We've written a number of posts about agile techniques of project management on this site, all in a spirit of advocacy. A comment at my personal site on one of the most recent reminded me that agile/scrum isn't necessarily the right solution in all situations, and in some it may work but needs to be applied carefully. After that comment I thought it would be interesting to write about situations in which agile methods should be applied with care, if at all:
6. Be careful with agile methods if your projects require people with distinct, highly specialized skills
One source of "agility" is that with group planning and simple, visible task lists, a team member finishing one task can grab another available task and work on it. Therefore team members never have downtime and the team is always fully productive. However, this pattern can break down when some stories require deep skills not shared among all team members. In the data management/business intelligence world in which I work, it is practical to cross train teams so that they can work in a truly agile manner. However, as my commenter "Rick" points out, that's not always the case:
"It has taken me years of study to learn what I know ... there are plenty of people who know as much or more than I do, but they aren't usually on the same team ... [and] unless its an obvious bug, such as a null pointer, unless you are familiar with quaternion math and plucker coordinates, Euler angles, etc. you aren't going to just be able to pick up where somebody left off."
My friends Susan Bullock and Ben Harden recommend tackling this one with team organization strategies, like separating the "experts" out into a separate team or accepting the imbalance and over time helping others come up to speed with the specialized skills. However, the new scrum master should recognize that vanilla agile techniques may require some adjustment if skills are unusually unbalanced.
5. Be careful with agile methods if your projects are fixed price
In my experience, and as is frequently documented, early detailed application requirements are usually either incorrect or incomplete, and early estimates are usually very low. Even so, fixed price software projects persist. Fixed price contracts succeed by demonstrably fulfilling the contractual requirements, and managing change by altering the contract, not by effectively managing changing user needs. One of the central agile tenets is to value "responding to change over following a plan". Fixed price projects succeed by rigorously following a plan. When change comes, the team responds to it only when it comes via a change in the contract plan.
In this case the team should recognize that there's an additional step before a product owner request can make it to the backlog. Fixed price projects require the team to bend this particular agile tenet and only add to the backlog after the request has been made part of the plan, and price is adjusted accordingly.
4. Don't use agile methods if you don't really mean it
In a 2011 SD Times post, JD Hildebrand describes the dismayed reactions of some of the signers of the original Agile Manifesto about the state of the practice after 10 years. The article describes their observations that, although the practices were widespread, the spirit was not. In the signers' view the great majority had implemented processes and tools but left aside the "individuals and interactions" (quoting another central agile tenet). My experience is that agile techniques in themselves are simply tedious unless applied in the right spirit. Little is more humdrum than team sprint planning to meet a goal set by program managers, or an hour-long standup in which participants explain in detail why their deliverables are late. If you aren't ready to buy into the spirit of embracing change and cultivating individual creativity, your Gantt charts and work breakdown structures will serve you better anyway.
3. Be very careful with agile methods if you are the only one who means it
If you are a PM in an all-waterfall organization, be careful about switching your team over to agile/scrum without support, either from your team or your management. If your team is on board, then be prepared to take on the work of translating your agile sprints to project phases, translating burndown charts to progress against the project plan, etc. If on the other hand, your managers are convinced but the team is skeptical, be prepared for to train your team in the techniques and facilitate their progress as they negotiate their new-found freedom and responsibility. If neither your team nor your management supports you, then your best bet is to lobby your managers to get their full buy-in before moving ahead.
2. Don't use agile methods to recover a failing waterfall project
More than once I've seen this pattern: a waterfall project fares swimmingly through the analysis phase and then hits a few minor snags in development. By the beginning of the testing phase, it is clear that things are desperately wrong, and someone pipes up, "why don't we go agile?" So the team begins daily standups and adds some of the other trappings and the project descends to the predictable death march. It is no surprise that those team members resolve that this agile thing isn't all it is cracked up to be.
1. Don't use agile methods with a team of part-timers
Carl Alvano recommends that you "don't use Agile techniques if your team is not fully allocated to the project. If 25%, 50% or more of your team members' time is dedicated to other efforts, then it will be difficult to fully utilize Agile techniques." My experience squares with Carl's. Success with agile methods requires developing team synergies, and thereby a measurable, predictable, and improving team work rate, estimates, and output quality. The need for fully committed resources is reflected in the agile fable about the chicken and the pig.
So there are six scenarios in which to be very careful with agile techniques, but don't get the wrong impression. If you are at the point of a) starting a new effort, b) require generally accessible analysis and development skills, c) you can see that detailed requirements may not be stable (are they ever?), and d) you can raise organizational support, then you may be in a good position to establish agile techniques as you start out.