(Continued from Agile Change or Adoption Always Starts with Why : 1 , 2 , 3 , 4 , 5 )
Seeing an organizational change map with seven to eight proposed major changes can feel daunting and discouraging. It’s even worse when we realize that list will keep growing as new organizational problems are discovered.
By taking on only one or two changes at a time, and creating and acknowledging the visible improvements that result, we avoid becoming so overwhelmed that we throw in the towel before significant change can be affected.
Our goal in the first few Sprints is primarily to create a habit of change, even more than the changes themselves. We want the idea of regular small changes to become the norm. The Organizational Improvement Team needs small wins. They need to create a sense of momentum and to prove to everyone that meaningful change is happening, so trust and support can grow.
In the previous post’s Case Study, the strategic items – “0 Net New Bugs at the End of Every Sprint” and “Find a More Effective Performance Review Process” are too big to be achieved in one or two Sprints, so they’re broken down into smaller visible steps. When breaking these down into smaller parts, it’s important to incorporate the element of Product Backlog/Organizational Queue Refinement and include some of the doers (e.g. QA, BA, Developers, etc.) who will be affected by the change. We need their input to ensure that the changes deliver value to them and are on point with what we’re trying to improve.
Scrum Development Teams often use User Stories to help them articulate the need and the value of a new piece of functionality, so let’s apply the same principles to this Organizational Improvement that we’re trying to accomplish.
Robin Dymond uses Improvement Stories at the team level so that teams have a tool to inject improvement into every Sprint. We will use the same approach at the organizational level. Like User Stories, Improvement Stories have: Why, What, Who and Acceptance Criteria.
Start with why – why would the organization benefit from a change? Time savings? Quality improvements? Repeatability? Reduction on conflict or stress? Happier team members? By stating the “why” first, we don’t presuppose the solution. Instead, we focus on the problem.
Improvement Story Templates
There are two different templates you can try for creating Improvement Stories.
“Template B – Start with Why” emphasizes the importance of why more than the standard template.
Template A is likely more familiar to most people who are using User Stories.
User Stories invite conversation, focus on the needs of the end user, have a clearly stated value, are small enough to be manageable, and can be implemented individually. They help us to break big challenges down into smaller, more manageable ones, and execute small changes
Will small changes solve all of the organization’s goals quickly?
No.
Will they foster positive momentum, an environment of trust, and habits that welcome improvements?
Yes.
Case Study
For the next few Sprints, the WorldsSmallestOnlineBookStore Organization Improvement Team selects two areas to improve: “0 Net New Bugs to Escape a Sprint” and “Find a more effective Performance Review Strategy”. They hand the first directly to the development teams and ask them to create a plan to implement, and the second is taken on directly by the Improvement Team itself.
“0 Net New Bugs to Escape a Sprint” – the Development Teams meet and come up with the following list of things to try:
- Start testing partially-completed Stories
- All testing involves collaboration between the team members who built the story and the tester
- Eliminate pressure on the Development Team to push more features out faster
- Try using the Specification By Example/BDD approach as a tool to foster greater understanding between QA, BA and Development.
For “Eliminate pressure on the Development Team to push more features out faster”, the Development Teams communicate with the Organization Improvement Team to make the need clear.
Meanwhile, the Org Improvement Team starts breaking down the Annual Performance Review:
- Eliminate Stack Ranking
- Test informal feedback process through bi-weekly one-on-ones
- Look into Performance Review alternatives
- Find options for Executive Coaching on Effective Leadership Mindset
Both groups agree to run these initial experiments for a period of six weeks (or three Sprints). They will recheck the results at the end of those cycles.
Template images © Robin Dymond
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
Leave a Reply