{"id":20840,"date":"2020-05-20T09:30:36","date_gmt":"2020-05-20T14:30:36","guid":{"rendered":"https:\/\/blog.planview.com\/finding-a-consistent-measure-of-value-across-different-frameworks-and-ways-of-working\/"},"modified":"2020-05-20T09:30:36","modified_gmt":"2020-05-20T14:30:36","slug":"finding-a-consistent-measure-of-value-across-different-frameworks-and-ways-of-working","status":"publish","type":"post","link":"https:\/\/blog.planview.com\/finding-a-consistent-measure-of-value-across-different-frameworks-and-ways-of-working\/","title":{"rendered":"Finding a Consistent Measure of Value across Different Frameworks and Ways of Working"},"content":{"rendered":"
\n
\"Finding<\/div>\n<\/figure>\n

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 fram­­eworks such as Scrum, Kanban, SAFe® and LeSS to implementing DevOps and Lean principles. <\/span>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. <\/span><\/p>\n

Beware Water-Scrum-Fall<\/b><\/h3>\n

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. <\/span><\/p>\n

For instance, a common anti-pattern we have seen at customers is <\/span>“Water-Scrum-Fall”<\/span><\/a>, 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. <\/span><\/p>\n

<\/p>\n

In this type of project model, the middle of the value stream — the <\/span>create <\/b>and<\/span> release <\/b>stage—has been optimized for fast iterative flow, while the stages before and after these stages (<\/span>ideate <\/b>and operate<\/strong><\/span>) 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.<\/span><\/p>\n

https:\/\/blog.tasktop.com\/blog\/overcoming-data-fragmentation\/<\/p>\n

Different Frameworks, Different Dictionary  <\/b><\/h3>\n

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. <\/span><\/p>\n

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.<\/span><\/p>\n

One Framework to Rule Them All?<\/h3>\n

Enterprises typically strive for a single enterprise-level framework, as we’ve seen in the past when PMI’s<\/a> 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. <\/span><\/p>\n

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<\/a>, you need to be able to measure your product value streams today to determine the effectiveness of your existing frameworks and methodologies.<\/span><\/p>\n

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<\/a> prohibits enterprises from being able to measure flow at the highest level in terms of what is actually<\/em> delivering business value.<\/span><\/p>\n

https:\/\/blog.tasktop.com\/blog\/moving-from-project-to-product-with-flow-metrics-what-are-they-and-why-should-you-care\/<\/p>\n

Flow Item Modelling<\/b><\/h3>\n

Flow Metrics <\/a><\/span>measures the flow of value-creating work across each value stream and ties it to key business results<\/span><\/b> in a way that is agnostic to frameworks and ways of working. In the<\/span> Flow Framework®,<\/span><\/a> Dr. Mik Kirsten provides an easy way to do this by broadly categorizing all software delivery work into four flow Items:<\/span><\/p>\n