We’re already familiar with how Story Maps are an excellent way to help development teams visualize the work involved in building a large product. They act as stepping-stones between the initial vision and the resulting deliverable user stories. But Story Maps can serve a similar purpose in Organizational Change, too! If the Story Map (or Organizational Change Map) is created as a collaborative activity between the Executives and the people who will implement the changes, the activity becomes a form of Catchball, as discussed in the previous post . The Story Map then becomes the Strategy.
But collaboration is the key. Both Vision and Strategy should be created with input from the whole organization. Often they’re created in a Catchball / Story Map process mentioned above, but there is an alternative approach, such as an X-Matrix.
Some prefer to use the X-Matrix as a Strategy Deployment Tool – basically another way of visualizing the relationship between an objective, a strategy, and the tactics used to implement the strategy. Caveat: most of the examples you will find on the subject are around manufacturing and are heavily focused on metrics. Given the limitations of measurement in the world of software development (i.e. knowledge work), I don’t find that an X-Matrix adds much more than a good Story Map.
If you choose the Story Map method, break down a few items at a time into manageable changes. Changes at this level should be small enough that it’s clear which team(s) needs to be involved in making the change.
At the WorldsSmallestOnlineBookStore, there are over one hundred people involved in making the quality changes that were implied by the vision! This is too large for even the most effective facilitator to handle in a single event. So Steve, the appointed ScrumMaster and Agile Coach, decides to run “Vision to Strategy” sessions in five groups. Each session includes at least one executive and a couple of other people who were participants in creating the original vision.The five groups discover the following problems:
- Stack Ranking , affectionately known as Rank and Yank. Since its introduction two years ago, has turned the workplace into a competition to get a bonus and avoid being fired. Team(s) involved: Organizational Improvement Team
- Full Regression Test Cycle is Too Long (four people take three weeks to run it). This means that even after a release is complete there is an extra three weeks before the software can be deployed. Team(s) involved: All Development Teams
- Hard to Make Changes because the Code Base is Brittle. Team(s) involved: All Development Teams
- Pressure to Deliver over Quality. Team(s) involved: Organizational Improvement Team
- Lack of Belief in Management’s Commitment. Team(s) involved: Organizational Improvement Team
- Every Sprint, new work results in net new bugs – i.e. “Bugs that escape the sprint”. Team(s) involved: All Development Teams
- Meaningless Performance Review Goals. They happen too late to provide relevant feedback and improvement opportunities. They create goals but the goals become out of date so quickly that, if the goals are pursued, they might focus people in the wrong places. Team(s) involved: Organization Improvement Team will work with HR
They reframe them as more positive goals:
Next step: Define Small Organizational Changes
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.