In Part 1 of this blog, we have seen the need for a framework that business can use to understand IT throughput and prioritization in a transparent and intuitive manner. The concept of value stream can help us here.
Value stream is defined as the end to end set of activities performed to deliver value to a customer through a product or service.The value stream for an online e-commerce order may look like this.
This can be expanded to include more upstream and downstream activities and this can also be detailed to capture more granular activities.An e-commerce value stream delivers an order for a customer. This is called a Flow Item. A Flow item is defined as a unit of business value pulled by a stakeholder through a product value stream.
The business needs to have a clear and detailed view of the value stream that they own and manage. Once this has been arrived at the value stream activities supported and enabled by IT systems and features will become clear.
IT is also a value stream that provides value to its customers. Mik Kersten categorizes the items that flow through IT value stream into four buckets and these are,
- Features
- Defects
- Risks
- Debts
A SCRUM team may own a particular IT value stream and work on various items which fall across the above four categorize. An IT product may have accumulated a high technical debt. Accumulation of technical debt negatively impacts the velocity and quality of the product. In this case the business and IT need to prioritize Debt items consistently over a few sprints\releases to bring it down. Let us say, lots of customer issues were identified in a recently launched product. The subsequent releases should focus on defect fixes and improving customer trust and satisfaction. Though these two scenarios may be quite obvious once the above four categorize are understood, risks and compliance needs often take a backseat against attractive new features or defects. Mik Kersten cites the Equifax data loss debacle as an example where conscious focus on the Risks might have helped. It is easy to point to this gap in hindsight with a 20-20 vision. Business can switch gears depending on the situation and where a particular product is in its lifecycle by gaining visibility into the distribution of flow items.
The next major benefit of adopting Flow Framework is that business can measure velocity, lead time and other key attributes of a value stream. This helps them to gain more awareness and visibility into a value stream and identify issues like work-in-progress pile-ups and bottlenecks. The Lean practices can be more readily adopted for continuous improvement.
Last but not the least, the value of each flow item and the overall value of the product\value stream should be measured. This can be compared against the cost and investment to run a value stream. In addition for each value stream the internal and external people focused measure like customer satisfaction and team engagement\happiness can also be measured. Flow framework can be used holistically to look into the items within a value stream as well as to gain a top-down view of overall benefits, cost, quality and satisfaction of the team. Such a view can help business to take strategic decisions like when to shut down a product or go in for a major architecture\technical debt overhaul, should we improve the team engagement, are the customers happy with our product. Do you think this framework provides useful insights to organizations adopting product management practices? If so, Project to Product is a great book to read. As you gain understanding of the Flow Framework, would you like to apply it to your situation.
One thought on “Project to Product – Part 2 – How Flow Framework can help?”