Nowadays everyone is agile. Or at least they say. Most organisations use Scrum. Or they claim to do it, while still doing waterfall. But why is the industry so focused on Scrum? What happened to eXtreme Programming? Why did we loose the XP practices? Is it too extreme?
The first agile methodology I heard of was eXtreme Programming back in 2001 when I was a CS student and read the eXtreme Programming Explained book by Kent Beck (published 1999). I remember reading about the ideas of pair programming, refactoring, test driven development and simple/evolutionary design and thinking that this is the future. The planning game and user story for requirements parts was nothing I payed that much attention to – I was completely focused on the code writing at that time.
Scrum is a few years older than XP, being launched in 1995 by Jeff Sutherland and Ken Schwaber. If you’re a regular reader of my blog you know that I have thought and written quite a lot about Scrum but very little about XP. The reason is that I’ve been quite focused on the management view of agile projects in order to get the customer interaction working. While XP is a bit vague (and too extreme with a customer full time on the team), Scrum offers a set of rules that is easy to get started with and easy to explain to the customer.
I think that I’m not the only one being dragged to Scrum because of the relative ease of getting started combined with the focus on the relation with the customer. Add to that the fact that most managers that are involved in methodology selection understand the core Scrum process, but without a strong foundation in development most XP practices make no sense. From a “marketing to management” perspective Scrum is easier to argue for and has become the de facto standard agile methodology.
But I think that we lost something along the way. We lost the technical XP practices that are an important foundation for the ability to be agile. Without those technical practices, can a Scrum team really become truly agile?
Technical skills is the core of any development project. In the end it is the skilled programmers that write the code that forms the product. Everything else is just support to ensure the coders develop the right features in the right order. But somehow management tend to look at the developers as the lowest level in the project hierarchy. How come that the respect for developers and their technical skills get lost?
Having been on a number of projects it’s evident that technical skills matters. They not only matters but are crucial. All processes (agile or whatever) are only there to support the technically skilled who write the code. In fact, the more skilled developers, the less need for tight processes. The then ground breaking Extreme Programming Explained: Embrace Change argued for tearing down most of the then dominant, heavy weight processes and instead trust the developers. It was of course a success, but not only because of the process. It was a success mostly because of the people.
With Kent Beck and Martin Fowler on the same team the process doesn’t matter. They would probably succeed in a heavily regulated waterfall process, coding on punch cards with needles by hand.
But to really unleash the power of such a team it’s best to give them freedom to do their magic and stay out of the way.
That’s exactly what eXtreme Programming is about: Connect the users/customers directly to the development team and keep management out of the way. It worked in the Chrysler C3 project because of the skilled people involved. It works in any project with a skilled team.
What does a developer gain by embracing Scrum? I’m a strong believer of Scrum, but some time ago, I got my beliefs questioned. That is always good because it forces one to think them over again and reason about why one believe in certain things.
It was not until several months later that I realised how much I learnt from having my beliefs questioned. At the time, I guess it was too painful for me to find out that things I thought were universal truths where merely my own beliefs. Working on a project with a plan that is constantly moving (even on things where coding has started) makes me feel uncomfortable, so for me as a developer, scrum is a way to make me feel better. I don’t need any more arguments for why I should embrace scrum. When I was faced with the question “why” it was an awkward experience, because I didn’t have any good answer.
To be honest, my first instinct was that becoming more professional is sufficient as an argument. But when I think deeper of it, that is not a good answer. Just because I find it so important to be professional that I see it as a value in itself, that doesn’t mean that everyone else does. No, I have to answer the question:
What’s in it for me as a developer, if we adopt scrum?
A friend of mine told me about an organisation in trouble: They were too firmly attached to their processes to improve when needed. The strict process that was followed? Agile (Scrum to be specific).
I’m sorry if I just caused some of you to swallow your coffee down the wrong pipe, but it’s true: Using an agile process the wrong way can give exactly the same problems as the agile movement try to extinguish.
The reason that this occurs is that most articles teaching agile practices (including my own) are very prescriptive. Do this! Don’t do that!
For beginners that’s great and that’s what they need, but for teams that have some experience it is time to bend the rules when needed. The best way to describe this that I’ve found is Shu Ha Ri. The term originates from Aikido, but is frequently used within the agile community to describe the different phases of agile adaption.