In June 2012 I gave a talk at QCon New York titled ‘Agile people over Agile process’. The full talk is here, and below are some of my thoughts on this topic.
Summary
What’s below is pretty long so if you don’t want to read it all, here’s the essence of my opinion.
In the ‘agile world’ these days I see a decent amount of pre-defined, unarguable, process and dogma – the very things that the agile movement initially tried to do away with. I think it’s worth stepping away from this and focussing first on individuals, how they communicate, and how as a team they best choose their techniques and tools
There are no such things as ‘best practices’, at least when it comes to being part of a software team or software project. There are practices that teams find useful within their context, but each context is different. Teams would do well to continually re-judge what process and tooling works best for them.
Agile teams can use values and principles to help drive their choice of process and tools.
So let’s begin…
There’s too much focus on process
When I got started in the agile world 10+ years ago we used to talk a lot about extreme programming (XP), Scrum, and the like. Obviously part of that was figuring out test driven development, pair programming, continuous integration, iterations, etc. A lot of it was also about how we needed to change as individuals though. Gone were the times where we could just sit in our cubicle and complete our individual tasks on the almighty gantt chart. No longer could we assume that we didn’t need to test code because that was someone else’s responsibility. We needed to embrace how we worked as a collaborative team, and not just argue over Emacs vs Vi. This was a revolution in how we identified as humans on a software project.
People back then accused XP of being a developer-focused methodology, and they were right, but this was with good reason. For developers to be most effective they needed to stop just being pawns in a bigger process and start talking to people, work with feedback, and take responsibility for delivery. XP helped them do this.
People in the agile world still talk a lot about Scrum, lean, kanban, etc., just like we used to 10 years ago. However I feel the tone of a lot of conversations has changed – now a lot of times it’s just about the process. Agile seems to no longer be about people changing their attitude to projects, to delivery or most importantly to people. Now often it’s just about introducing a new team management methodology in the hope that Lean or XP or whatever will be a process magic bullet that will solve all their problems.
But with process, as with many other things, there is no magic bullet.
Process is very important. It’s where the rubber of any methodology hits the road, but there are problems with an overly-zealous focus on process:
- Processes can become kings. Processes are at the end of the day just tools – they have no intrinsic value by themselves. They can only be judged valuable in the context of their application. When processes become kings then our discussions descend to hypothetical judgments of a supposed intrinsic value that the processes don’t have. Such discussions are a waste of time and don’t help anyone.
- If processes are considered axiomatic then we can no longer adapt how we work. If we believe the best way to do something is X, yet we do not understand the motivation for X, how can we decide if Y would be better?
- It misses the the point of what Agile was supposed to be about…
What I think is important about Agile
The Agile Manifesto starts as follows:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools…
In other words the unique characteristics, personalities and abilities of members of a software development team, and the conversations that they have with each other and with their stakeholders (management, users, etc.) are worth considering more than the process and tools that they use.
This is not to say at all that processes and tools are unimportant, I am merely arguing that that they are not so important that they should drive discussion about the basic way we choose to deliver software.
Focussing on individuals sounds like a management technique. While that is important, I think it is more a call to individuals themselves to consider how they can most effectively be part of a software delivery effort.
There are many ways individuals can answer this call, but one way that may be useful is to look at the values and principles from ‘Extreme Programming Explained‘ – Kent Beck’s original book about XP. These values and principals are not specific descriptions of how to do something but guides to help people decide how they actually want to work. I’m not going to go into detail here since literature is already available for each point (and I also discuss further in my talk at around the 13 minute mark), but a list of ideas is as follows:
Values
- Simplicity
- Communication
- Feedback
- Courage
Principles
- Assume the values are present
- Incremental change
- Deliver at the earliest responsible time (an addition / variant of mine that I think is worth considering separately)
- Quality (the Jim Highsmith article I refer to in the talk is here)
- Accepted responsibility – everyone on the team should assume they have responsibility
- Local adaptation – change everything according to context
How this applies to practice
These values and principles are all somewhat theoretical – the application of them is the actual choice of what set of practices and processes a team choose to use. Not one pre-defined overall process, but an active, continuing choice of what techniques to use.
This is necessary since in the case of software development teams and projects, there are no such things as best practices. There are practices that teams find useful within their own context, but this is not an absolute categorization.
How I’ve recently embraced this
In the video I describe how I applied these ideas on my most recent project. It starts at about the 28 minute mark. It made sense to include this in the talk but I’m going to leave detail out of this post.
It is worth mentioning here though that there are certain ‘typical practices’ of agile that we did use but others that we chose not to. For example we didn’t use ‘iterations’ to structure our week-to-week work. However we did often deploy new software, we frequently re-prioritized our next work, etc. Since we already did these things formal iterations in our world would have been unnecessary baggage. For many other teams formal iterations would be very valuable.
Is this really for everyone?
In discussing this subject some people have challenged me that this way of thinking is only useful for ‘experts’, such as people who already have previous agile experience. I disagree. While I think that picking an off-the-shelf methodology might make for a ‘decent first set’ of practices I think a team needs to know from the beginning some amount of why that may be so. I think for someone with experience to provide a pre-canned process set as ‘the way things should be’ is disingenuous.
I wouldn’t expect everyone on a team new to agile to be able to immediately make their own choices about the entire implementation of principle to practice, but I would expect them to know that the introspection of their process (based on values and principles), and their subsequent refinement of the same, is a more important aspect of agile development than any of the individual techniques they may be using.
Concluding thoughts
None of this is new at all, and a lot of the good agile literature from the last decade describes these ideas. As a more recent example Ross Pettit does a good job talking about them here.
I think it’s worthwhile repeating it though for 2 reasons:
- I see some amount of the agile community as a whole moving to a ‘process first’ mindset and I disagree with it.
- I’ve seen myself at times throughout my career treating process, practice or technique as dogmatic. Invariably when I do this it’s because I’ve missed something important. Stepping back and thinking ‘why’ always leads to improvement. I think this is a valuable reminder to myself and hopefully others.
My first computer was an 
In our second year at college Mike and I shared a house with a few friends, so the networking in my machine got upgraded to have a BNC ethernet card. It was around this time that storing music as MP3 format started – it used to take 2 – 3 hours to rip a CD on my computer. Winamp was the music player of choice. I had an 
I continued tinkering with my tower-case enclosed PCs over the first 3 years or so after college. I also bought my first laptop around this time. In 2002-ish I bought my first Shuttle ‘small form factor’ PC. This was a speedy machine, and also (for the time) tiny. I added a 2nd Shuttle to allow further tinkering.
The iMac was great and I was still using it through until last summer – not bad for a 6 year old machine. In this period I only upgraded one piece of hardware – giving it a slight RAM upgrade to 3GB. My years of constant hardware tinkering were over.
Mike Roberts