This is the fifth in a series of posts on self-management that began with "The Use of Self-Managing Teams Outside the Context of Software Development."
Short Iterations Increase Management Leverage
One of the hardest jobs of a manager is discovering and resolving problems. If you don’t know about a problem, you can’t resolve it. If you discover a problem late, you can’t do much about the negative effects it has already had. If you don’t get feedback on the results of the actions you take for a long time, it is difficult if not impossible to judge the effectiveness of your actions. Short iterations, the practice of breaking up a release into 1-4 week development cycles that each produce a shippable increment of work, vastly increase the amount of feedback available to management for making good decisions. It also provides more opportunities to make adjustments and judge their effectiveness.
Burndown Charts are a Management Dashboard That Everybody Loves
A burndown chart is a useful tool for measuring the amount of progress, positive or negative, during an iteration which clearly illustrates trends which may indicate problems. It is simply a day-by-day chart of how much effort remains. At the beginning of an iteration, 100% of the work for that iteration remains. At the end of the iteration, there should be 0% remaining.
An important multiplier of the effectiveness of a burndown chart is its visibility. A clearly visible burndown chart makes it obvious to everybody how the project is progressing. Nobody wants to see a burndown chart that isn’t making progress, and nobody wants other people to see lack of progress for a significant period of time. The burndown chart helps to motivate and inspire. If your own work is going well, but the chart isn’t going down in general, you’ll be more engaged in helping to solve problems that the team is having overall. When used effectively, the burndown chart reduces the effort required for a manager to determine that there is a problem and also reduces the need for the manager to cajole the team into taking corrective action.
Retrospectives Emphasize That You Are All In This Together
A retrospective provides a forum for the team to talk on a regular basis about what worked and what didn’t work as a team, to discuss ideas for improvement and to work out problems. Instead of a manager having to unearth all problems and come up with all solutions, a retrospective accomplishes much of this, providing the manager with more bandwidth to deal with sensitive issues and to focus on people management. Retrospectives are particularly effective when combined with short iterations because problems have less time to fester and there are more opportunities to take corrective action.
User Stories Reduce Micro-Management
Agile prefers user stories over requirements. User stories are simply stories that describe what is needed from the user’s perspective. User stories help to separate business value from implementation and focus all parties on the desired outcome. The separation removes the invisible constraints which can appear when the engineer assigned to a task is given a specification which completely constrains the problem such that only one solution is available. By focusing on the outcome desired by the user, the engineer working on the task has more freedom to utilize their creativity and ability to innovate without the risk of implementing something that the user doesn’t want.
There are two reasons that user stories support self-managing teams. First, they reduce the temptation of technically minded managers from becoming an implementation bottleneck. Second, they encourage team members to innovate and take on more responsibility which increases their self-sufficiency. This is much easier to do within an Agile environment because there are more practices in place such as short iterations, burndown charts, and retrospectives which encourage learning while reducing the risk of making mistakes.
I hope you have enjoyed this series on how Agile practices reduce and redistribute the job of management and thereby increase your capacity for self-management. If you missed the beginning, the first posting is "The Use of Self-Management Outside the Context of Software Development" .
via http://damonpoole.blogspot.com/2009/01/getting-management-and-engineers-out-of.html
Posts
