Imagine the following scenario. You are working as a Scrum Master with a Scrum team in a project. Your Scrum team is one of two Scrum teams in the project working together with a bunch of business analysts. The project itself is just one of multiple projects within a program with approximately 300 members. Each Scrum team in this program is responsible for a single technical component. Only the integration of and interaction between different technical components delivers usable features. This way of software development is also called horizontal software development. In contrast to vertical software development, where teams implement features through the full technical stack, in horizontal software development a team implements only a single technical component and thus just one technical part of a usable feature. In other words, not a single component delivers any value to any user of the software. Only the combination and integration of multiple components and services provides real value to users. Until the integration of the individual components to full-functioning features the output of the Scrum teams is just for stockpile. The consequence is that the Scrum teams and business analysts mainly think in technical terms.
This is the environment I was working in. But because we wanted to deliver value to the users of the product under construction, we should have emphasized value and not output of technical components or services. So, the challenge I was confronted with was finding a way to make people think more in value than in technical terms. Fortunately, I knew Jurgen Appelo from his Management 3.0 activities for a while back then. So, the time he founded his new company Agility Scales I immediately followed the evolution of his new startup. Agility Scales develops an app called MindSettlers which enables people throughout the world to share practices with each other. Thus, it was no surprise that I came across a tool called Value Grid. Because this article focuses on the practical implementation of this tool, I don’t explain it here in detail. Just shortly, the Value Grid directs attention to the delivered value of any activity. A detailed description of the tool can be found here.
The first thing I then introduced in my project was evaluating every finished user story at the end of the sprint using the Value Grid. We even showed these evaluations to our stakeholders in the Sprint Review and discussed our ratings. In addition, we also started using the Value Grid to evaluate our Scrum events, like the Sprint Review, Refinement sessions, Sprint Planning, and other workshops. We wanted to get a picture of the perceived value of the participants, and thus the usefulness of our workshops and events.
The effect was amazing. After a very short time people in the project – at least in the range of my influence – started to change their wording. Where we previously had a technical driven language, people more and more started talking about delivering value. Especially the business analysts, who were formerly almost exclusively thinking in technical ways, started talking about delivering value. They even deliberated about the value they were delivering to the Scrum teams during their daily business.
But that’s not the whole story, the consequences were much more far-reaching. The word was spread and more and more people in our program realized that what we were doing was of no benefit to any user. The call for a structural change became louder and louder. This finally ended in a reorganization of the whole program structure into teams with a focus on delivering value instead of producing useless technical components.