Gwarred Mountain over at Climax Studios has posted a very thoughtful blog post about software development methods and the appropriateness of Agile Software Development. I was ready not to like this article, what with the title and things like this:
If I have to sit through another meeting with some little “agile” toe-rag defending their train wreck of a project then I may end up forcibly ramming a kanban where the scrum does not shine.
But then I thought about all of those fresh-faced management consultants we’ve run into recently — who have read a book about agile — trying to teach us how to do it. Well, yes. I’ve had some uncharitable thoughts myself.
Surprisingly, I felt myself agreeing with most of what he wrote. No, Agile is no panacea. Yes, it works best on small to medium sized projects. Yes, you have to have an experienced team to do it well. Yes, there are other methods that are more appropriate in some cases and, yes, you have to recognize when to use something else than an agile approach.
His breakdown of people vs process is one of the many nicely coherent gems in the post:
So what is so great about process? Well, it gives us:
- Repeatable and predictable results
- Quality Assurances (through the above)
- Cost savings through the ability to optimise work flows
- Defined work flow allows us to use cheaper labour
- The promotion of best practices and conceptual integrity
- The ability to scale to large numbers
- A means to effectively track our progress against the objectives
McDonalds is a great example of successful process. No matter where you are in the world, you know what you are going to get and you get it quickly and cheaply. This process has successfully scaled to thousands of restaurants. Whether you consider this good or bad it is hard to argue with the results.
Nevertheless, software development is much harder than frying beef burgers. Process is sometimes inappropriate or unconstructive.
I’d say the lesson from his post is that you need to be thoughtful about the software development and project management technique you adopt. Know why you are doing things. Any process that has magical rituals rather than purposeful activities has a good chance of devolving into a software development farce.
There is one thing with which I take issue. He states that Test Driven Development (TDD) adds from 15%-35% to development effort. He cites an empirical Microsoft Research study. The paper, authored by Nagappan, et. al., is one that I am well familiar with. The study looks at four case studies, one at IBM and three at Microsoft, where two teams are given the same system to implement. Everything is the same except in one team incorporates TDD into their process. Neither team is told they are part of a study.
It isn’t clear from the paper, but in my experience teams that adopt a new technique or tool usually are not as efficient the first time around. Certainly that is born out by our own empirical observations — developers that are performing TDD for the first time are anywhere from 10%-30% less productive. That starts to move toward 0% after the first project. It becomes second nature. And as the study itself makes clear, the productivity losses in the study would be more than made up for in the maintenance phase of the software life-cycle, where 80% of software product costs land anyway.
Let’s see, lower defect rates, no productivity loss after a little bit of developer training and reduced cost in the maintenance phase? Sounds like a no-brainer to me. Of course I don’t know Mr. Mountain’s industry. It may be that there is no maintenance in the game development space, just code and release. No updates. So rush to release, bugs be damned may be the best way to go (not being facetious here).
The fact that this study comes out of Microsoft already sets some alarm bells ringing for me. Although we’re headquartered in Chicago now, we actually were founded in Seattle, physically and intellectually not far from the Microsoft campus. Based on what we saw working at and for Microsoft, we soon began a physical and intellectual journey away from there that has landed us in Chicago as a premier User Driven Software Product Development shop. We use experienced teams, User Experience Design (UXD) and are thoughtful about how and why we practice Agile.
We may not be everyone’s cup of tea, but if you have a consumer or business software product or service that you need to get out to the marketplace swiftly, reliably and with high quality, then we may well be a fit for you.
