My travels around the landscape of DevOps brought me to Mike Burrows, and the work he was doing around what he terms Agendashift, an outcome-based approach to continuous transformation. While these words could be off-putting, I was more intrigued by the fact that Mike had set up a Slack site to articulate, test and improve his experience-based models – as he says, there’s 500 people on the site now, and as I have experienced, it’s very participative. So, what’s it all about – is there life beyond prescriptive lean and agile approaches? I sat down with Mike (in the virtual sense) to find out the background of, and hopes and dreams for, Agendashift.
1. What led you to write a book about lean/agile/Kanban — what was being missed?
Good question! I’m one of those people that laments the rise of prescription in the Lean-Agile space, and though I found it easy to find people who were in sympathy with my view, I didn’t find a lot of constructive alternatives. I myself had developed a consistent approach, but calling it “non-prescriptive” only told people what it wasn’t, not what it was! Eventually, I (or perhaps I should say “we”, because I had collaborators and a growing community by this time) landed on “outcome-oriented”, and suddenly everything became a lot clearer.
2. How would you explain Agendashift in terms a layperson might understand?
The central idea is principle #2 (of 5 – see agendashift.com/principles): Agree on outcomes. It seems kinda obvious that change will be vastly easier when you have agreement on outcomes, but most of us don’t have the tools to identify, explore, and agree on outcomes, so instead we jump to solutions, justify them, implement them over other people’s resistance, and so on. I believe that as an industry we need to move away from that 20th century model of change management, and that for Agile it is absolutely essential.
Around that central idea, we have 5 chapters modelled on the 5 sessions of our workshops, namely Discovery (establishing a sense of where we are and where we’d like to get to), Exploration (going down a level of detail, getting a better sense of the overall terrain and where the opportunities lie), Mapping (visualising it all), Elaboration (framing and developing our ideas), and Operation (treating change as real work). Everything from a corporate ambition to the potential impact of an experiment is an outcome, and we can connect the dots between them..
3. You went through an interesting development process, care to elucidate?
Two key ingredients for Agendashift are to be found in the last chapter of my first book, Kanban from the Inside (2014). The first is the idea of “keeping the agenda for change visible”, a clue to where the name “Agendashift” came from, and worthwhile to develop further how one might populate and visualise such a thing (and I took inspiration not just from Kanban, but also from Story Mapping). The second was the kind of bullet point checklist you see at the end of a lot of books.
I and a few others independently around the world (Matt Phillip most notably) realised that we had the basis for an interesting kind of assessment tool here, organised by the values of transparency, balance, collaboration and so on (the values model that was the basis for my book). In collaboration with Dragan Jojic we went through several significant iterations, broadening the assessment’s scope, removing jargon, eliminating any sense of prescription, and so on. We found that the more we did that, the more accessible it became (we now have experience using it outside of IT), and yet also more thought-provoking. Interesting!
Other collaborators – most notably Karl Scotland and Andrea Chiou – helped move Agendashift upstream into what we call Discovery, making sure than when we come to debriefing the assessment that we’re already well grounded in business context and objectives. The unexpected special ingredients there has been Clean Language (new to me at the time, and a great way to explore outcomes) and Cynefin (already very familiar to me as model, but now also very practical once we had the means to create lots of fragments of narrative, outcomes in Agendashift’s case).
4. Who is the Agendashift book aimed at, is it appropriate for newcomers, journeymen or masters?
I do aim in my writing for “something for everyone”. I accept though that the complete newcomer to Lean-Agile or to coaching and facilitation may find that it assumes just a bit too much knowledge on the part of the reader. My third book (working title “Right to Left: The digital leader’s guide to Lean-Agile”, due 2019) will I think have the broadest possible appeal for books in this space. We’ll see!
5. How do you see things progressing – is nirvana round the corner or is that the wrong way to think about it?
We’re coming up to the 2 year anniversary of the public launch of the Agendashift partner programme, 2 years into what I’m told is likely a 3-year bootstrap process (I have some fantastic collaborators but no external investment). General interest is definitely growing – more than 500 people in the Agendashift Slack for example – and I’m seeing a significant uptick in demand for private workshops, either directly from corporates or via partner companies. Its potential as a component of leadership development and strategy deployment is gaining recognition too, so we’re not dependent only on Agile transformation opportunities. I believe that there is potential for Agendashift in the digital and DevOps spaces too.
There is a lot of vested interest in imposed Agile, and in all honesty I don’t see that changing overnight – in fact I tell people that I can see the rest of my career (I’m 53) being devoted to outcomes. Over time though, I believe that we will see more success for transformations that are based on genuine engagement, which can only be good for the likes of Agendashift, OpenSpace Agility, and so on. Eventually, the incongruity of imposed Agile will be exposed, and nirvana will be achieved :-)
My take: Not the weapon, but the hand
I’m all for methodologies. Of course, I would say that – I used to run a methodology group, I trained people in better software delivery and so on. From an early stage in my career however, I learned that it is not enough to follow any set of practices verbatim: sooner or later (as I did), edge cases or a changing world will cause you to come unstuck, which goes a long way to explain why best practices seem to be in a repeated state of reinvention.
I was also lucky enough to have some fantastic mentors. Notably Barry McGibbon, who had written books about OO, and Robin Bloor, whose background was in data. Both taught me, in different ways, that all important lesson we can get from Monty Python’s Holy Grail: “It’s only a model.”
Models exist to provide a facade of simplicity, which can be an enormous boon in this complex, constantly changing age. At the same time however, they are not a thing in themselves; rather, they offer a representation. As such, it is important to understand where and when they are most suited, but also how they were created, because, quite simply, sometimes it may be quicker to create a new one than use something ill-suited for the job.
And so it is for approaches and methods, steps we work through to get a job done. Often they are right, sometimes less so. A while back, myself, Barry and others worked with Adam and Tim at DevelopmentProcess to devise a dashboard tool for developers. So many options existed, the thought of creating something generic seemed insurmountable…
… until the epiphany came, that is: while all processes require the same types of steps, their exact form, and how they were strung together, could vary. This was more than just a, “Aha! That’s how they look!” as it also put the onus onto the process creator to decide which types of step were required, in which order.
Because of this, among many other reasons, I think Mike is on to something. In another recent conversation, Tony Christensen, DevOps lead at RBS, said the goal had become to create a learning organisation, rather then transforming into some nirvanic state. True Nirvana, in this context at least, is about understanding the mechanisms available, and having the wherewithal to choose between them.