Recently Alistair Cockburn invited 32 agile practitioners to join him at the Snowbird ski resort, for a retrospective on the agile movement as a whole. I followed the event via Twitter, sitting under a sun umbrella here in the southern hemisphere, reading the tweets from the snow.
The event was both a celebration of the first 10 years of agile, and an attempt to answer three questions which Alistair circulated before the meeting:
- What problems in software or product development have we solved (and therefore should not simply keep re-solving)?
- What problems are fundamentally unsolvable (so therefore we should not keep trying to “solve” them)?
- What problems can we sensibly address – problems that we can mitigate either with money, effort or innovation? (and therefore, these are the problems we should set our attention to, next.)
There was clearly much to celebrate from the past 10 years of agile, but when it came to the future, there seemed to be concerns in several areas: the slowness with which good practices are adopted in some quarters; the risk of losing momentum now that there is no longer a common “enemy” (as heavy process was, when agile began); and a perceived lack of strength, clarity and consensus in the group’s answer to Alistair’s third question – “what next?”
Reflecting on those concerns, here are my “ah-has” from my virtual participation:
Gradual Change is Normal (Part 1)
Mike Cohn wrote a great post likening agile to Object Orientation. Eventually, OO was taken for granted, and people stopped talking about it. He suggests that agile will go the same way, and I agree.
However, these things can take a really, really long time. Here’s an example, that extends Mike’s OO one: By the late 90’s, OO had blossomed so much that the premier OO conference, OOPSLA, moved away from its original goal of making OO practical and understandable. OOPSLA’s work was done. But, at the turn of the century, there were still a lot of people who weren’t using OO. Legions of VB6 developers making business apps on the Microsoft platform were not using OO at all. Slowly, over the decade that followed, OO seeped into the Microsoft development community. Languages were replaced and improved, and starting in about 2007 we saw wide adoption of Object-Relational Mapping and a variant of Smalltalk’s decades-old Model-View-Presenter pattern. (Yes, Microsoft played a role in the timing, but so did changing sentiment within the developer community.)
There are two key things to note from this example:
- We are currently seeing (real) OO go mainstream in the Microsoft community – about a decade after it went mainstream in most other parts of the development community.
- This happened without any industry association driving it. There was no equivalent to the Agile Alliance, cajoling Microsoft developers into using Objects. There was no need for such a body, because OO had become adequately embedded in the industry’s consciousness back in the 90s. It was like a virus that had infected enough of the population that it could no longer be eliminated. Slowly, over the decade that followed, it reached the rest.
So don’t sweat it. Agile isn’t going away. It will continue to influence people, and to be embraced by new users, long after the early adopters have taken it for granted and stopped talking about it.
Gradual Change is Normal (Part 2)
In a post on his delightfully-named blog, Jonathan House wrote the following after the Snowbird event:
Does Agile really make a difference? – Not so much a question that showed up at the conference, but one that kept running around in my head, kicking over garbage cans and spray-painting the cat. … It’s clear we’ve made excellent progress over the past 10 years, but it’s still not so clear to me why businesses aren’t beating down the door to really adopt Agile throughout the enterprise …
Jonathan, I’m fairly sure this is not a reflection on agile. It is reflection on business. Business leaders often fail to follow advice, even when they actually agree that the advice is good. I don’t say this out of personal dissatisfaction; it is a well-researched fact. There’s even a book on the subject, called The Knowing-Doing Gap by Jeff Pfeffer and Bob Sutton. (I mentioned Pfeffer and Sutton in my Agile Roots talk. As an agilist and geek, I find their work extremely credible and relevant).
I am convinced that you are observing not a failure in agile, but a significant problem in business in general.
(Having said that, it wouldn’t hurt if we in the agile community could familiarize ourselves with how the more self-aware sections of business community do already understand agile, just with different words and under different names. It will be much more polite, and therefore more likely to succeed, if we listen before we lecture).
Diversity is Good
I think some people who were following the Snowbird event may have been disappointed at an apparent lack of consensus. I know I was, at first. But then I remembered that diversity is good. Think of the importance of genetic diversity in populations of animals; remember how the messy diversity of capitalism out-performed Soviet central planning; and think back to the diversity of the original 17 signatories to the Agile Manifesto – a diversity which was alive and well both before and after they signed the Manifesto.
By having a range of people, with differing interests and priorities, the agile community is much more likely to successfully address the many and varied challenges of the next decade.
I think the point with diversity is not just to accept it, but to actually encourage it. Good agile, particularly by experienced practitioners, will be situationally specific. I suspect this point has not fully seeped into the overall consciousness of the wider agile community. Perhaps one of the tasks for the next 10 years is to promote the acceptance of “situationally specific agile”, and to help people learn (i.e. practice) how to do it.
There is Plenty to Do
Several people pointed out that agile lacks a clear “enemy” now. When agile started, heavyweight process was the enemy. But today there is no clearly-identifiable external enemy. So what is the point of the agile movement now?
David Anderson seemed to reflect the mood of the group when he wrote:
The mission now is incremental improvement. It’s evolution, education and improving levels of maturity, rather than a revolution. The enemy is now within. The enemy is as Joshua Kerievsky put it “all the crap I see out there” despite 10 years of Agile methods.
David Anderson went on to write
I don’t believe the Agile movement knows how to operate without something to revolt against. Agile came, it served its purpose, it had a positive effect. What next? Perhaps it is time to move on?
Is the really nothing more to do? Nothing more but combating the enemies within, of complacency and poor execution? I can see the logic of what Joshua and David (and others) are saying, but please, please don’t let it be true! There is so much more to do. Here are just a few topics that come to mind:
- The spread of agile beyond software (as per Jonathan House’s comment above, and others on the day)
- Jeff Patton’s story mapping and feature thinning – two wonderful techniques which deserve to become much more prominent in agile’s second decade
- Advancement of knowledge/skill in Ri-level/situationally-specific agile
- Philippe Kruchten’s herd of elephants (elaborated/commented on here by Scott Ambler)
- Really paying attention to “Individuals and Interactions”. For 10 years we’ve been getting this first point of the Agile Manifesto round the wrong way!! So you can’t tell me there’s nothing left to do ;-) James Coplien phrased it well in his outstanding reflection on the first 10 years: “We have test scripts and jUnit trumping individuals and interactions”.
- Sharing our failures as well as our successes, as several people mentioned on the day
- Contracts for agile projects – currently, only a partially-solved problem at best.
We’ve only been doing knowledge work in teams for a short part of human history. The previous millennia did not prepare us well for the last few decades of complex, abstract, co-operation in non-trivial teams. So of course this is still more to learn.
Summary
We need to keep thinking, keep talking and keep learning.
We need to keep agile’s sense of humanity – of valuing, respecting and caring for people in the workplace.
We need to retain and treasure the global and local communities of practitioners, which the agile movement has created.
We need to keep all these things, even though there is no longer a common enemy to unite us. We need to learn to operate in an agile community that doesn’t just accept, but actively promotes, its own diversity.
I recently stumbled across a quote from the French poet Stéphane Mallarmé:
to define is to kill, to suggest is to create
Let us not define our future. Let’s suggest it.
