How The Road to Agile Coaching Made Me A Gambling Addict!

Watch a video version of this blog or scroll down to read a text version…

I used to be passionate about Agile Coaching and Scrum. I have spent many years and a lot of money to get here. So it is strange that I am now writing about how all the investment made me a gambling addict.

Writing this blog is not easy. In fact this is a very risk– personally and professionally. But I am doing this out of a sense of responsibility towards our industry and towards other Agile Practitioners who might be on the path that led me here.

So, let’s start at the beginning…

About a year ago, I left for Boston, to attend a PSPO – TTT (Professional Scrum Product Owner – Train the Trainer). I was excited because this would be a chance to learn from two of the most respected minds in the Agile Industry – Ken Schwaber, the co-creator of Scrum and Gunther Verheyen, the Steward of the Professional Scrum Training Courses at Scrum.org.

I had no idea that this class would lead me down a slippery slope from which there was no return…

Gunther and Ken began the class with a question – what if we each got a bag of cash and went to a casino, maybe Las Vegas, for a gambling trip.

Maybe we had $50K to spend, and we were given two options for our gambling approach…

• PLAN A: Place a single bet of $50K
• PLAN B: Place 50 bets of $1K each

Which approach would we choose and why?

All students chose PLAN B because in an environment of high risk and uncertainty like a casino, smaller bets allow us to observe results, learn and adapt our future bets.

The environment of risk and uncertainty in a casino is somewhat similar to that in the world of complex software delivery. As in gambling, so in complex software delivery – things rarely turn out the way we expect them to.

Look back at your own experience in complex software delivery and think…

• How often are business and I.T. on the same page – “what” we should build?
• How often are I.T. teams on the same page – “how” we should build it?
• How often do 3^rd party components behave exactly as we thought they would…?
• How often does the solution behave the same way in production as in the lab?
• How often do customers behave exactly the way you expected them to…?
• How often does the market remain static between the time the requirement is created to the time the solution was deployed?

Chances are, not very often.

So it turns out that there are no guarantees in the world of complex software delivery. Anyone who says otherwise is either misinformed or not talking about complex software delivery.

As we see from the modified Stacey chart below, the domain of “complex” software delivery refers specifically to problems that fit this description…

• REQUIREMENTS: There is more disagreement about requirements than there is agreement
• TECHNOLOGY: There is more uncertainty in the underlying technology than there is certainty
• PEOPLE: There is more unpredictability in the behavior of team members than there is predictability

The sweet spot for Agile Software Delivery is the part of the graph colored blue – the domain of problems where the degree of uncertainty is so high that it is impossible to guarantee the future.

This uncertainty puts a lot at risk…

• Investment in I.T.
• Delays in time to market
• Loss of revenue
• Loss of market share

The key question is that when there is so much at stake, how can we manage the risk so we don’t lose more than we can afford to lose?

Before we talk about how we can manage the stakes and risk exposure, we need to talk about how we can measure them. As Peter Drucker said…

“What gets measured gets managed.”

Peter Drucker

So let’s look at a simple model for measuring the size of bets in the world of complex software delivery.

First, let’s make some assumptions about the size of scrum teams, projects and programs in the portfolio and the average hourly loaded cost for a team member…

Next, let’s make some assumptions about the duration of the sprints…

Based on the assumptions of the teams, projects, programs and portfolio, the organization would probably look like this…

If we created a simple model in excel, the build-up of bets across time looks like this at each level of the organization…

For a developer, the risk-exposure of throw-away work due to invalid assumptions, reaches $150K in less than a year.

Perhaps the cost in dollar amounts is not significant for a single team member, and could be absorbed by an organization. However, the cost may be higher in terms of delays in time to market if the rework needed by one developer delays the deployment to production.

The risk exposure for the work done by a scrum team that is not integrated with other teams and deployed as a solution can be visualized as shown below…

You can see that the stakes start getting higher at a faster pace. Invalid assumptions made at a scrum team level can have a much greater impact to the entire solution both in dollar terms as well as in terms of time to market.

Similarly, the stakes at a project and program level start adding up much faster…

And finally, the risk exposure of the entire portfolio can be visualized as shown below…

Most of my clients know these #’s but when they are made as transparent and visible as I have done above, I usually get a gasp from the audience. Once my clients have seen my presentation on this topic, there is a new level of awareness of the level of responsibility towards the organization and the investors. There is a fresh sense of urgency towards managing the risk exposure better.

CALL TO ACTION: Discuss as a team…

• How does the risk exposure build up in your portfolio across time, teams, projects and programs?
• Do you have a transparent way of quantifying and visualizing this exposure across time and levels of the portfolio?
• Is this view accessible to all your stakeholders? Is it frequently inspected to adapt your actions?

Let’s assume that you have now used a similar model to create an increased level of transparency into your organizations risk exposure with every passing day that teams work on complex software without deploying to production.

How do your investors feel about the risk and uncertainty their investment is exposed to in your software delivery teams…?

The simple way of finding out is to ask them.

CALL TO ACTION: Talk to your investors or their representatives to find out…

• What kind of ROI are your investors looking for? What is their investment horizon?
• How big a bet are they willing for you to place on their behalf…?
• How much I.T. investment are they willing to lose on invalid assumptions and rework?
• How many weeks of delay in time to market are they willing to accept?
• How much revenue loss are they willing to accept due to delays in time to market or deploying flawed solutions?

