The Regenerate Web

Reading this post on Carpe Factum made me want to share about my experience with "agile" management practices.

The value of the agile, especially SCRUM, is the continual measurement of the distance to a goal. That is, for me, a signficant benefit. Here are the premises:

• Tasks size is small, so deviation from estimate is identified quickly.
• Frequent measurement of distance to the goal. In SCRUM the daily meeting allows the SCRUM Master to measure the distance. The burndown charts they use show daily progress toward the interim goal
• Use of interim goals to calculate velocity. In SCRUM they recommend 4 week sprints or iterations, which creates a more consistent urgency (prevents procrastination or chewing up slack that the beginning of the project.
• Create an environment where the team members can focus on the immediate. The reduction of the required time span for team members allows them to freely focus on the now, rather than being overwhelmed by the scope of future expectations.
• Dynamic planning allows the estimates to be more accurate as we approach the goal. In each iteration or cycle, team members are asked to break down the work into smaller chunks and estimate the smaller chunks. Team members are encouraged to add tasks as they learn about the project, so that the measurement of distance to the goal remains accurate.
• Binary task status reduces fiction from project status. A small task is either complete or not. Distance to the goal only changes when tasks are marked complete. 90% done is a useless backward looking statistic - it is all about velocity and distance to the goal.

In my experience, agile project management methods make issues visible earlier, because of the small task size, the reduced fiction, and the emphasis on more meaningful statistics.

I also recognize that in the enterprise, there are challenges on integrated projects where teams are using agile and traditional methods. The agile methods emphasize sequence over schedule. When there are dependencies, they are reflected in sequence. When working with external dependencies, this is harder to manage using these methods.

My personal experience implementing agile practices for management, reveals that there is tremendous benefit for organizations that support multiple concurrent projects with individual contributors matrixed across projects. I believe that this is because of the time boxes or iterations, and how each individual's time span is reduced. When working on multiple projects with differing schedules, it is hard to know which task has higher priority. In allowing the individual to focus on the immediate, he can simply grind away.

My current time box style is concentric monthly and weekly timeboxes. This inner weekly time box allows IC's to focus on what needs to be complete this week. If that doesn't allow you to focus, nothing will.

Hope this helps explain why people believe these methods work for them.