Project evaluations (or retrospectives) are a nuisance. Everybody knows they are important, but nobody performs them. With at least ten new projects starting every week in our company, how can I instruct our people to get all project stakeholders together (in ten different settings) and construct a "lessons learned" list of the ten projects that were delivered the week before? Nobody is available for such meetings because they are all too busy making sure the new projects are initiated properly. Sure, this is no excuse. But it is reality.
Automate the Process
To get around this problem I have decided to automate the evaluation process. Everytime a project is deactivated in our project management system, a notification message is sent to each of its stakeholders: the project manager (or ScrumMaster for some), the business consultant (or Product Owner for some), the technical lead, the technical manager, the financial department and the quality assurance manager. Each of them is asked to rate the project on a scale of 1 (Bad) to 5 (Excellent), with the option to add some comments and lessons learned. It is similar to Amazon asking you to rate a book after you've purchased it. (Only in our case people don't rate value-for-money but satisfaction-for-energy.)
No Secrets
The nice thing about this approach is that we are now starting to accumulate a queryable history of evaluations that will enable us to drill down to customers, teams and individuals. All ratings are open for everyone to read and respond to. We have no secrets. (If someone messed up completely, everyone usually already knows.) This makes sure that people's ratings and comments are honest as well as constructive. In fact, I just posted the monthly report of our April's ratings on our company intranet to share with everyone.
From Feedback to Action
Browsing through these evaluations regularly, I am able to pick up what the most common problems are and I can check if they are already covered by some of our quality improvement steps. In some cases the feedback still requires some face-to-face communication, as I walk up to people and ask them to elaborate on something, or to respond to someone else's somewhat critical findings. And in some (but fortunately rare) cases, when I hear of something that makes my hair stand on end (or my jaw drops to the floor, or my brain passes out) I organize a face-to-face project evaluation meeting. And believe it or not, it turns out that these are now easier to organize now that everyone knows that these meetings are only reserved for the most serious cases. Nobody wants to miss out on a bit of flame and mud throwing. All in good fun of course.
Lesson Learned
Sometimes you have to run a process the unconventional way, or it will never run at all. For years we never could get people to organize project evaluations. But the automated project evaluation looks to be reasonably successful. In April the number of automated evaluations climbed to 117, as compared to 65 in the month before. And in the meanwhile I do my best to make people see that the evaluations are actually being read and acted upon.
Of course, automation of an important part of a project workflow can only be done for the most mundane of processes. If you cannot get people to perform their daily stand-up meetings, I wouldn't dream of automating it!
RSS feed
Comments
My hair stands on end...
I don't really recognize the agile idea in your post. Where's collaboration? Where are the individuals and their interaction? Where's the team?
Do you really expect shaping effects for the team or the process by commenting on estimated versus achieved percent numbers? At least that is what your charts imply. Numbers are the centric point in this "automated evaluation".
Believe it or not, there is a tremendous difference between hacking some comment into a wiki and interacting with team mates in a face to face situation. Those are lessons to be learned to support team building and increase productivity.
This conecpt may be effective in your environment, but it's everything but agile.
I would recommend to do some research on what (and whom) the retrospective is intended for. I would try to narrow down the attendees to just the team members and define a time box for the meeting. The Scrum Master (your "equivalent" role names are not really equivalent in terms of agile, by the way...) should be well prepared. He should be a well trained moderator, which is extremely important especially for retrospectives.
Give this a try and watch your teams growing more and more productive and your process evolving into a more agile one.
When is something agile?
"This concept may be effective in your environment, but it's everything but agile. "
Sometimes people don't recognize agile when the textbook examples are not being followed to the letter. Are you the one to decide what's agile and what not?
Our ratings mechanism acts like a wiki or a forum. The information is open and shared with everyone. Interaction is in the replies among the comments, and people can contribute freely. That's agile enough to me.
"your "equivalent" role names are not really equivalent in terms of agile, by the way...)"
Ken Schwaber himself explains that people should not follow the rules just because they are rules. I'm reading his latest book right now in which he explains how he has bent Scrum in many ways to fit the organizations he worked for. If something works, then that's fine!
You seem not to recognize that *agile* means doing what's necessary to achieve a solution that works. You are telling me that my efforts do not follow the official agile rules. But it seems that you are following what Ken Schwaber calls a "defined process", while agile is all about following "empirical processes". Do whatever it takes to make something work. Try the textbook solutions first. But if they don't work, try something else.
Post new comment