I recently presented at the Agile Business Conference in London and the ScrumGathering in Minneapolis. This gave me pause for reflection on what has changed in the world of Agile in the year since I last attended these events. The major change from my perspective has been the shift in emphasis to large scale adoption of Agile. What do we mean by scale in this context? One version of scaling Agile means attempting something that is bigger than a single team can efficiently cope with, usually through the deployment of multiple teams working collaboratively, sometimes across geographical boundaries. Another version of scaling Agile occurs after an organisation has seen success with a small number of teams and decides to adopt it as the standard project delivery approach across the organisation.
This shift has been one of the drivers or excuses for some in our profession to foist the term “Agile 2.0” on us all. I dislike “Agile 2.0” even more than the term “Web 2.0” but that’s another story.
What’s wrong with Agile 2.0? Well for starters it’s a conjuring trick to persuade the gullible that what is required to successfully take Agile to the “Enterprise level” is a new agile methodology. Something nice and prescriptive that tells you exactly what you need to do to make an Agile project work so that you never feel out of your depth. The thing is, there has always been a wide choice of Agile “Flavours” or denominations to choose from, with different terminology, processes, roles and artefacts. Having more is fine - as long they respect the fundamental principles on which all truly “Agile” frameworks are based (see the Agile Manifesto and Principles). It’s not fine though when they claim to fundamentally transform Agile thinking whilst not actually delivering anything new – I believe this is referred to as Marketing Spin!
It is the principles and how they are applied that are the key to making a single project team successful and not the details of the specific denomination of Agile. I know many teams that do not subscribe to any particular flavour but are nonetheless both Agile and very successful. This fact makes Agile almost infinitely flexible such that it can and has been applied to many different organisations, cultures, technologies (including non IT projects), team size, team skill and team distribution. So when faced with the challenge of using Agile throughout an organisation or on a programme of development that will need many teams, evolve the way the fundamental principles are applied rather than adopting a different methodology. Sure the context has changed, this just means that the principles may need to be applied in different ways and we need to avoid losing our agility in our quest to keep the reins on our large programme. This isn’t to say that it’s easy. A single Agile team can cause pain when it bumps into organisational impediments, just imagine what a programme of many teams or even organisational wide adoption of Agile can do!
We have been working on a number of scaled Agile programmes in the last year and it was this subject that I decided to present at the Agile Business Conference and ScrumGathering. These events also proved to be a useful sense check on the way we have applied Agile principles in our specific examples against what other large organisations like BT, Amazon.com and LastMinute.com are doing. There seems to be an appetite for information on the kinds of approaches that can be applied in scaled situations so I thought I would share our thinking on the subject through this blog. It is important however to remember that we are presenting some advice and options rather than prescriptive recommendations so you will still need to apply common sense when taking these ideas and considering if and how you might apply them in your specific context.
Part 2 to follow .....