Agile metrics can can be confusing. And there a lot of metrics the try to connect IT to business, by valuing IT and scrum teams in business terms.. There may not be enough metrics, or their could be too many, quite often they confuse everyone rather provide the proper guidance and direction for delivery teams to deliver business value . And of course metrics can easily be gamed, or used to to unwittingly optimize one part of an organization at the expense of the end to end organizational flow. Ultimately the purpose of metrics is to guide our decisions to maximize the delivery of business value through the software we provide customers. So metrics can be challenging at the bests of times
I found the work done by Mik Kersten in his book “Project to Product” a very intuitive and helpful framework to better connect business results and technology investments. Many of the principles are based on Reinersten’s Principles of Product Development Flow. (Reference Cybernetics by Norbet Weiner) By using value streams and flow metrics to understand and the E2E value streams and use lean methods to reduce the waste associated with silo’s. That are promoted through traditional project and management artifacts that are based on cost center fundamentals to shift organizations from a project to a product mindset. The product mindset is one of the key agility enablers . As we continually immerse ourselves in digital experiences , we will equally have to let go of concepts and artifacts, that may have served us well past , but are now bottlenecks in a digital world that requires less friction between business value and technology investments
The model aligns the business value (reduced cost, high quality, increased value and happy teams) to the agile flow metrics of technology delivery. to aligning aligning business and IT cadence with one operating rhythm. This model has the potential to produce a new framework for business agility
In software delivery flow Mik identified four key work items being features and defects that are pulled by customers , risks that are pulled by risk officers and technical debt pulled by architects. We then use lean flow metrics of velocity, efficiency, flow time and flow load to correlate to business value, cost, quality and happy teams for the value stream . This gives business level visibility to drive investments, remove waste and connect value streams.
However value streams in software delivery are more not as sequential as manufacturing value streams. And the creativity and manufacturing process are separate. However business value flow is designed and delivered in daily cycles, where he creative and manufacturing processes are one . The complexity is at the is highlighted when you layer the delivery model across the product model(value stream model), activity model (artifact network) integration model (model) and the integration model (tool network). The people doing the work can then configure their manage their value. Models such as azure are simplifying the activity model with configured drop done task. The concept of value is contextualized to the product
Business value is contextual . Product value streams have different notions of value and monetization value. For a software company it is the exchange of value with a customer , advertising is monthly active users that is monetized to advertisers.
Using flow metrics creates the Business and IT Transparency by translating spending, consumption, and capacity into mutually meaningful perspectives for technology, finance, and business decision makers. This provides a common language that focus on transparency of value that allows the business to make informed trade-off decisions across delivering more features, defect management , business risk and technical debts.
Each work item can be managed can be decomposed within the context of functional expertise. For example Technical debt can be managed through DevOps Maturity models to address and prioritise pipeline bottlenecks