If you were to show them a view of how their risk exposure increases across time, they might not like you to expose the business to more than a month’s worth of lost investment in time and money.

Whatever their risk tolerance might be, adjust your sprint size to be less than or equal to that duration.

So, now we have increased transparency in three areas…

• ROI expectations of our investors
• Risk tolerance of our investors
• Quantified build-up of risk in terms of un-deployed solution being developed by our teams

Given this increased level of transparency into the build-up or risk, how can we manage the risk exposure to stay within the desired tolerance? One possible approach is called Evidence Based Management – EBMgt ™.

Here are some snippets from a white-paper on Evidence Based Management ™, by Gunther Verheyen – the Steward of the Professional Scrum Training courses at Scrum.org… WHITEPAPER – Empirical Management Explored: EBMgmt for Software Organizations, Gunther Verheyen, Scrum.org…

“The complexity and the creative nature of software development make it a highly fascinating, yet quite unpredictable business. Scrum employs empiricism, systematic inspection and adaptation, to deal with the unpredictability typical to software development. Empiricism is also a pillar of ‘Evidence-Based Management’ – “EBMgt ™”…

Managers in product-development organizations are shifting towards using evidence for better decision-making.

Information and insights gained from having actually performed some work are infinitely more valuable than any upfront theory, assumption or prediction. In the absence of observable work, all preliminary information is to be considered a hypothesis, not knowledge or evidence.

Knowledge is gained when an actual working result can be compared against a stated hypothesis and the observers capitalize on the findings that emerge from the comparison.

A highly dynamic and safe way to gather evidence of what does and does not work is to create repeated cycles of

1. Stating a hypothesis
2. Working on the hypothesis for a limited time
3. Verifying results of the work

This approach enables learning and improving while effectively making progress.”

Evidence Based Management – EBMgt ™ has identified 11 Key Performance Indicators or KPI’s of organizational performance that can help us assess the effectiveness of our underlying activities in accomplishing desired business outcomes. As described in the “Evidence Based Management Guide” written by Ken Schwaber, Patricia Kong and David Starr, these 11 KPI’s are grouped into 3 categories…

CURRENT VALUE: Current Value reveals the organization’s actual value in the marketplace. Current Value establishes the organization’s current context, but has no relevance on an organization’s ability to sustain value in the future.

TIME-TO-MARKET: Time-to-Market evaluates the software organization’s ability to actually deliver new features, functions, services, and products. Without actively managing Time-to-Market, the ability to sustainably deliver value in the future is unknown.

ABILITY TO INNOVATE: The Ability to Innovate is necessary but often a luxury. Most software is overloaded by non- valuable features. As low-value features accumulate, more of the organization’s budget and time is consumed maintaining the product, reducing its available capacity to innovate.

These 11 KPI’s are used to create a weighted indicator of organizational agility called the Agility Index. The agility index and contributing indicators can be used as part of the three-step process…

1. TRANSPARENTLY share the current state of the organizational value by measuring the KPI’s.
2. INSPECT the KPI’s to identify deviations from the desired outcomes. Diagnose which underlying activities might be causing the deviations. Create a hypothesis about how adapting those activities might help correct the course and get closer to the desired outcome.
3. ADAPT the activities to correct the course. Go back to step 1 to validate whether the hypothesis was valid. Rinse and repeat.

This cycle of frequent inspection and adaptation of organizational value can be visualized in a radar graph. The Evidence Based Management – EBMgt ™ framework also helps executives visualize the ROI for investments made in Agility to ensure that it is acceptable…

IN SUMMARY:

To summarize the ideas, Complex software delivery is like high-stakes gambling. Even the smartest person / team cannot consistently predict / guarantee…

• The solution will work exactly as we designed on paper
• How the market will react
• How much business value will be generated

Every morning, our investors give us a briefcase of cash. The amount of money in the briefcase will vary for each organization. In our hypothetical organization here is the amount of cash at stake…

Our investors expect us to be effective at gambling with their time and money

• Understand their ROI expectations
• Understand their risk tolerance
• Be transparent about the size of the bets
• Manage the bets to optimize ROI / Value

We owe it to them to be “Expert Empirical Gamblers”. Empirical gambling requires three pillars…

• TRANSPARENCY: Into size & placement of the bets
• INSPECTION: Of results of the bets
• ADAPTATION:Of size and placement of future bets

Evidence Based Management – “EBMgt™” can help us get better…

1. Create / Refine hypotheses
2. Transparently place small, calculated bets
3. Deploy to production
4. Inspect the market response
5. Measure ROI
6. Learn
7. Go back to step 1 and adapt future bets. Rinse and repeat.

So those of us in Complex Software Delivery are high-stakes gamblers. For us to be effective, we must…

1. Come out of denial
2. Acknowledge the reality
3. Get better at it

So I have no shame in admitting that I am addicted to high stakes gambling. In fact, I am quite proud of it and I try to get better at it each day. I hope that if you are in the world of complex software delivery, you will feel the same way.

Either way, I would love to find out what you think. Especially if you try out any of the calls to action and uncover any insights that alter your future course of action.

Keep calm and Scrum on!