One Size Does Not Fit All

 Recently I wanted to buy a new pair of trousers. I know that I’m 38 short (I know. I need to lose weight.) The 38 short was the easy part. I know that I’m not slim fit, but how Regular am I? Am I a Hilfiger Regular or a Levi’s Regular? If I pick carelessly, I could end up looking like I need to visit a bathroom, or look like the rear end of an elephant.

That made me think about how we pick software development methodologies. What can I say? It’s geek creep.

There appears to a weird perception that only one magical methodology can be used on a specific project and that this approach must apply to all phases and teams of the project.

It is possible to combine the best features of different methodologies.

For example, up-front design could conform to the concept of “Just Enough Software Architecture” (Fairbanks).  Evans of “Domain-Driven Design” did an interesting video with the same argument. The development cycle that follows could then be XP with pair programming. Leffingwell suggests this as a combination of RUP and Agile (“Scaling Software Agility”). Team management could use Scrums.

In defense of the indefensible, Waterfall actually places a strong emphasis on prototypes and proof of concepts. The Waterfall downfall is that the requirements phase tends to take so long that by the time it is completed, the requirements have changed or the solution is no longer needed.

Agile attempts to reduce this lead time by continuous ‘prototyping’ in collaboration with the customer.

To assail the unassailable, ‘Agile’ is not one methodology but a series of methodologies, some of which predate Waterfall. For example, scrums are not dissimilar from project briefing and debriefing regularly used for pilots on missions. The issue of Undisciplined Agile (Fragile) is that it encourages bad behaviors. It encourages an attitude that users are basically stupid and don’t know what they want, and there is so much emphasis on progress (burn rate) that often the most critical tasks are deferred. I have seen several ‘complete’ Agile projects which provided only a user interface with no concept of data persistence.

The important thing to remember about Agile is that it is not a methodology, but a series of methodologies formalized in the Agile Manifesto. If you look at the signers of this document, you see a whole lot of different approaches. Beck and Cunningham (XP), Sutherland and Schwaber (SCRUM). Then here are the other evangelists, each with their own focus: Poppendieck (Lean), Ambler (Agile Modeling). Everyone uses Agile. The issue is what flavor of agile.

The most important thing to decide on a project is not the methodology to use, but a decision about what has to be achieved and the best mix of methodologies to use to achieve that goal. In fact, Cockburn (Crystal Clear) suggests minimal methodology up-front and adding the methodologies as required. This is interesting as Cockburn’s book “Crystal Clear” was based on the results of examining successful projects to see what made them work. (And Cockburn must be correct since he is a signer of the Agile Manifesto).

If the chosen methodology does not work, modify it or throw it out. It is not a loss. You got this far as a result of the chosen methodology. It served its purpose. Now find one which fits the next stage.

So, I think I’ll go to the stores and try on the jeans. Until you actually try something, it is hard to know if it really fits. After all, one size does not fit all.

Cockburn, Alistair. “Crystal Clear: A Human-Powered Methodology for Small Teams: A Human-Powered Methodology for Small Teams.” Addison-Wesley Professional, 2004. http://www.amazon.com/Crystal-Clear-Human-Powered-Methodology-Small/dp/0201699478/ref=sr_1_2?ie=UTF8&qid=1393085241&sr=8-2&keywords=crystal+clear

Evans, Eric. “Domain-Driven Design: Tackling Complexity in the Heart of Software.“  Addison-Wesley Professional, 2003. http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1?ie=UTF8&qid=1393084938&sr=8-1&keywords=evans+domain

Fairbanks, George F. Just Enough Software Architecture.” Marshall & Brainerd, 2010. http://www.amazon.com/Just-Enough-Software-Architecture-Risk-Driven/dp/0984618104/ref=sr_1_1?ie=UTF8&qid=1393084853&sr=8-1&keywords=fairbanks+architecture

Leffingwell, Dean “Scaling Software Agility: Best Practices for Large Enterprises.” Addison-Wesley Professional, 2007. http://www.amazon.com/Scaling-Software-Agility-Practices-Enterprises/dp/0321458192/ref=sr_1_1?ie=UTF8&qid=1393085158&sr=8-1&keywords=Leffingwell+scaling

Royce, Winston W, “Managing the Development of Large Software Systems.” http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf