Mark Levison
Mark Levison an agile software developer who writes Notes from a tool user.
Agile Change or Adoption: Define Small Organizational Changes
Posted: Dec 15, 2016 12:20 PM
Advertisement
(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. Image attribution: Agile Pain Relief Consulting Template images © Robin Dymond
Read: Agile Change or Adoption: Define Small Organizational Changes
Previous Topic
