Maintaining Development Momentum
New development is self fueling. Momentum is rarely a problem early off. The team is hungry to transform their ideas into code. Then as the refactoring and development proceeds design flaws begin to emerge and revisions being to happen. Depending on the severity of the problem it may be corrected in the current iteration or queued up for a future iteration. Working through these scenarios is what builds team cohesion. Overcoming design hurdles and major refactoring provides fulfillment and gratification for the team. The code base was solid before but now it is even better!
Iterations pass and depending on the size of the overall project the team may grow tired. During the early iterations when the energy levels are high you need to build up endurance and set the pace. I love to go full bore but that kind of pace cannot be sustained. This is why development teams needs to be thought of as a relay team running a relay race. Staggering iterations, or legs of a relay, among the team allows individuals "to pass the baton" and rotate off the critical path. This allows you to formulate strategies, based on your team’s strengths, for the upcoming iterations and keeping the team energized.
A few momentum killers
Disengaging the team or individual members for fire drill exercises are the single biggest momentum killer. Most iterations only last a couple of weeks. Management may try to pull people from an iteration to perform another task. From a managers viewpoint the individual completed their work for the iteration so pulling them to tend to another task makes sense. We all know this should not happen but it does and it will happen.
The nature of iterative development usually means subsequent iterations become more complicated and the pressure and stakes are higher. This occurs for an obvious reason: increased functionality of the code base. Do not allow yourself to under estimate iterations under pressure from above. This will happen and create additional stress for the team.
It's all about teamwork
Here are a few key guidelines I follow.
| • |
Have fun with your work. Smile and laughter keeps stress to a minimum and keeps you approachable to your team members. |
| • |
Lead by example. This kind of behavior is contagious. |
| • |
If you are a lead, stay involved as a code contributor. |
| • |
Make time for creativity. Don't schedule individuals with mundane tasks back-to-back. Their enthusiasm will begin to drop. Keep it mixed up. |
| • |
Make sure everyone has weekly goals/deliverables. Everyone should be working to contribute a piece of the puzzle on a weekly basis. |
| • |
Work as a team. Keep everyone engaged and involved in the decision making process. Collective code ownership. |
| • |
Pair program liberally. When working on complex algorithms or refactoring code work in pairs. The creativity can really flow. |
| • |
Police each other. Multiple people should have an understanding and contribute to functionality across the code base. Two or three minds work better than one. |
| • |
Track project metrics from the start. These metrics are vital to estimating future iterations. Use these metrics to back up your estimates and keep the team out of the pressure cooker. |
Comment Notification
If you would like to receive an email when updates are made to this post, please register here
Subscribe to this post's comments using
Comments