Process empowerment and team building through retrospectives
Because, at our core, engineers tend to be creative types most of us share the following sentiment:
We hate process.
At least, we hate process for process sake. For the kind of person who forsakes the assembly instructions for any piece of electronics they purchase, it doesn't exactly engender excitement to fill out what may seem like needless documentation and follow rules that appear to do nothing but delay the schedule. Even the most cynical among us, though, would agree you need some sort of process to manage the goings on in a project.
How do you get a group of people to follow a process when they naturally hate them? By letting them shape and tinker with that process. When someone feels empowered to change something they think is broken, they are more likely to go along with it until it is fixed and then adhere to the alteration given they had a hand in creating it.
Changing process in the middle of a project can be difficult, though, and can possibly lead to anarchy if you aren't careful (somebody will stretch the meaning of "process change", for sure). Instead, I've found that the best time to tinker with process for a project is when you are doing the retrospective for the previous project. Two jobs ago, I tried my hand at project management for 6 software releases over about a 15 month period.
Taking on the challenge issued by Scott Sehlhorst and the good folks over at Tyner Blain, here's my "how something I did made a project successful" entry on how we improved teamwork, empowered engineers to make process changes, and let off some steam with a good project retrospective. While hardly rocket science, some wrinkles in the steps below are unique and helped improve the results of the session.
As homework prior to the retrospective meeting, each team member was required to come up with "3 things that went well" and "3 things that didn't go well". The meeting would then proceed like this:
1) Play Google Words. Given that we were having a meeting that worked best with everyone's participation, we needed to get everyone in a talking mood. Hence, lead with a game that requires everyone to speak. As an added bonus, the order of finish in the game determined the order of presentations for later steps.
2) Review the "went well" lists. In the order of finish from the game, each team member presented their "3 things that went well". The "no interrupting the speaker" rule was in effect to keep the more talkative members of the group from overwhelming the quieter ones. I'd record a synopsis of each point on a PowerPoint slide everyone could see using NetMeeting.
You might be thinking, "Why the 'went well' list first?" I like to go with the positives initially because it opens a chance to pat folks on the back. "Yeah, Sonny, your idea to spend the extra money on that organic peanut butter really did make a better sandwich." It not only allows you to give verbal rewards like the contrived example just given, but makes them generally more receptive to the criticism to come for the things that need fixing.
3) Review the "didn't go well" lists. Same general approach as #2, but reverse the order used. That's a little sneaky, as the folks with aggressive personalities that tend to dominate such discussions will usually press to do better in the game and be forced to go last when it comes to finding places to improve. Typically, the same ideas will be mentioned by multiple people and that is denoted in the slide being shared.
It is important that, at this point, you want to let everybody list what the problems are, but not address solving them just yet. Think of it as a brainstorming session for the things that sucked. When everyone has had a turn, sort the cumulative list on the slide by the number of times that people mentioned it.
4) Pick 3-5 problems and document process changes to solve them. Now that everybody has had a say and the group has collectively determined what the key problems are, discuss how to solve them. This should take the bulk of the meeting time as you'll likely get more than one suggestion on what could be changed. It might lead to a side project for somebody too, such as finding better bug tracking software.
The key is, be open to change and letting your people make the process something that helps, not hinders, their productivity.
5) Have a "Name the Next Release" contest. It's always good to end on a positive note and this is an easy way to let people have some fun while fostering some teamwork. In random order, people suggest one word names for the next software release. Again, "no interruption" rule in effect. Then, each person explains what the word means.
Inevitably what happens is that people will choose a name that has something to do with something going on in their lives and in letting them explain it you learn more about that person. That sparks team building, which can help later when the pressure mounts on the schedule for people to lean on each other for support.
For example, one release someone suggested "Granite". Sounds unappealing for a web application framework release name, doesn't it? The woman who suggested it went on to explain that she chose it because it was the name of her daughter's pet rabbit who had died the week before and was so named because of a fur pattern that resembled a slab of granite. Needless to say, when we multi-voted on names, that won by a landslide because of the story that went with it. Throughout the release, we got regular updates on how the daughter was coping with the loss and, in the process, found out a lot more about that team member than we otherwise would have.
Conclusions
The best way to get a team of people who ordinarily despise process to embrace it is by giving them a regular opportunity to change it. The set of steps described above were used successfully for a long string of software releases with more refined processes as time moved along and helped build team cohesiveness too. A group that plays together, changes the way they go about their jobs together, and learns personal insights about each other operates much more optimally than one that does none of those things, or even two of them. With all of those aspects in place, you build a group of people willing to handle pressures together and deliver results, knowing that if things get messed up they'll have an opportunity to change the way things are done so improvement comes the next time around.
We hate process.
At least, we hate process for process sake. For the kind of person who forsakes the assembly instructions for any piece of electronics they purchase, it doesn't exactly engender excitement to fill out what may seem like needless documentation and follow rules that appear to do nothing but delay the schedule. Even the most cynical among us, though, would agree you need some sort of process to manage the goings on in a project.
How do you get a group of people to follow a process when they naturally hate them? By letting them shape and tinker with that process. When someone feels empowered to change something they think is broken, they are more likely to go along with it until it is fixed and then adhere to the alteration given they had a hand in creating it.
Changing process in the middle of a project can be difficult, though, and can possibly lead to anarchy if you aren't careful (somebody will stretch the meaning of "process change", for sure). Instead, I've found that the best time to tinker with process for a project is when you are doing the retrospective for the previous project. Two jobs ago, I tried my hand at project management for 6 software releases over about a 15 month period.
Taking on the challenge issued by Scott Sehlhorst and the good folks over at Tyner Blain, here's my "how something I did made a project successful" entry on how we improved teamwork, empowered engineers to make process changes, and let off some steam with a good project retrospective. While hardly rocket science, some wrinkles in the steps below are unique and helped improve the results of the session.
As homework prior to the retrospective meeting, each team member was required to come up with "3 things that went well" and "3 things that didn't go well". The meeting would then proceed like this:
1) Play Google Words. Given that we were having a meeting that worked best with everyone's participation, we needed to get everyone in a talking mood. Hence, lead with a game that requires everyone to speak. As an added bonus, the order of finish in the game determined the order of presentations for later steps.
2) Review the "went well" lists. In the order of finish from the game, each team member presented their "3 things that went well". The "no interrupting the speaker" rule was in effect to keep the more talkative members of the group from overwhelming the quieter ones. I'd record a synopsis of each point on a PowerPoint slide everyone could see using NetMeeting.
You might be thinking, "Why the 'went well' list first?" I like to go with the positives initially because it opens a chance to pat folks on the back. "Yeah, Sonny, your idea to spend the extra money on that organic peanut butter really did make a better sandwich." It not only allows you to give verbal rewards like the contrived example just given, but makes them generally more receptive to the criticism to come for the things that need fixing.
3) Review the "didn't go well" lists. Same general approach as #2, but reverse the order used. That's a little sneaky, as the folks with aggressive personalities that tend to dominate such discussions will usually press to do better in the game and be forced to go last when it comes to finding places to improve. Typically, the same ideas will be mentioned by multiple people and that is denoted in the slide being shared.
It is important that, at this point, you want to let everybody list what the problems are, but not address solving them just yet. Think of it as a brainstorming session for the things that sucked. When everyone has had a turn, sort the cumulative list on the slide by the number of times that people mentioned it.
4) Pick 3-5 problems and document process changes to solve them. Now that everybody has had a say and the group has collectively determined what the key problems are, discuss how to solve them. This should take the bulk of the meeting time as you'll likely get more than one suggestion on what could be changed. It might lead to a side project for somebody too, such as finding better bug tracking software.
The key is, be open to change and letting your people make the process something that helps, not hinders, their productivity.
5) Have a "Name the Next Release" contest. It's always good to end on a positive note and this is an easy way to let people have some fun while fostering some teamwork. In random order, people suggest one word names for the next software release. Again, "no interruption" rule in effect. Then, each person explains what the word means.
Inevitably what happens is that people will choose a name that has something to do with something going on in their lives and in letting them explain it you learn more about that person. That sparks team building, which can help later when the pressure mounts on the schedule for people to lean on each other for support.
For example, one release someone suggested "Granite". Sounds unappealing for a web application framework release name, doesn't it? The woman who suggested it went on to explain that she chose it because it was the name of her daughter's pet rabbit who had died the week before and was so named because of a fur pattern that resembled a slab of granite. Needless to say, when we multi-voted on names, that won by a landslide because of the story that went with it. Throughout the release, we got regular updates on how the daughter was coping with the loss and, in the process, found out a lot more about that team member than we otherwise would have.
Conclusions
The best way to get a team of people who ordinarily despise process to embrace it is by giving them a regular opportunity to change it. The set of steps described above were used successfully for a long string of software releases with more refined processes as time moved along and helped build team cohesiveness too. A group that plays together, changes the way they go about their jobs together, and learns personal insights about each other operates much more optimally than one that does none of those things, or even two of them. With all of those aspects in place, you build a group of people willing to handle pressures together and deliver results, knowing that if things get messed up they'll have an opportunity to change the way things are done so improvement comes the next time around.
Labels: General stuff
2 Comments:
Great job Pete! Is there anyone you want to tag? These things are all about geometric growth - put some folks on the spot.
No problem Scott.
Via email, I tagged Tac Anderson, Jason Alba, and Scott Allen. We'll see if they play 8).
Post a Comment
<< Home