I’ve heard the phrase “Agile doesn’t work.” numerous times. Perhaps you’ve heard it. Maybe you’ve said it yourself.
Usually, the counter argument is “You’re doing it wrong!” And yes, the tempo and volume of the argument tend to increase when things are going poorly on a project. The closer you get to a deadline, the louder anti-agilistas become. The practice of agile software development tends to polarize, especially when projects slide toward “very challenging.” I suppose that’s when projects get evaluated for how well they are doing or how well they went. It is understandable to point fingers at the process — agile or not.
When agile works (and when it doesn’t)
I believe that agile does work if you’re willing to make it work. Many teams, projects, and organizations have employed agile methods wonderfully and fantastically — and the success is pretty well-documented and cited.
Does this mean every project or team should use agile methods? Hardly.
Not the right way to do agile, in this author’s opinion | Via quickmeme
If you look under the covers for the different software development methods, the key differentiators are:
- Criticality — If the software is wrong, will it kill someone?
- Experience and excellence — How good is the team at delivering quality software?
- Change — How easy is it to define requirements up front?
- Culture — Does the organization support change and trust people?
There’s certainly other aspects, but these are the biggest ones.
Let’s take, for example, an FDA-regulated project that will deliver software that controls a robot used in brain surgery. High criticality. The company is minimizing cost by hiring “fresh outs” and the product manager is still working with neurosurgeons and robotics experts on the hardware. Oh, and let’s get that FDA submission out the door next year; we’ll get our quality management system together during the development phase, too!
Sure, it’s a very extreme example and the project is challenged from the start no matter whether adaptive or plan-driven methods are used. Extreme examples tend to expose falsehoods in statements like “agile doesn’t work.”
Enabling agile teams, not managing them
Anti-agilistas will claim “victory” in the above example — that project will fail if they use agile methods. The truth is, that project will not deliver high quality software on time not because of the method used, but because of the nature of the project. If you’re set up to fail, it doesn’t matter what method you use.
In the end, agile methods are better than plan-driven methods given the right context. It really comes down to management — who owns the process, who owns creating the team, and who owns providing the environment for that team to succeed. What tends to happen with agile transformations is that middle management — people who are overseeing big agile software development teams — tend to be in command and control mode. The fear is that their jobs will be eliminated.
That skillset isn’t warranted when you convert to agile. You need people who will:
- enable the process,
- create a collaborative work environment that’s safe,
- remove obstacles when they arise,
- and build a team with the right mix of skill sets and experience.
If you have a team of great developers and you’re missing a skillset, the project is not going to go well. Running a successful agile project is not about managing the team; it’s about enabling the team and providing the team with exactly what they need.
