Oct
17
Methodology Misuse
October 17, 2005 |
At some point, I’m going to have to stop simply critiquing Agile methods and actually propose alternatives. That sounds suspiciously like work.
In an attempt to put off dealing with that, I’m going to change the subject, at least a little. I can’t remember who originally pointed this out, but I generally agree with the perspective that says that methodologies are a response to failure. People encounter problems that frustrate them, dream up a way to fix it, try it out, refine, it, and eventually it gets a trendy name and people start writing books about it.
So what happens when the method encounters trouble? Let’s assume, for the moment, that the method is a good one, since the failure of bad ideas is pretty self-explanatory. Good methods run into trouble when they encounter problems they weren’t designed to solve. This is pretty common. For instance, there is this thing I hear about called “analysis paralysis“. I don’t suffer from it. Never have. So will a methodology I develop include robust defences against it? Probably not. All I can really do is say “don’t do that then” or suggest things which sound to me like they would work. But I’m not going to spend a lot of time on it, or add a bunch of stuff to prevent it, because I don’t have the problem. So any additional effort or rules are useless.
But sooner or later, that methodology is going to find its way into the hands of some organization that suffers from analysis paralysis and does so badly. One answer, of course, is that it will fail, and then they will throw out the method or claim to practice it while doing something else (this last, by the way, is very common). Or, maybe I’ll hear about it and try to help.
This is where most methods get into trouble. They do one of two things. First, they can introduce more checks and balances and increase the complexity of the method in order to solve the new problem. This usually includes shoehorning in additional roles, responsibilities, and tasks. This is what happened to RUP, as far as I can tell–the additional verification steps and control desired by large customers, with masses of different stakeholders, caused an iterative process to balloon and complexify to the point where it’s very hard to implement a “vanilla RUP” iteration in less than 6 months. Or, the method tries to remain reasonably light and stays as is, with an injunction not to do that. This leads to the people who implement the method inventing ways to solve the problem, and we get back to the first outcome.
The third possibility, of course, is that the people trying to implement a methodology don’t actually understand why the method is structured a certain way, never actually use it correctly, and so try and solve problems that don’t exist. But again, that’s not the method’s fault.
I suggest that a method should explicitly include three things to avoid these problems: assumptions, contracts, and correctives.
- Assumptions tell people what conditions the method is known to work under–for instance, that iterations will be short (and how short they should be), teams should be a certain size, there should be so many stakeholders involved in the project, etc. Assumptions tell you where a method has not been tested.
- Contracts tell you where a method has failed or will fail. If a method requires that you have a team of less than 20 people say so. This is the “it breaks under these conditions and it’s not worth fixing” section.
- Correctives are problems that have been solved in the past–they say essentially “you may not have this issue, but if you do here’s a way to deal with it”. A corrective isn’t core to the method–in my example, it would be a technique to avoid analysis paralysis. For Agile methods, they describe what you do if the customer doesn’t know what they want, or if you have to deal with 20 different stakeholders who all have immediate demands of the system, or if you have a customer who won’t accept deployment more than once a year.
No method is good for every possible development problem. What I want to encourage here is thinking about what a particular method does well and what it does poorly.
Comments
What I'm Reading- Agile Requirements Information Model (4) – Subset For Agile Programs (a): Features and Feature BacklogScaling Software Agility
- The Great Implication of Context-Driven MethodologyJames Bach's Blog
- User stories versus Use CasesBusiness Analyst Blog
- Can Use Cases Possibly be Agile?Agile Product Owner (.com)
- A little bit of levity for the holidays from iRiseThe iRise Blog
- The end of reposiphilia?The Forrester Blog For Technology Product Management & Marketing Professionals
- IT ethics and the recessionIT Project Failures
- Risk Assessment ModelingEDS' Next Big Thing Blog: Read and Respond to What the EDS Fellows Say About Technology
- Test Requirements, Don't Test CodeHerding Cats
- Enterprise architecture is optionalBizRules Blog