But how do you manage the effort of moving from the point you are today—whether that’s just starting to adopt an agile project management approach or fine-tuning your implementation—to a place where you can readily react and respond to the vagaries of the market? By following an iterative transition process. Making small changes on a continual basis is a logical way to adopt a development process that is itself iterative. Doing so will be much more likely to result in a successful and sustainable transition. This is why I believe that the effort of adopting Scrum is best managed using Scrum itself. With its iterative nature, fixed timeboxes, and emphasis on teamwork and action, it seems best suited to manage the enormous project of becoming and then growing agile with Scrum.

Just as Scrum development projects use product backlogs, you should use an improvement backlog to track the effort of adopting Scrum in your organization. An improvement backlog lists everything that the organization could do better in its use of Scrum. If you’re just starting with Scrum, your improvement backlog will emphasize creating awareness and desire. If the transition is already well underway, your improvement backlog may contain more items around developing the ability to do Scrum well, to promote successes, or to transfer it to other groups. A small department or single-project transition may involve a single improvement backlog. But when Scrum is being adopted across a large site, department, or organization, the transition effort becomes large enough that multiple improvement backlogs are used, each of which is created by a community of individuals who are passionate about improving the organization in a particular way.

Many corporate improvement initiatives fail because plans are not made specific and actionable. Using Scrum to manage the effort of becoming agile allows you to divide the work into stories and tasks with concrete deliverables and definite end dates. At the end of every iteration, the organization will have improved in measurable and visible ways. Eventually, you will have successfully transformed the organization into one that not only is agile but also that seeks to become more agile each day.

Additional advice on using Scrum to manage your transition effort is provided in Chapter 4, “Iterating Toward Agility” of Succeeding with Agile.

Although team members should always look to share with one another their newly discovered good ways of working, they should resist the urge to codify them into a set of best practices. What’s good for one team may be too prescriptive for others. For example, one company I visited had decided that all daily scrums needed to be held no later than 10:00 a.m. I found this an extremely unnecessary dictate. I’m not entirely sure what purpose the dictate served, but many employees interpreted it as a lack of trust by their management.

Even a good practice can lure teams into a false complacency once it has been established as the “best.” Like sirens singing to us from the rocks, best practices can tempt us to relax and stop the effort of continuous improvement that is essential to Scrum. Mary Poppendieck quotes Taiichi Ohno, originator of the Toyota Production System, as saying that “there is something called standard work, but standards should be changed constantly. Instead, if you think of the standard as the best you can do, it’s all over.” Ohno goes on to say that if we establish something as the “best possible way, the motivation for kaizen [continuous incremental improvement] will be gone.”

In Scrum, sharing success stories and methods that work is a good idea. Establishing one set of solutions as the best is not. Don’t limit the very improvement you are seeking. Instead, let your organization’s standards evolve with you as you grow more agile.

For more information on this topic, see Succeeding with Agile: Software Development using Scrum.

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.