Historically, when an organization needed to change, it undertook a “change program.” The change was designed, had an identifiable beginning and ending, and was imposed from above. This worked well in an era when change was necessary only once every few years. But in today’s fast-paced, ever changing environment, it makes more sense to create agile organizations, ready to adapt to whatever comes their way.
But how do you manage the effort of moving from the point you are today—whether that’s just starting to adopt Scrum or fine-tuning your use of Scrum—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.
Boy, this hits home with our scrum transition. I can use this info to help in the next step, moving from agile Dev teams to an agile organization. Our teams are fully agile but management and other areas of the company are not.
Mike,
Very nice posting. I especially liked the idea of creating an improvement backlog, goes in line with the continuous improvement that Scrum preaches.
I have some question though, would you recommend using user stories for the improvement backlog? How would you define the acceptance criteria for those user stories? Should one only consider improvements that could be measured?
Best regards,
Juan
Totally agree with you !!!
Just like refactoring the complete application in one shot is a mistake so is turning upside down your development process.
We need a slow and stead revolution not a revolt.
Thanks for this post Mike.
I feel Scrum as project management framework is useful to manage process improvement (PI) in general, apart from software development. In PI projects we do not know the solution from up-front or what the requirements should be. In fact we do not even know all required stakeholders in many cases or even the scope. We may claim we know the problem. In PI we try to uncover what is required to be done using for example DMAIC. However, from my view unless we have time-boxed goals; retrospectives; and planning for next goals; improvements tend to delay.
[...] [...]
+1 on the idea of using Scrum [techniques] for things other than software.
At this point in my career I get to work with departments and organization that wish to reap the benefits of an agile approach. But, if one chooses to use all of Scrum’s techniques for organization change and adoption, such as Sprints, then one mustn’t get disappointed if an organization doesn’t change in given Sprint. While it would be easy to track the activities you are doing to help change the organization, it isn’t as easy to track the outcome. We’re dealing with values, principles, org charts, personalities, HR, titles, etc. These organizational things have inertia, and it may take multiple sprints to exert enough force to change their direction.
Given that, I fully support the idea of a backlog of items like “Conduct a brownbag on agile planning and estimation,” “bring in Mike Cohn to conduct a session on Relative Sizing,” “Introduce One True Metric + Themes to the Executive Team,” etc.
Mike
I am sooo glad to hear you say this. I have been so annoyed with “Scrum coaches” whose “coaching” follow either have no structured process at all, or is planned very waterfallish.
Wrote about this earlier this year: http://dearjunior.blogspot.com/2009/05/scrum-coaches-ought-to-use-scrum.html
Hey Mike, nice post. While I live more and more in the iteration-less kanban world of rhythm and cadence these days – I like how the Scrum framework of fixed iterations seems to be a more effective framework for continuous organizational change.
Can’t wait to read your new book! Keep up the great work.
Hi Juan–
As you can imagine, I love user stories but I haven’t found them as helpful for the improvement backlog items. I think they have potential and I talked to some IBM teams who write improvement backlogs with user stories. So I’d encourage experimenting with it but I don’t feel as strongly about stories for an improvement backlog as I do for a product backlog.
Rajiv–
What an excellent analogy: We don’t refactor the product all at once, let’s not refactor the dev process all at once. I think that is a great way of thinking.
I do, however, still think there are times when an “all in” transition is called for. Salesforce.com, quite notably, was very, very successful with this. Still we can have a revolution to start the change but then we evolve from there (as they did) to continually better and better places.
Hi Sameh–
I love what you’re saying about the uncertainty of a transition. We don’t know the exact goals, we don’t know how we’ll end up, etc. These are completely analogous to most development projects and are the reasons why Scrum, as a general purpose project management framework can be used for development projects and organizational change efforts.
You’re right, too, about the value of timeboxes, retrospectives, (and reviews), and such for the transition project as well as any development project. I think I’ve got a blog coming on that. (I’m still pursuing my 20-blogs-in-10-weeks goal!) But you’ll find the idea of using Scrum to guide a transition to Scrum much more fully described in the Succeeding with Agile book than in this short blog post.
Hi Charles–
You’re absolutely right–changing an organization is slower going than most projects so tangible progress won’t be visible every sprint. I think at one point in the book I wanted to say something like “at the end of each sprint, the organization is incrementally improved.” But I had to avoid that because it’s not really true. Sometimes I want the organization to try something that may or may not work. If it doesn’t work, we’re not really incrementally improved. (We may be smarter and that’s good enough some times.)
Hi Dan-
Thanks for sharing the link to your blog on the value of using Scrum to become agile. You’ve got some good examples of organizational user stories there so hopefully Juan sees them as well.
Perhaps not surprisingly, I have seen two companies who had Gantt charts showing how they would adopt Scrum in one case and XP in another. Now admittedly the activities were high-level but still there’s a fundamental incompatibility to assuming we can become agile with a waterfall transition process. Fortunately that type of transition process has begun to fall out of favor in general, anyway, not just among agilists.
Thanks, John. It’s always good to see your name. While I can see and have witnessed how a sprintless approach can work for some development projects, I agree that the timeboxes and focus on a deliverable by and endpoint will be necessary for a transition project. Without the focus and intensity created by the sprint, there are too many competing demands in most companies and attention would get pulled away from the transition effort, I think.
Mike,
Per your comment about the organization not being incrementally improved at the end of each organizational change iteration, I humbly submit that the organization -knowing- more at the end of an organizational change iteration -is- an incremental improvement, even if what they know is that what they tried during that iteration doesn’t work in their context. Of course, you allude to that at the end of your comment, but I think it should be more prominent than a trailing parenthetical calling it “good enough”.
We are knowledge workers doing something (software dev) that is extremely knowledge-oriented. Knowing more is better than “good enough”, it’s the difference between winning and losing. (Rapid learning is also IMHO one of the key reasons why agile is more successful than waterfall/batch and queue models.)
Thanks for the blog. This is a great strategy for organizational change.
Hi John-
Absolutely, and I’ve written in previous books that developing knowledge is second in importance only to developing functionality. However, what I’m referring to in the example in my comment is the case where an organization tries something (say 6-week sprints) and learns that it is a bad idea (at least in the organization’s current context). Absolutely we have learned something but in a case like this it is almost universal in my experience that if we had it to do over, we wouldn’t have made that particular change.
For the improvement backlog, I found a useful article at http://bit.ly/24Cnd4. It might be useful to use as Epics for the initial backlog to start with.
Good blog post! Especially since I already had an idea called the “Scrum Process Backlog” I was going to bring to our next retrospective (on monday).
The idea basically means to establish a heading on the Product Backlog where the team members can write down their ideas, questions, etc regarding the Scrum Process. For example, under the user story “As a developer, I would like a better dialouge with Customer Support” the team members could write ideas like ” appoint a designated customer support person that can take time off his normal tasks to help us”. These tasks are then to be brought up at the next retrospective, and action is taken.
I’m really looking forward to find out if it will work as intended and how the idea will develop in the upcoming sprints!
Good luck, Ådne. Please let me know how it works for you.
I like the idea of this. I’m working at a company where the scrum adoption is completely grass roots, bottom up, and in this situation one of the challenges we’ve faced with an improvement backlog is that there is often no “scrum team” responsible for executing on it. One of the indicators of a successful scrum team is that they are 100% dedicated to their scrum team’s work, at least for the length of the sprint, and so can fully focus on their commitments for the sprint. With organizational change in a bottoms up org, this is rarely the case, where there is a team of people fully responsible for it, and rarely a true “product owner” of the organizational change to whom the team can commit and demo to at the end.
In this situation, we’ve had to be a lot more flexible with the rules than some of us would like to be, until we can more fully establish and prove scrum’s worth at our company. We’re starting to see some top-down support and goal setting, so I anticipate that this will really help and we can get much closer to the ideal change management process you describe.
Hi Peter–It’s good to hear from you. You’re right that things will get easier as you begin to get some top-down help. Bottom up transitions are great, but they inevitably hit a level where those above do not support the change and will try to stop it. Top-level support helps break down that middle layer of resistance. Good luck!
[...] How Do You Get from Here to Agile? Iterate. by Mike Cohn – “…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.” [...]