None of the agile processes as described by their originators is perfect for your organization. Any may be a good starting point, but you will need to tailor the process to more precisely fit the unique circumstances of your organization, individuals, and industry. As Alistair Cockburn once told me, “Having a chance to change or personalize a process to fit themselves seems to be a critical success factor for a team to adopt a process. It’s the act of creation that seems to bind teams to ‘their own’ process.”
You may have a clear vision of what “doing Scrum” or “doing XP” means to you, and you may get others to buy into exactly that same vision, but where the organization ends up is likely to be somewhat different. In fact, to even refer to end states in an agile transition is incorrect; there can be no end state in a process that calls for continuous improvement.
This creates a problem for an organization that wants to transition to agile through a traditional change approach that relies on gap analysis and then on closing the identified gaps. If we cannot anticipate the end state of an agile transition, we cannot identify all of the gaps between there and the current state. So, a gap analysis–driven change approach will not work.
The closest we can come is to identify gaps between where we are now and an improved, intermediate state. After identifying these smaller gaps, though, we are still left with the problem of how to close them. It is difficult (and often impossible) to predict exactly how people will respond to the many small changes that will be needed on the way to becoming agile. Teamwork expert Christopher Avery views organizations as living systems.
We can never direct a living system, only disturb it and wait to see the response…. We can’t know all the forces shaping an organization we wish to change, so all we can do is provoke the system in some way by experimenting with a force we think might have some impact, then watch to see what happens.
So, a transition to agile cannot be a process that “articulates and defines the entire change process required to bridge the gap between ‘as is’ and ‘to be’ and creates tactical plans,” as I read in a traditional change management book recently. Creating such a plan would require leaping two impossible hurdles: first, knowing exactly where we’ll want to end up; and second, knowing exactly the steps to get there. Because we cannot overcome these impossibilities, the best we can do is adopt a “provoke and observe” approach in which we try something, see if it moves us closer to an intermediate, improved state, and if so do more of it.
These pokings and proddings of the organization are not random. They are carefully selected based on experience, wisdom, and intuition to drive a successful transition to agile.
For more information on this topic, see Succeeding with Agile: Software Development using Scrum.
‘Poke and Observe’ as opposed to ‘inspect and adapt.’ This would imply that organizations not merely complex, but truly chaotic.
I recently put an impediments & escalation board in a very visible place. The board provoked curiosity until the first tickets were posted, then a firestorm. People were surprisingly sensitive to the implied criticism of impediments. The tickets came down.
So v2, we will try to communicate the purpose and playing rules of the impediments board, then post impediments.
Yeah, poke and observe makes sense. And every once in a while, you can wake the sleeping giant…
Cheers,
peter
Excellent post. it nails the main agile adoption principle and shows clearly why tests like “Nokia Tests” fail. I always told that it is SO context dependent and there is no single right solution for every development team.
Great post! I couldn’t agree more and htis is also the thought processes (from my readings) about the Toyota Production System. You define a better state and you move form your current state to the better state. You may not achieve that fully or you may; regardless there will be a new and better state to try and move to when you get as far along as you can.
Thanks re-emphasizing that the change should be continual.
Paul
I like the tag line “provoke and observe”!
Understanding what it means to “be agile” and intelligently applying the knowledge to your context is so important.
Our meetup this week at Agile Ottawa is titled “Don’t Do Agile” http://agileottawa.wordpress.com/2009/11/01/dont-do-agile/
Good post http://mitchlacey.com/Blog/Scrum-for-Managers.html about how managers role includes helping team understand agile principles and values.
thanks
Phil
Great post Mike. It’s amazing that companies will write vague and verbose mission statements and not have detailed plans to attain those “goals,” yet they want a specific process of moving to, or rather adding agile in to their existing processes. As you say, an Agile transition is different for many companies, and looks more like a roadmap with many potential ways one could go. I hope people keep this in mind as they become more Agile.
Thanks everyone for the comments on this one today. I wish I could be in Ottawa for the Don’t Do Agile meeting.
I like that exercise, Russell. I’ve seen Lyssa Adkins do something nearly identical in her upcoming book on coaching.
The so-called Nokia Test has always bothered me. I suspect it bothers many at Nokia, too, since they aren’t the ones to have named it after themselves. It’s too simplistic to mean much.
I hadn’t thought of irony, Robert, of the willingness to accept a vague mission statement (yuk) while insisting on a Gantt chart for how to adopt agile.
Thanks for reading and commenting. I appreciate it.
I suggest that the transition process should be Agile by itself. It is like new product development which we figure what we want as we iterate. Assessment of one iteration is the driver for what to do in the next. I think Agile serves to make the organization acknowledge that we can not commit on what we deliver from up-front and at what cost. In traditional project management, it’s bold to say that. We rather uncover value as we proceed. I think this applies to the transition process.
Hi Sameh–
You’ll see in both some upcoming posts and in my Succeeding with Agile book itself that I completely agree that the transition process needs to be agile itself.
Interesting post.
In my current thinking not only is there no end state but I’m not really convinced that aspiring to be ‘agile’ is a really useful goal to be aiming for in the first place even though I’m coming across that idea quite frequently.
I think it’s useful to remember that our goal is to try and build software quickly and with the level of quality that satisfies our customer and helps them solve their problems.
Agile provides a lot of ideas around how we can do this but just aiming to become proficient at the ideas it suggests isn’t enough.
We want to be looking to continously improve our feedback cycles, get better at solving problems in our given domain and so on. Maybe that’s me just describing some of the ideas of lean though!
Hi Mark–
Yes, it is a common argument that “we should focus on becoming more agile.” I put that in the same vein as I shouldn’t focus on eating more vegetables, I should just focus on being more healthy. Eating more veggies is a leading indicator of being healthy (at least eating more of the disgusting things than I eat is).
In the Succeeding with Agile book I do stress that while being agile is not the ultimate goal, it is a good leading indicator of things that will lead to success at what we really want.
Thanks for your comments.
[...] with that, you are on your way to succeeding with agile.” Which is the title of the book. By Mike Cohn. Love [...]
[...] Whilst on the subject of scrum, there’s another important idea that needs to be driven home to organizations that take on the scrum challenge: is is that there is no end state when transitioning to agile. [...]