Five things worth visualizing

If you’re reading this article, you probably know how important the role of visualization is in solving complex problems, achieving ambitious goals, as well as improving the quality of cooperation in a team. Visualization allows you to gain a common understanding, a common ground on which to discuss facts. We know or at least "feel" intuitively why it is worth making visualization a central tool in the team's day-to-day work. But what are the things worth making visible? Micha? Pokorski, one of Hobly's experts in the field of agile transformation, presents his proposals.

1. End-to-end flow

How long does it take your team to create value? Every modern enterprise should answer this question. Imagine a situation like this: after many stormy workshop sessions with stakeholders, the Product Owner has thoroughly learned about their needs and hopes related to the product. He translated the results of these sessions into User Stories and then explained them to the team. Now it's all in their hands. How long it takes for them to transform an idea into a working functionality is what I call an end-to-end flow. Such a measure shows how quickly we can organize ourselves around an idea and turn it into an increment. The key to visualizing the flow of e2e is the value delivered, not just the work done, so we can break away from the mechanical execution of tasks and instead focus on their impact on our customers.

2. Change failure rate trend / defects after Done / Production incidents

What is the quality of our value stream? The post-sprint increment should potentially be ready for implementation and, therefore, of good quality. The question is: how can we be sure of that? For this purpose, we can determine how many errors leak beyond the completed sprint. A straightforward measure illustrating this information is the ratio of the time spent on a story in a sprint to the number of errors spilled out. Many variations can be applied: number of production errors, number of errors in the pre-prod environment, etc.?

3. The value we deliver to our clients

Even if the flow of our value stream is perfect and there are practically no problems, we may still lose sight of the most crucial element - value for the customers. When we apply appropriate measures consistent with our product and the nature of our business, value ceases to be an abstract issue. The Evidence-Based Management approach deals mainly with how to measure value. Are you interested in the usability of an application created by your team? Don't be afraid to ask its users. This is where the satisfaction survey comes in handy. A more direct form of measurement is the Customer Usage Index, which shows precisely which features of your product are used the most. Subsequently, we can apply several profit-oriented measures: average profit per transaction, Product Cost Ratio, or Revenue per Employee. The most important thing is that the value measures should be used consistently – so that the knowledge gained from them allows you to find trends over time. EBM is an excellent set of tools and practices that can be used no matter how agile we are.

4. Complex processes / Big picture

Building digital ecosystems can be a very complex

and challenging task, but when the team does not understand the "Big picture" and instead just stacks proverbial bricks on top of one another, the task becomes impossible. Therefore, it is essential to visualize the outline of the target solution at some level of abstraction. Big Picture Event Storming is a good tool here. It allows colliding the ideas of many parties involved in creating a complex product, eliminating misunderstandings and systematizing knowledge. It is also a great starting point for any deeper analysis of individual elements.?

5. Teams & Dependencies

Entering agility, we need to visualize how our value streams are arranged. Can the teams produce this value without dependency? Or maybe everything looks like one great web of mutual dependencies in which no one can create anything without the help or approval of someone from outside. Such a structure will not only require a complex management process, many coordinators, and work transfers, but it will also reduce the efficiency of the entire stream. All this while waiting for the next person or team to take over/approve the task. What part of your team's job is to wait?

On the other hand, reducing dependencies and ensuring the development of critical competencies in a single team minimizes the work in progress, allowing us to deliver value faster. This approach is much more effective than ensuring everybody’s completely booked in their work capacity. Many tools for visualizing dependencies, such as Jira, can be configured appropriately for this purpose. Only when you visualize the spider's web of dependencies can you start to untangle it.