Cramming Works in College But Not in Agile Projects

This is the seventh in a series of posts on dealing with the impediments raised in “Agile Antipatterns Are Easy to Spot, Hard to Change”. The seventh antipattern discussed in the post is…

7. Cramming as much as possible into every iteration to ensure that the team is kept busy

You’ve undoubtedly heard of Parkinson’s Law — “Work expands so as to fill the time available for its completion.” Many managers strongly believe it. It causes them to cram more work into a given time period than can be done. This provides some level of comfort in knowing that everyone will be kept busy. Of course, the target completion date cannot be met by definition — there’s too much work to do. Project failure, as measured by meeting end dates, is guaranteed.

There are other negative repercussions from this law as well. When a project team is under intense pressure to over-deliver, they will cut corners. Software quality, code maintainability and system performance will have to suffer the consequences. The team may react by padding their task estimates to give themselves more time. All that does is mask the problem and damage the team’s ability to meet business needs.

This suicidal management behavior can be even more damaging on agile development projects. Short iterations or sprints provide many opportunities to invoke Parkinson’s Law. As each iteration under-delivers, the team either falls further behind the business or incurs massive technical debt. Either way, the team and the business are in big trouble.

The cure lies in following agile principles.

Short deadlines and peer pressure are powerful tools. Every administrative manager, project manager, Scrum Master, and project leader should master them.

Keep tasks small and make the end results measurable. This approach provides frequent checkpoints and many opportunities for corrective action. Don’t wait several weeks (or months) for an activity to be completed only to find out that it’s late or deficient. Break up the activity into tasks that are no more than 30 hours of work (I’m assuming a 40-hour workweek with 75% efficiency.) Ideally, shoot for average task duration of 6-12 hours (i.e. 1-2 days).

Encourage teamwork, swarming, and active business participation. When the team is collaborating openly and swarming to help a team member in need, everyone will make the extra effort to get more done while meeting quality metrics. When the business stakeholders and end users are engaged in the process, additional positive pressure will encourage the team to over deliver.

Don’t force the team to accept more work than can be done. Lead them to doing more by creating many opportunities to succeed, and many situations to collaborate.

Updated: November 22, 2011 — 9:37 pm