In Part 1 and Part 2 of “Agile Antipatterns: Easy to Spot, Hard to Change”, I discussed the main agile antipatterns signifying that an organization may not be ready for adopting agile. This is the third and final post in a series of articles on dealing with the impediments to adopting agile practices successfully.
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.
8. Unwillingness to invest in training and coaching
Agile looks easy. All you really need are daily meetings, a status board, and active SQA participation, right? No need to spend a lot of time planning and designing. Just jump in and start writing code. The team will sort things out as they go. What could be simpler?
In fact, it’s so simple, that there’s no need for training, coaching or other expensive services. The team is bright. They’ll figure it out.
Sure they will! To anyone who thinks agile software development is easy, I have bad news for you. It’s not. In fact, getting agile development right can be more complex than getting waterfall development right.
Comments