Often times when introducing some of the basic agile project management practices to new teams (for example, the daily standup) some of the more experienced (ok, older) team members comment on the fact that these techniques look a lot like the techniques they used in the past when their projects were in deadline trouble. Indeed, most of us have similar experiences with challenged projects and when a project is struggling, and the deadline approaches, we would always fall back on some tried and true disaster recovery techniques. We’d form “tiger teams” that would typically work as follows:
- Quickly form a team of key, dedicated individuals, representing all the necessary disciplines
- Empower the team to cut scope as necessary in order to achieve the deadline
- Meet daily, first thing every morning (meet twice daily as the deadline approaches)
- Bring honesty and complete visibility to actual, objective (not planned) project status
- Commandeer outside resources as necessary
- Continue doing all the above until deadline achieved
We immediately see the parallels to agile project management, reflecting again that agile is not so much new, as a synthesis of some of most effective and highly tactical project management techniques from prior experience.
Parallels are as follows:
| Tiger Team Action | Agile Team Principle |
| Form a team of key, dedicated individuals, representing all the necessary disciplines | Get the right people on the team. All necessary disciplines (define-build-test) must be present. Dedicate the team members for the life of the project (iteration or release). |
| Meet daily, first thing every morning (meet twice daily as the deadline approaches) | Daily standup. (Plus we have observed many teams doing twice daily stand-ups as iteration or release deadlines approach.) |
| Empower the team to cut prioritize and cut scope as necessary in order to achieve the deadline | Product Owner who is a team member, empowered to manage priorities and cut scope is systemic in agile |
| Bring complete visibility to actual, objective (not planned) project status | Empirical, demonstrable frequent outputs in hands of product owner and customer |
| Manage/commandeer outside resources as necessary | Commit resources, eliminate outside impediments that inhibit success |
| Continue doing all the above until deadline achieved | Repeat for every iteration throughout the project lifecycle. |
In other words, the best way to keep projects out of trouble is to apply the same intensity at the beginning of the project as we used to do at the end. While this may seem intense for the routine day to day existence of the project, the actual result is sustainable and highly productive development process that avoids the enormous deadline pressures we used to see at the end, as the illustration below shows.
Scaling Software Agility 