One of the 12 principles of the Agile Manifesto tells us that Agile processes promote sustainable development, implying there should be a reasonable upper boundary to productivity as measured by the classic definition of output per hour. Another principle suggests regularly reflecting on how to become more effective, then making appropriate changes. Under both principles, a goal of productivity improvement may be implied but is not explicitly called out.
So, what do we mean by Agile productivity? In my experience, Agile teams can waste significant time on this issue. As a coach or ScrumMaster faced with corporate pressure, it’s difficult to resist the management call for higher velocity from teams and easy to succumb to the manipulation of story points or task sizes that appear to achieve desired outcomes.
But, setting aside the ease with which it can be manipulated, does higher velocity really mean higher productivity? Given a choice, would the business (and management) prefer to maximize story point throughput (higher velocity), employee utilization (everyone is as busy as they can be), or business value delivery?
I recently ran an exercise with a group of CIOs where we quickly looked at three projects and used Cost of Delay (CoD) and Weighted Shortest Job First (WSJF) to prioritize the projects by business value. We found that one of the projects had a higher business value score than the other two combined. It was easy to decide to focus just on that one project.
Of course, CoD and WSJF are based on Lean principles. Don Reinertsen1
tells us that if we only measure one thing, we should measure CoD. Reinertsen also tells us to focus on end-to-end productivity and avoid the bottlenecks of work in process caused by local optimizations (such as pushing for local high velocity).
I have found that the only form of productivity improvement that everyone can agree on is measured through value delivery. This seems like an easy compromise, until everyone realizes that both the business and software development teams are accountable for improving value. While software development still needs to maximize output per person, the business team must also put higher-value epics or stories into the backlog.
The first step is to agree on the value metrics and to make them visible. Many more mature Scrum teams have their product owners assign value metrics based on relative value. While this is indeed a good first step, too often it relies on the judgment of the individual product owner. This first step can be improved in two ways: Introduce a standard process for all product owners, and get the business involved.
The real challenge is getting the business involved, because taking a structured approach to assigning business value to epics feels like extra work to them. Possibly, they don’t see why they should invest that time with the software development teams — “Why don’t they just develop what we tell them to develop?” It’s important for them to understand that collaborating with your team to determine the business value has an even bigger impact than helping you maximize productivity of your software development team. It can actually help them, and your organization, justify the expenditure if — or when — it gets questioned by executive management.
Finally, as we have said, assigning business value to epics means that the business is accountable, along with the software development team, for maximizing end-to-end software value delivery. Politically, that might not be something the business heads want to do — it’s much easier and safer to blame the CIO for poor productivity!
So how do we tackle these issues? I recommend starting small and using relative metrics for CoD and WSJF. Relative metrics are useful when absolute numbers are hard to get or not available, and our goal is prioritization. Relative metrics are familiar to Agile teams from story points and Planning Poker, and these techniques can be readily applied at the tactical2
Any progress made in prioritizing software development initiatives based on business value will only help improve overall value and positively impact the organization’s bottom line.
Reinertsen, Donald. The Principles of Product Development Flow: Second Generation Lean Product Development.
2009. Celeritis Publishing.