Did Agile Ruin your Life?

Daniel Markham has written a rant about how many people feel that Agile has “ruined their lives”. Basically, he is saying that to these people Agile is just a new name for snake oil. Agile coaches are nothing but scamsters. The books they write are nothing but positively biased stories about their own “success”.

There are two things in the post that I cannot refrain from commenting on. First, in one comment someonone writes that agile methods were originally developped for web development projects. Second, in the main post and many of the comments there is a discussion about people who are not masters cannot be coaches.

Fitness

Agile is best for web projects, or so my experience has taught me. There really is such a thing as different methods in software engineering being fit for different purposes, I have performed research that supports this claim.

I have been the scrum master/product owner/project manager/coach for a number of agile projects of different sizes and kinds over the last few years. There is no doubt in my mind that agile practices are best suited for three-tier web-development projects. In these projects it is clear who the customer is. Making vertical slices of functionality is no big problem. The requirements can be discussed with the customer. Monthly or even more frequent releases are needed to keep the web site fresh and attractive to net users.

In a research study conducted a few years ago by me and my colleague Jürgen Börstler we found something like this for the object oriented development paradigm. We studied the outcome of a course where students were developing different software products for real live companies. One thing we found, if
memory serves, was that having a good project plan at the start of the project was indicative of a good customer satisfaction at the end of the project. Is that anti-agile? On the interesting findings.

We had identified that students generally worked on three types of projects: Editors, web-applications and data-flow applications. The type of project did not have any significant impact on the final outcome but it did have a
major impact on the deliverables that the students had to produce which were directly related to the object oriented analysis and design. Students working with editor applications were much more likely to get good grades on these deliverables.

So if agile is best for web projects, is it then useless for other projects? As Daniel and commenters pointed out in the rant – there is no definition for Agile. It is simply a fancy name for a collection of best practices, methods, techniques, values, principles and tools. Some of which are even false or contradictory but that is another story. Many of these things can be applied in any project to achieve some kind of improvement. This is where the agile coach comes in.

Coach

Daniel seems to think that an agile coach must be some form of “master software” engineer/craftsman/etc. Why should you take advice from someone who earns less than yourself? I think this is wrong and misleading. Who coaches a world class athlete? Universe class athletes? Of course not. Do you even have to be a retired former X star to be a world class coach? Of course not. World class athletes are coached by a range of people including sports psychologists, physiotherapists, strength coaches, tactics coaches and so on.

Being a coach requires knowledge about the topic you are coaching on but not always personal mastery. It requires being able to listen, to monitor progress, to have compassion and passion to improve your clients performance. It requires being able to bring a number of options to your client to let them grow and improve.

Of course, we might want to differentiate between specialists and generalists. You might (be required to) go to a generalist doctor before you are sent to a specialist doctor. The same might be true with coaches. As a generalist, I might be able to recommend to a client that they start with unit testing – as indeed I have done earlier on this blog – but if the client wants someone to pair program unit tests with their clients for a month they might have to find a coach who specializes in that.

There seems to be a perception that you either do agile by the book or not at all. In one of the canonical scrum books the author writes something like do not attempt to change the process before you have mastered it. Anyone who comes with a cookbook solution to an organizations problems is not really doing coaching at all. And I wonder if they can really be successful at all?

It seems to me that to be counted as a successful software professional a person must do at least one of the following three things. 1) Write a book. 2) Write a blog. 3) Make his/her name visible as a (co-)developer of some framework. (See for instance this recent listing of the top software professionals in Sweden.) Naturally, people with some writing proficiency will want to write a book. Often their best contribution will be to write about their personal stories. And that leads to the kind of books that Daniel rants about.

Any organizational change project has three essential components:
determining the current state, envisioning the desired state, and working to move from the former to the latter. The agile cookbook coach skips two of the three steps and thinks it is possible to move directly to the goal. Sort of like the “go directly to jail” card in monopoly. Is that a recipe for success?

To be successful as an agent of change, the agile coach must meet the client with humility and a listening approach. Not everything the client is doing is wrong – maybe nothing they are doing is plain wrong; it just needs improvement. Otherwise, they would not be successful enough so that they could even hire the agile coach in the first place. Right? A coach who starts with his own version of what reality is may be right but will not be heard. Advice requires a receiver not just a transmitter. If no one is listening to the agile coach – can you hear him/her fall?

I have seen many examples where organizations have used agile coaches to setup something which is far from agile and calling it agile. It is clear that this is doomed to failure from the onset and it will create even more people who are convinced that agile ruined their lives.

Waterfall

But is anyone NOT doing agile? Agile coaches and advocates often compare with the waterfall method. I have to admit that even I often use this comparison to create a clear contrast to highlight the strengths and weaknesses of agile development. The effect is stunning because it is like saying that look, if you do something stupid things will be bad will if you do something smart things will be good.

I have never worked on a project that was not iterative and incremental. Perhaps such projects exists but I have never seen one. Real life software development starts with an existing code base and improves on that in small, often quarterly, increments. What I have seen though is a lot of people doing FAKE waterfall development. That is that they pretend to be doing waterfall development while they are in reality working in a highly iterative and incremental development style.

There are at least three major vulnerabilities with fake waterfall:

1. People create a lot of documents which no one ever cares about so some
   effort is wasted.
2. Fake waterfall makes companies vulnerable to snake oil coaches.
3. Some people (my ethics do not allow me to give names here 🙂 ) actually
   believe in the waterfall fiction and do not understand that they should just
   be going through the motions not religiously enforce them.

Summary

Pre-packaged agile methods might not be right for your company. A good coach can help you improve from where you stand today. Contrary to what the snake oil coaches tells you, no one starts from scratch.