One of the beauties of Scrum is its simplicity in converting a Product Backlog into increments of value with just a handful of events. When I engaged with teams in larger enterprise IT functions or large product organizations, I found something more is required to deliver value continuously.
- Firstly, multiple teams need to work together to create something of value to the user.
- Secondly, demand comes from many different sources and stakeholders. Alignment to strategic initiatives becomes important to move the organization in the desired direction in an accelerated manner.
- Thirdly, co-ordination between scrum teams and central functions becomes a challenge and often frustrates a scrum team looking to deliver faster.
- Finally, legacy architecture of the product and proprietary technologies add a layer of complexity to incremental delivery.
Many organizations have carefully re-organized themselves around products and product groups to localize dependencies. While structural change is a critical element to faster delivery of value, it is not adequate to assure continuous flow of value. In this post, I propose five enablers that organizations should consider for realising continuous flow of value to their users.
Enabler 1: Clear understanding of ‘value’
A simple definition of ‘value’ would be something a customer would be able to use and they choose to adopt it because it solves a business problem.
For a mature product, value could come from adding functionality that would make it easier or more efficient to use. Team’s ability to understand the demands on customer’s business and how the product could serve their business interests becomes crucial.
For a product that is new, value would initially come from creating a minimum marketable product that would start generating revenue. Opportunities to leapfrog competition could be a great source of innovation. Features that would help acquire and grow the customer base become a priority.
In larger set-ups, ‘value’ aspect of work being done is often lost. Engineers do not often know why they are working on certain backlog items. They are mechanically producing code that gets integrated across teams and gets delivered by a central team. Team members need to have visibility to how a feature is solving a business problem for a user.
Enabler 2: Prioritizing for maximizing delivered value
Often quantification of expected value is tricky. In my view, it is adequate to have the ability to assess relative value. It will help us to order the items of higher value first.
Alignment of the demand to strategic objectives of the organization maximizes the returns on the value being delivered. This alignment needs to be captured and made visible as we refine the big items in the backlog to smaller items for teams to develop.
It is important that product management collaborate with engineering to get an idea of the quantum of effort and complexity of a backlog item. For example, there may be items for which value to effort ratio, RoI, could be higher. It would make sense then to prioritize these features ahead of the others.
Apart from demand that comes from users of the product, there could be demand coming from sources like product standards compliance, regulatory expectations, new technology adoption, architectural investments, competitive products, technical debt, etc. There are useful prioritization techniques that will help in prioritizing disparate items. However, collaboration among various stakeholders is more important for force-ranking the items in the pipeline for each of the teams in the overall value stream.
Enabler 3: Smaller the items the better the flow
Complexity is intrinsic to software development. Bigger backlog items hide complexity and tend to block flow. Traditional approaches promoted creation of detailed specification and well-documented design to solve this problem. We know that approach did not yield the desired results. Breaking items to smaller pieces progressively helps teams to learn from the development experience and reduces the risks associated with complexity.
Often a question pops up: How small should I break a backlog item to be? My answer is always simple: As small a slice of value as possible. When it is meaningful to the users, we can then get feedback from our users.
Enabler 4: Focus on finishing
When one scrum team is involved in developing solutions to the users, it is relatively easy to manage work-in-progress. Team would look at their scrum board on daily basis and pull items only when they could together complete the items in progress.
In larger set-ups, multiple teams are working together to create value. In such organizations, product management would prepare a roadmap for high level backlog items. This helps them forecast and communicate to their customer base on when certain functionality would be available in the future. While it sounds a simple enough thing to do, product management is under pressure to keep the multitude of stakeholders satisfied. They end up creating a crowded roadmap with too many items planned for concurrent development. Let us assume a simple taxonomy – Requirement-Feature-User Stories. Teams end up working on multiple requirements and multiple features at the same time. Even if the teams focus on finishing the User Stories in their sprints, they do not finish features or requirements. Focus on finishing needs to be stressed at all levels of planning – during road-mapping, release planning and sprint planning.
There is a related area that needs leadership attention. Team members typically tend to specialize in certain functional areas of the product. I have seen six-member teams work on six different features because each feature relates to an area that team member specializes in. While this approach keeps the utilization high, each feature takes longer to complete and, in the end, we slow down the flow of value to our customers. Leadership needs to pay attention to the skills set of individual members of the team from technical as well as functional/domain perspective and optimize for faster completion.
Enabler 5: Systemic waste removal
There are structural impediments in a larger organizational set-up, legacy product architecture, proprietary technology limitations and unnecessary processes. Leadership has a critical role to play in removing such systemic waste. These cannot be removed on the fly and need investment of time, resources, and commitment to effectively address their impact.
In a scenario where multiple teams are working together to generate value, there is a dire need to look at the end-to-end value stream and remove wait and waste. Flow metrics associated with the value stream like cycle and lead time, product quality and adoption would help the team measure the impact of improvements and waste reduction efforts. Tools play an important role in gathering the necessary metrics. Systemic waste removal is best done by representatives of teams involved with the support of leadership.
In conclusion, orchestrating continuous flow of value requires leadership focus and energy – particularly from the leaders in the middle.
