By James Dobbs (https://www.linkedin.com/in/james-david-dobbs)
The Agile methodology is a powerful tool that can increase the success rate for project delivery, decrease delivery time, lower the rate of troubled projects, control budget overruns, and increase team morale. As a result, many organizations are hastily moving projects onto the Agile methodology that may not be suited for it. This can cause massive negative impacts and destroy entire programs.
Determining when Agile is effective and when it is not.
When properly applied to projects where it is well suited, Agile is an extremely valuable tool with myriad upsides and few to no downsides. If Agile is misapplied to a project, the results can be disastrous. Every project should be reviewed on a case-by-case basis to determine if the Agile methodology will be useful. One can do this by asking themselves the following about a project:
Q: Is the problem to be solved simple or complex?
A: Complex projects are a better use case for Agile.
Q: Are the solutions initially known or unknown?
A: Agile works better when project solutions are unknown.
Q: Are requirements set in the beginning and unlikely to change?
A: The Agile methodology is better for projects with changing requirements.
Q: Are end users able to collaborate and give feedback?
A: Agile is better for projects in which end users can collaborate closely and provide feedback.
Q: Is the work modular, and can it be conducted in rapid iterative cycles?
A: If the work is incremental, Agile is a more favorable methodology.
Q: Are late changes manageable, or are late changes expensive/impossible?
A: Agile should only every be used when late changes are manageable.
Q: Are end users unable to start testing parts of the project before the whole project is complete?
A: Agile only functions properly when iterative testing can successfully inform development.
Q: Are mistakes during the project low-cost opportunities to learn and make improvements, or are mistakes catastrophic?
A: Agile should only be used when mistakes are low-cost opportunities for improvement.
Management must trust teams to set their own velocities for issues.
When a cross-functional team comes together to evaluate an issue that needs to be addressed, they determine their collective domain knowledge, experience, and the ability of all necessary parties to sync up and collaborate on aspects of the issue. These factors create an inherently unique team to which past teams (or hypothetical ones) cannot be compared. These are the factors that a team uses to determine the velocity on a project and for Management to collapse or expand that timeline can introduce chaos and undermine the Agile methodology.
Agile must be customized, but not too quickly.
Do not use the Agile approach to customizing Agile. Only after using proven approaches, rules, and methodologies that have delivered success in thousands of companies for hundreds of thousands of projects (and perfecting them) can an organization move to customizing Agile to fit their needs.
Agile must be iteratively improved. Once a team is ready to make changes, the should track not only the metrics they’re looking to improve, but also any effect on key performance indicators, including team morale. If slowly and systematically optimized, an organizations homebrew version of Agile can become more powerful than the base Agile methodologies. If properly implemented with skilled cross-functional teams on appropriate projects, the Agile methodology can set an organization and its teams up for unparalleled success.