Kevin Brady claims they are in his recent blog article "AGILE /SCRUM Fails to get to grips with Human Psychology". After reading his article, it seems it should have been named something like "Agile Methods Do Not Cure Dysfunctional Organizations". I believe the latter is true. I think agilists understand this at some level and that why they focus so much on the "agile attitude". My belief is that this "attitude" is a psychological prerequisite of a potentially agile team. Agile methods can’t reliably _create _ this psychological state, but they definitely require it. Without an agile attitude (focus on business value over politics, people-centric, empowering, …), it’s not surprising that organizations would experience the Orwellian effects that Brady describes — no matter what software development process they chose to use.
However, it also appears that Brady has a limited understanding of the agile methods he criticises. To make his point he focusses on Scrum teams that apparently had weak development practices and who operated within a dysfunctional organizational environment. Other agile methods, like XP, tend to focus more on development practices but even XP is doomed if it’s attempted in a highly dysfunctional organization.
Brady describes a 6 person team that he says failed with Scrum (athough he appears to be claiming a more general failure of agile methods). He lists the results of that project.
- "Project closed, business case closed and £30 million loss quietly absorbed and forgotten." Was this project closure caused by the use of agile methods? At this point, it’s not clear. Would a heavier process have saved it? Again, it’s not clear.
- "Testing was impossible with such limited up front requirements." It’s not clear if the up front requirements were limited because nobody knew the requirements or because the requirements were not fully documented up front. In either case, it’s not clear why the requirements that were identified could not have been tested. Agile methods generally recommend incrementally developing the tests in parallel with with code. In other words, create a large well-tested system by starting with a small, well-tested system and evolving it.
- "Acceptance criteria impossible to define because the requirements were never defined until too late in the programme." No requirements were defined until (too) late in the project? That definitely sounds like a problem, but agile methods don’t recommend that approach. They recommend not waiting to define all requirements up front since requirements and context often change during development of a project. I’ve worked on very large, global development projects with formal requirements processes and requirements were still being defined late in the project. That’s reality. The world changes and we learn. In any case, assuming at least some requirements were known earlier in the project, they could have had acceptance tests written for them. Brady also says,The system would only run to 3 concurrent users. Not suitable for a system to be used by 1000s of people daily but who’s to grumble AGILE says this is OK to start building databases and systems without detail like this. Just keep moving forward is all that matters in this cloud of confusion.— Kevin BradyApparently, no refactoring practices were used on this project. Given the weak testing approach, this is not surprising. It’s difficult to refactor effectively without tests even for the known requirements. Agile methods definitely do not say that forward motion in a cloud of confusion is all that matters. However, forward motion in a dynamic environment is possible, but requires a strong collection of practices to support it. It sounds like using agile methods in this organization was like putting a powerful engine in an automobile with a weak suspension, brakes, and tires. It’s a recipe for disaster, but that doesn’t prove all automobiles are flawed. It’s far from obvious that any other development method would have been more successful in the context Brady describes.
- "Ran out of budget without early warning because no one could see more than 28 days ahead or new the full scope with unmitigated and uncontrolled changes in scope." At least some agile methods (XP) suggest a release plan giving a longer range view of development activities. I don’t know enough about Scrum to know if this is true or not. I do know that a product backlog exists in Scrum that gives a view beyond 28 days. Why nobody could see farther than one spring is not at all clear. (All of these issues point to more fundamental problems than whether the team used agile methods or not.)
- "Some of the worst usability I have ever seen because the user flows could not be tested up front because the requirements were at feature level". It’s not clear, but it appears that Brady may be confusing the equivalent of XP user stories (a placeholder for development/client discussion about requirements) with feature level "requirements". It is very true that defining user stories and never following up with the conversation to define specific requirements like user flows (and documenting those as test cases) could well be disastrous. However, agile methods don’t recommend this latter practice.
- "A horrid final system. Because iterative development methods were used with each part of the system independently designed without a broad view of the full requirements." The phrase "independently designed" sounds like a euphemism for designed with ineffective communication between the developers. It’s also clear there was no continuous integration practices. I not seeing any relationship between these problems and iterative development, as Brady claims.
I don’t have a strong objection to Brady’s beliefs about human nature although I believe they have little or no relationship to his criticism of agile methods. We need to find ways to heal "sickly" (Brady’s description) IT organizations so they can use more effective development methods the way the methods were intended to be used — agile or otherwise.