Moving fast is a necessity for enterprises looking to stand the pace with the tech giant oligopoly and other startup technologies disrupting most industries. This need for speed has resulted in the adoption of various ways of working to accelerate the flow of work across the software delivery value stream, from Agile frameworks such as Scrum, Kanban, SAFe® and LeSS to implementing DevOps and Lean principles. Yet while it’s crucial to allow teams to experiment with the best ways of working to boost productivity, we must also take steps to address the variability that it brings to the equation in terms of measuring and managing our product value streams. Different methods mean different units of measurement of flow. To find a consistent measure of value from end-to-end, we must take steps to normalize the measurements to generate overarching business metrics that are relevant and meaningful for business and IT leadership.
Beware Water-Scrum-Fall
As organizations pilot new ways of working, they typically start small from the bottom up at the team-level. However, scaling Agile across the enterprise is typically a large top-down undertaking, one that many organizations are struggling to find success with. Instead of a unified Agile transformation across the business, most enterprises are left with only pockets of Agile dotted around the organization.
For instance, a common anti-pattern we have seen at customers is “Water-Scrum-Fall”, where development is using Agile and DevOps practices, but further upstream (Product and Portfolio Management (PPM)) and further downstream (deployment and operations) are using more waterfall-based methods.
In this type of project model, the middle of the value stream — the créer et release stage—has been optimized for fast iterative flow, while the stages before and after these stages (ideate and operate) are still waterfall in nature. So even though development teams are moving faster, generally they’re not going to reduce overall lead time from customer request to delivery because bottlenecks occur outside that stage.
https://blog.tasktop.com/blog/overcoming-data-fragmentation/
Different Frameworks, Different Dictionary
Each framework/way of working paradigm has its own nomenclature of work or artifacts: Requirements, features, stories, incidents, defects, problems, service requests — the list is endless. Complicating matters further, the same term can have different interpretations between different teams adopting different ways of working. A feature in Scrum, for instance, is more likely to be a capability or epic in SAFe®. This has led to the business-level metrics being a superset of a number of the individual team-level dashboards rather than a specific set of metrics for business and teams.
A common anti-pattern that we see is when a CIO requests a dashboard of all the products under their wing. Typically, a product manager will share their own dashboard for their product showing throughout or story breakdown (number of backlog items completed). While team-level metrics are critical for teams to improve their own efficiency, these metrics are too granular for the CIO/IT leadership. The insights needed at a business-level to discuss flow in relation to business results are far more overarching. Yet the inability to abstract the details out of the various components of the value stream makes this a huge challenge, especially when you consider all the frameworks and terminology in the mix.
One Framework to Rule Them All?
Enterprises typically strive for a single enterprise-level framework, as we’ve seen in the past when PMI’s Project Management principles were adopted enterprise-wide. Many organizations are going through a SAFe® transformation to scale the benefits of Agile development across the business. While smaller organizations and startups can have better success with a single framework, larger enterprises find it difficult to align on a single framework.
Large scale transformations are multi-year initiatives, and during this deployment period there will be pockets of different frameworks across IT, and like the toolchain, this environment can be exacerbated by mergers and acquisitions (M&As). However, business-level metrics can’t afford to wait until the entire organization has started operating under a single framework. With business agility and customer responsiveness more important than ever in the Novel Economy, you need to be able to measure your product value streams today to determine the effectiveness of your existing frameworks and methodologies.
Another factor to consider is that all work initiated from a portfolio level in a value stream is broken down into a number of constituent work items, e.g. an epic is made up of a number of stories which is in turn broken into a number of tasks. There are other contributing work activities such as Prioritization and Release Planning, Iteration Planning, Testing, Security Scan, Documentation Releases that determine all the steps towards the delivery of the work. While every one of these work items is essential to delivering value, business-level metrics should be derived at the top-level work items to provide a view of value delivered at a business level. However, we have observed that the lack of traceability prohibits enterprises from being able to measure flow at the highest level in terms of what is actually delivering business value.
https://blog.tasktop.com/blog/moving-from-project-to-product-with-flow-metrics-what-are-they-and-why-should-you-care/
Flow Item Modelling
Flow Metrics measures the flow of value-creating work across each value stream and ties it to key business results in a way that is agnostic to frameworks and ways of working. In the Flow Framework®, Dr. Mik Kirsten provides an easy way to do this by broadly categorizing all software delivery work into four flow Items:
- Feature (business value)
- Defect (quality)
- Technical debt (improve the ability to accelerate future delivery)
- Risk (security, governance, compliance)
Through these flow items, we can now consistently measure end-to-end flow without impacting the way teams work for interpretations based on frameworks across teams and across value streams. At Tasktop we call this flow item modeling. As with flow state modeling—which provides a consolidated view of active and wait time of work in the value stream with just four levels (New, Active, Waiting, Done)—it is important to not disrupt the processes and ways of working model that teams rely on by overlaying the flow items on top of it specifically to generate Flow Metrics.
https://blog.tasktop.com/blog/a-unified-view-of-wait-states/
Don’t let Metrics Dictate Ways of Working
In large enterprises, variability and change are constant. There are a number of external and internal factors that have contributed to them and it is not an easy task to remove them. In many cases, applying too many standards can starve teams of the ability to be creative and the cost is the inability to be reactive to customer needs.
While measuring flow is vital to prioritize improvements towards value delivery, don’t let metrics dictate organizational processes and the way teams collaborate to create value. Instead, measure flow based on the current state, using integration and modeling techniques (like flow item and flow state modeling) to measure flow through a business lens.
These models overlay on the existing ways of working in a non-intrusive way, allowing teams to work in a way that best suits their context while at the same time giving the business vital metrics to identify what’s slowing them down and how to go faster.
Vous voulez en savoir plus ? Let’s chat to begin visualizing and measuring your flow so we can help improve your customer responsiveness and innovation velocity today.
