Value Stream Management: Measuring the value delivery-EN

Value Stream Management by Gabriel Cassarini and co-author Alonso Álvarez

The Nokia case is usually presented as one of those examples of “not knowing how to adapt to change.” And in this discourse, Nokia has as companions Blockbuster (which rejected the opportunity to buy Netflix) and Kodak (which invented digital photography but did not exploit it commercially).

All of them are companies that did not understand the changes in habits, technology, and market. And this discourse is usually the preamble to justify a shift in mindset, strategy, and processes, usually associated with the need to address an agile transformation.

However, a decade ago, Nokia was the model pupil of the transformation and modernization of large organizations that embraced agility. At that time, the famous Nokia Test made it possible to assess the teams’ degree of maturity, measure how agile they were, and whether they followed the Scrum principles.

But we already know how the Nokia story ended – terribly wrong.

What went wrong with Nokia?

When Nokia detected the need to restructure and become more agile, it embarked on an expensive internal transformation program. The objective was to train its teams in Scrum and adopt agile practices and new tools. Experts from all corners were recruited to coach the teams in agile project management. The company’s management was confident that streamlining the way the teams worked would improve the situation for the entire organization. Progress was measured by the adoption rate of Scrum and the use of the new tools.

But Nokia’s problem lay elsewhere. The launch of the iPhone in 2007 had changed the landscape completely. The software was becoming the new source of innovation. At the time, Nokia was using the Symbian operating system and did not have an architecture capable of integrating an app store. The technical teams at Nokia saw that the main obstacle was the substantial technical debt of the software platform.

But their efforts to get the support needed to solve that problem ran up against the company’s organizational structure and the management poor understanding of the situation.

Internal Transformation

The internal transformation of the organization only produced local optimizations. And while this helped individual teams, it did not accelerate innovation and value delivery along the entire chain. There was a vast disconnect between production levels and management. If deployments and moves to production had to be approved by a group that only met once a month, the speed of delivery remained monthly-even though teams released new features every 2 weeks.

The agility metrics used in Nokia’s transformation focused on individual teams but did not give a systemic, end-to-end view of how work flowed through the entire value chain. They did not show the negative impact of mismanagement of dependencies between teams, the problem of technical debt and the lack of alignment between technical and business areas.

Lack of visibility into the impact and contribution to business results led to failure. The trees did not let them see the forest which was burning.

At a business level, we cannot manage what we cannot measure

Today, many organizations are investing enormous resources in digital transformation processes. But they still struggle to see the benefits or measure the results to know if the changes are working or not: “Banks Spend $1 Trillion on Digital, But Few Reap the Rewards”. In these companies, the efficiency and effectiveness of software development are very low compared to what tech giants and startups achieve.

Would it be possible to see how the teams work producing software in real-time flows, in the same way, we observe a car’s entire manufacturing process on an assembly line?

It is indeed a complicated question to answer. Much of the software production process is a creative, knowledge-based activity in the developers’ heads. It is impossible to ask them to document and record the whole process to make it visible. That is because different tools and communication channels are used during development. We cannot inspect their heads neither read their minds.

Also, part of the problem is in the leadership. Concepts of software development and deployment familiar to people in the software world- technical debt, story points, incremental delivery of value- mean nothing to leaders who manage IT initiatives as stand-alone projects. These roles are used to measuring everything in terms of budgets, schedules, and cost optimization.

Still, some companies do manage to measure how workflows and value delivery in business terms. Uber has demonstrated that a well-designed app running on mobile can disrupt an entire industry.

These companies use metrics and dynamic internal structures to guide innovation. It is not enough for them to have agile teams. In addition, the organization’s structure mustn’t be an obstacle to cross-functional collaboration and communication between different areas.

In the case of software, it is also necessary to have a technical architecture capable of evolving, that allows solutions to be created incrementally, iteratively and by integrating different technologies.

Their leaders speak the language of developers because many of them were developers before. They understand the complexity and uncertainty of the process, which allows them to define and execute their software strategies well.

Measuring and optimizing end-to-end value delivery

There are many frameworks and practices for streamlining, transforming, and scaling software development. They all attempt to align the internal organization with the value streams through which work, value creation and value delivery flow. They try to take a broad view of the entire development cycle and involve all stakeholders from start to finish.

Some, such as SAFe, are comprehensive management frameworks that combine the organization’s current structure with new dynamic networks through which innovation flows. Others, such as DevOps practices, focus on the more technical aspects, automation, blockages and bottlenecks during the build and deployment phases.

Other proposals, such as Flight Levels, seek to visualize and optimize the flow of value by applying Kanban principles and practices. And finally, others, such as Flow Framework, use metrics to close the gap between the business strategy and the development process. There are a variety of options for all tastes.

We will analyze the Flow Framework proposal to interconnect software development activities end-to-end and measure their impact on the business areas in future articles.  

Part 2: What is Flow Framework?