For my blog post Craftsmanship over Execution I had read about teams that were doing Agile, – i.e. Scrum – had practices – i.e. test-driven development. The point by that time concerned that another development team would hear “Oh, they succeeded with Scrum, let’s take Scrum and be successful, too!” There are several reasons why this is a bad idea and I decided to write about some of them.

Introduction

First of all it does not really matter whether you’re doing Agile or not. You may run into the same problem. Why? If you have a project which is successful it will attract the so called Early Majorities and other Innovators. They will try to copy most of the practices. Over the past year I have read and seen one or more of the following patterns happening:

1. The team adopts the practices without understanding why. This is a case of applying Shu-level actions.
2. The dramatically fails with the application of the chosen practices since they don’t their particular situation. They are not context-aware and don’t adapt or adopt to their particular situation at hand.
3. The project team is forced to use the practices from other successful teams but are not involved directly into the decision making about it. (This is a lack of buy-in. Very dangerous. Very harming to the picture of the brought in methodology.)

There are even more patterns. Alistair Cockburn did a great job of writing his thoughts on the errors these teams might run into while trying to adapt another successful methodlogy here and here. Altogether it boils down to some way of Cargo Cult where something is done without understanding why it is necessary.

Extending the methodology

The problem with extending a given set of practices or principles lies in the blind adoption of the name of the methodlogy to another context. Recently there are several terms popping up which build a counter-movement to this habit. For example take a look on Brian Marick’s Artisanal retro-futurism crossed with Team-scale Anarcho-syndicalism movement. In the talk on this movement Marick states that he invented the name for this very reason. Everyone has some understanding of what Agile means or of what Craftsmanship means. But all these persons mean something different with it, have a different association with it – occasionally. This is why he invented such a name for his way to do software development: You have to ask what is meant by the name.

So, when you take Scrum and follow it by the book, you might succeed, you might fail. This depends highly on the amount of practices you add to it. Basically speaking, Scrum is just a framework, a more abstract description on how to software development. There are more managerial points mentioned in the methodology itself and you will not be able to do software development with just the practices mentioned in the books. Sure, TDD is a practice that might help when using Scrum. A story board based planning might also. But these can also help teams not doing Agile or Scrum at all. The point is that Scrum alone is not the key factor that might make you succeed or not. The collaboration between Scrum, your customer and your development team and the added practices can tell you, why you are successful or not. This is context-dependent. (On a side note this is to my understanding the reason why Alistair Cockburn introduced a family of methodologies with Crystal that can be fit for the team at hand.)

Leaving something out

This is another bad way to say: “We succeeded with X.” but forget to state what you left out from the methodology to do so. For example there are several practices in XP. Some of the them might be worthwhile to try out immediately, for others you will clearly need more time and experience to build them up. Kent Beck describes in the Second Edition of extreme Programming explained some of these dependencies among practices by dividing them into first and second level practices. For example it’s hard to get a fully automated build with all unit tests passing, if these unit tests still take three hours to run and a big deal of manual efforts to run. Continuous Integration does not make sense in this context. But what should the team state when they succeeded? “We applied XP, but left out Continuous Integration.”? Would make sense, if you’re not context-aware. Everyone else might then start over and apply XP without Continuous Integration, though they have a fast build already in place.

This topic does not only hold for Agile methodologies. Recently I attended a short Lessons Learned workshop for a smaller project at work. My company introduced a new project methodology over the past one and a half years. We reflected over the degree we had applied this new project methodology. When we realized that we had left-out significant portions of the methodology itself, I raised this point. If we simply stated that we applied the new methodology to look good in front of our executives, we would betray the remaining projects that struggled with it. This is why we had to state the obvious to us, that we did not apply everything from the methodology in order to be able to see patterns when other teams do this, too, in the future.

What should I do tomorrow?

Constructing a methodology takes care and needs experience. In the past I tried to do so several times and failed significantly with it. Sure, there were times I had success with it, but these seem to be rare considering my roughly four years of experience in the software business after leaving university overall. What has helped me in the rare occasions is having read through Alistair Cockburn second edition of Agile Software Development – The Cooperative Game, among many, many other books, blogs and articles on the web. Reflecting over the course of your efforts helps to improve while doing so. Maybe over time you might see patterns of successful behavior – but don’t count on it. As a team member you can lead your managers and leaders to these changes over time with some patience. It’s a worthwhile thing to do and personally I state that I like to work on this level. Beneath the work on the project itself, it makes me aware of our process and see opportunities for improvement while doing so. Indeed, everyone should be a methodologist.