ROI/Story Point: The Mark of a Truly Agile Organization

ROI/Story Point: The Mark of a Truly Agile Organization

In this article, James examines why the Agile Organization that knows how to do real Scrum is the Future of How Business is Done.

When I'm working with teams, I hear all kinds of reasons why they want to do some version of Scrum that's easier than the Scrum I teach, or that my kind of Scrum is too prescriptive. Likewise with Kanban teams, they have lots of different reasons why they pick their process because they don't want all the administration of Scrum.

My response is usually (delivered gently) either you're doing Scrum or you're not, and the reason why you use the Kanban process is because you can't do Scrum given the nature of the work and workflow, and not because you don't want to do Scrum (I'll leave the criteria for selecting Kanban over Scrum for a later article).

Additionally I'll remind teams that real Scrum:

1) is intended just as much as a way to reveal dysfunction as it is a way to get work done.

2) emulates the habits of high performing teams.

Don't change Scrum because you feel like it without your team reaching a high level of agile maturity first. Get through the Imitate and Assimilate phases before you start trying to Innovate. https://en.wikipedia.org/wiki/Shuhari

So why is real Scrum so prescriptive? We're supposed to be agile so the process adapts to our needs, and as the Scrum process specifies, teams are autonomous and can change process as is necessary and needed, right?.

Let's address that question of prescription. Organizations don't become agile so that teams can enjoy some newfound freedom in their autonomy and hope that this makes teams more productive. Organizations become agile because they want to be more successful, increase shareholder value, and be more competitive.

This being the case, agile organizations understand that the team and the way the team gets work done both contribute more to positive outcomes than individual resources. Why? Well thank Scrum. Specifically that prescriptive kind of Scrum that many organizations still think is too much trouble to implement.

And if you represent leadership in one of the organizations that allow for some sort of half-hearted Scrum process, then I'd suggest that you'll eventually be in trouble if your competitors are serious about their Scrum process and enforce a consistent company-wide message about how real Scrum is done.

So what's the advantage that your competitors will enjoy over you if they are doing a prescriptive Scrum process that you aren't doing?

Simply this: Empirical data and predictable performance. The prescriptive Scrum process provides the best environment for nurturing Agile Values (trust, transparency, commitment, continuous improvement). And these values when fully embraced lead to empirical data and predictable performance.

AGILE VALUES

Trust: The more leadership can trust their teams, the more members of the team trust each other, and the more the process itself is trusted (*remember what Nick Saban says), then the process itself takes on the bulk of the responsibility for getting work to a done status. Process becomes team shared instinct.

Transparency: The more the team trusts the process, the more open that team will be with regard to the status of their current or future work, without fear of reprisal.

Commitment: Armed with trust and transparency, a high-performing scrum team will reliably produce positive outcomes over a longer period of time – the measure of a true asset.

Continuous improvement – A repeatable process reinforced by trust, transparency and commitment leads to maximizing the amount of work not done, and kaizen (improvement) efforts by the team.

Even the artifacts resulting from the process improve. High performing teams resulting from real Scrum encourage more strategic product roadmaps, and release plans increasing in reliability.

Did I say release plan? If you have a high-performing team that can reliably deliver on a release plan (given inspecting and adapting to change along the way), now what have you got?

CPP – Cost per Story Point. Wow, that's a pretty powerful number there. How can leadership make use of that number for the benefit of the company and to the dismay of competitors not having the same data?

Well, because it's one of the two critical variables used to calculate ROI (return on investment). The other being VPP (value per story point).

VALUE PER STORY POINT

A mature agile organization that wears Agile Values like a pair of comfortable walking shoes is capable of valuing products at the portfolio/epic level. There are a variety of ways to do this. Qualitative methods are simple even if they don't eliminate bias, but I contend they're better than nothing if done with good faith and transparency. Ways to do Qualitative Valuation might include prioritizing epics and assigning estimated point pools to them, valued by their priority. The size of the pool is all you have to point your stories mined from those epics.

Quantitative methods are much more accurate and eliminate bias, but require data, and take more time. These methods might originate from the agile Finance Dept of your company and include Net Present Value or Cash Flow Analysis. So each epic is assigned a calculated value, then each story mined from that epic is given a value per story point once it is relative size estimated.

Ok, now we have something to work with: Calculate the ROI of a story by subtracting CPP from VPP to get a positive or negative number, or dividing VPP by CPP and multiplying by 100 to get a percentage.

This is powerful, actionable data for your organization. And I submit that it is the ultimate expression of an agile organization in a single number: Maximizing the least you have to do for the most return. That's the strength of an agile organization doing scrum right.

*https://constantrenewal.com/nick-saban-the-process/

Until next time,

slàinte mhath!

James Smith has a 25 year career building high-performing technology teams and organizations for a multitude of industries. He enjoys working with startups to some of the largest corporations in the world, has held several highland games world records, and has pitched to VC using nothing more than napkin drawings and a bowl of M and M's. He claims there's only one truely always-optimizable XOR result in the universe, that either 2+2=4 or it doesn't, but not both. Otherwise, some of the best results can be found in the grey areas.

Sangeeta Karambelkar

Technical Project Manager

5 年

Very well explained.

Randy Harris

Manager Software Engineering at Jacobs

5 年

This is an incredible tutorial for organizations and their coaches. James, if you are interested, I highly recommend you submit this as a white paper for the 2019 I/ITSEC conference in Orlando. The DoD has a mandate going forward to adopt agility in every facet. In most cases, the hurdles program offices face is traditional acquisition processes that rely on quantitative values and strict contractual vehicles. ROI prediction appears impossible to them when comparing agility to their traditional methods. Every program office could benefit greatly from this article. I am going to reference this information heavily until I have it memorized. Thanks for another outstanding contribution to the agile community!

要查看或添加评论,请登录

社区洞察

其他会员也浏览了