Do agile methods help improve software? It seems they often don’t

Just the other day I was asked what I think about Agile Methods during a coffee break on our Refactoring / Unit Testing Workshop. My very first reaction was: I think it’s a become money machine.

The reaction was somewhat puzzled. Then I went on to explain that the ideas of getting rid of a lot of bad working practices like planning everything upfront and forcefully sticking to the schedule are of course great. Keeping communication within a team alive, staying in close contact with stakeholders, being able to change directions in very short timeframes and holding the stakeholder responsible for all changes by letting them decide are great ideas.
But no agile method, whatever it may be called or whoever may have come up with it, is going to heal anything if a team follows it relegiously.

The fact that agile has turned into a big merchandising industry, from books, conferences, certifications to buttons, t-shirts and maybe even underwear (you never know…) makes me sceptic. Not that I think it doesn’t work, but I’m afraid it mostly enables quite a few people to sell their consulting time and written material and may be promising enough to make people buy stuff while it doesn’t work good enough for people to adapt it easily and/or succesfully. All of that is not bad per se. I do a bit of consulting and try to think some of the teams I consult profit from it, but I am seldomly selling a ready-made concept or methodology. The art of consulting lies in helping people find their own pace.

This piece of Gerald Weinberg is a great summary of what I mean by all that. If you only have 30 seconds to learn about his conclusions, I’d recommed you this gem:

Those installations and individuals who have successfully realized the promised benefits of agile programming tend to be the ones who don’t buy the typical hardware or software pitch, but who listen to the pitch and extract what they decide they need for solving their problems. They do their own thinking, which includes using the thoughts of others, if they’re applicable. By and large, they were the most successful problem solvers before agile programming, and are now even more successful.

If you even have 6 minutes, read the full article. It’s not new, but it’s excellent, especially his observatiosn and conclusions are worth thinking about.

I agree to almost all of it. I am not sure if and how you could see if a piece of code was written using agile methods, but the numbers he gives are discouraging, because roughly 100% of the code he looked at was not much better than the code written by non-agile teams. So the hope for higher maintainability and quality seems to be unfulfilled.

Does it mean we should condemn agile methods, eXtreme programming and friends altogether? No. I think it means we should use ideas like “Agile” to reflect on what it can do for our specific project or team. There’s a lot of inspiration in what people write about their approaches to overcome certain problems and their experiences with them.
But we always have to choose carefully what we adapt for our teams.

I haven’t yet seen a team that really got anything from reproducing a methodology and making it their new way of life/working.   All they are is a bunch of people pretending to be cool and changing the world whilst ignoring they only replace a well-understood problem with a badly understood “solution”.

But when I visit a team that has adapted maybe one or two ideas and made them a well-understood, common-sense part of their daily work, maybe even tried a few more and stopped using them when it turned out they don’t work for them, I often get the impression they’ve made progress in quality and productivity. Funnily, these teams would never present themselves by “We’re agile” while being much more agile in the sense of speed and quality than those who would.


5 thoughts on “Do agile methods help improve software? It seems they often don’t

  1. Hi,
    gud article Agile Methods only apply to the software “development” portion of the lifecycle and certainly
    don’t apply to the software maintenance portion of the lifecycle.

  2. IMHO you don’t get what agile development is about at all. Agile is not about producing higher quality code, you can accomplish the same level with waterfall models. Agile is about stopping to ignore how requirements develop in reality. It’s not that nobody commits anymore and managers like to change their mind too often. Requirements evolve over time just as code. Agile is about accepting that as something natural and structuring your code and processes to accommodate to that.

    1. Christoph,

      isn’t that a sad statement?
      I mean, meeting requirements is important, and keeping the customer responsible for changes is good and important. Short cycles and fast feedback to the customer are important. But not caring about code quality is of course a very stupid move. Long term cost of such decisions is extremely high.
      I don’t think I am not getting it. I think it’s not a good idea to stamp whatever label onto your project and try to follow some methodology pope like a bunch of brainwashed monks without reflecting about whether a mix of techniques is good or bad. And believe me, there’s a lot of brainwash out there. To me it seems there are lots of developers and managers out there who asks for it!
      I am trying to make a point by asking people to chose carefully and find out what works and what doesn’t. Nobody will ever build a statue for you because you’re agile, eXtreme or scrumnmy. But they will probably love your product (and therefor your team) if it meets requirements and proves to be maintainable and extendable when needed. Maybe some techniques help you stay on track with your budget and still meet the most important requirements. Maybe others, however, force you to write ugly and expensive code in the long run. Try to pick and do what’s best for you. In the end, it’s never a technique that makes you as an individual developer or team better. It’s never your faith in A or B that makes you more effective. The only thing is experimenting and trying things out and having the experience to find out what you shouldn’t do (any more).

  3. To my time at the university it was not all complete top down. But something very theoretical structured. And all the programming courses had one thing in common the ignorance for programming. It was analyses, design and full stop. I always hated this approaches with just says first do that then that and yes do not forget to implement it finally. This is not as I experienced programming is working. I may just blame it on me. But my way is always. Think about the problem and try to implement the base idea as fast as I can. Till today I never was unhappy with the outcome. Yes I throwed away code and retried things but seeing the “stuff” in action always was the biggest incentive and yes joy. In the way like “yes that seems quite ok” Maybe someone else works different, but all the programmers I’ve worked with up till today want the thing running. If that is what agile has taught some, then I think it has some really good work. Anyway I still think programming is under appreciated. And I’ve to admit if I see jobs like system architect or the like I’m fed up.

    Maybe it’s beause of my “attitude” towards programming that I do like Smalltalk that much. And that I do not have find a hang to Haskell e.g I for my part like the cycle of “try-and-error” I easily can have in Smalltalk also. Maybe this was the reason I also liked Common Lisp quite much. I don’t know maybe it’s like in the stories of Harry Poter. Maybe it’s true that the languages chooses it’s follower and not the other way.

    1. Friedrich,

      I fully agree. The whole point of my post was not to say that agile methods are bad per se. It’s bad that people try to follow them without reflecting them and chosing what’s right for them. And I think Weinberg’s observations underline this. If you find ideas that fit into your team and make you faster and better, by all means go agile. But don’t think that using any of the agile books as the ten commandments for your new programmer’s life will improve anything. You’ll just make your team unhappy, frustrated and probably have a very bad impact on code quality.
      Will it be the fault of teh Agile Popes? Not really.

Comments are closed.