Riffing Off the Agile Manifesto: Investing over Budgeting

Some of my daughters’ art work.. and some guitars…

Riffing

In music terms “riffing” means we liked the idea you had there, we took it and did something with it. We are building on an existing idea.

Preamble

The ideas in this series of articles were not being talked about with the exception of very few people many years ago. While the agile software industry was primarily focused on delivering more faster, people like David Hussman, “The Dude”, were thinking about products and pointing out that it doesn’t matter how fast we can deliver if nobody cared what we were delivering.

I have been impacted by working closely with people who worked with the dude directly. And I feel the industry is still struggling with these ideas. This series of articles is a call to remember the dude, the power of these ideas, and those still working to help people think about the impact of their products and learn in the flow of their work.

Articles In Series

Riffing Off the Agile Manifesto: Preamble

Riffing Off the Agile Manifesto: Investing over Budgeting - You Are Here

Riffing Off the Agile Manifesto: Measuring Impact over Counting Story Points

Dude’s Law - What is Dude’s Law (1)

Value = Why/How - “When people are stuck on how do it, and as that goes up, like any simple equation they forget why they are doing it and the value they are trying to get out of it goes down.” - David Hussman - The Dude

“If I can’t come to grips or if I can’t validate, especially to the most skeptical person in the room what value they are going to get out of it, why we’re doing it, then just telling them how to do it over and over again doesn’t really solve things.” - David Hussman - The Dude

“What’s the least amount of process that helps us show value, address our issues, or augment our strengths.” - David Hussman - The Dude

It would be helpful to consider the thoughts above more often.

Iterative Investment over Iterative Progress

Based on what we’ve learned, should we continue investing?

What would have to be true for this question to be part of your organizations thinking? Too often we are stuck thinking about how much more we have to do before the whole thing is done. How can we help shift thinking to the idea that maybe we don’t need ‘the whole thing’ to be done?

Instead of talking about being 20% done, what if we discovered that 20% or 10% or 5% of the thing being done was enough, and the remainder should not be done at all?

What we are talking about is shifting from talking about the progress we are making towards some imagined final version of a product to validating what we have done so far against it’s actual value.

Funding Models

Software creation is an evolving practice. We discover things as we go and this demands that we adjust traditional budgeting to match.

“How am I supposed to plan a budget for this work?”

Very valid and important question. But given the nature of the work, rather than invest in a project for the next calendar year, we invest in a team of people for a given time period.

Lets assume funding 1 team for 1 month where we work collaboratively. And I mean really collaboratively; everyone together “working on the same thing, at the same time, in the same (virtual) space, and at the same (virtual) computer (2).” -paraphrased-

Actual steering takes place. Decisions are made at the place the work happens. Priorities adjust in real-time. And a natural rhythm occurs. When we can steer frequently there is more authentic engagement rather than micromanaging predetermined deliverables.

At any point in time funding decisions can be made. We can pause to measure actual impact, we can continue down the path we are on, or we can stop altogether and shift to something else. This ironically provides more control vs the annual budgeting process.

Learning drives investment since each funding decision is based on actual results and learning. We have product discovery through iterative delivery.

Trust builds through small bets rather than being tested against one big delivery.

Artificial urgency is reduced as the pressure to justify a massive budget no longer exists. Teams can focus more on real value instead of rushing to show something that validates the big spend.

What is tough about this shift in thinking is moving from “getting what I paid for” to “investing in the right direction.”

Was This A Good Idea

What does measuring the impact of what we are doing look like?

What will tell us if what we did was a good idea or not?

What would have to be true for us to have conversations around validating what we did, with some measurement once our product is out in the wild?

For a while now, teams have had and continue to have conversations around when something will be done. The definition of done is often a checklist of things in a ticket around, “code is unit tested”, “Code Reviewed”, “Non-Functional requirements met”, “Functional Tests passed”, “Product Owner accepted the User Story” and others depending on if you are talking about User Stories vs Features vs Epics or whatever your favorite flavor of burden might be. And then we are quickly on to the next story/feature/epic.

With your teams, start with thinking about what validating if the thing we delivered was a good idea or not before we start coding. Then we can build towards that outcome. This helps to get us bonded around what good looks like. Then before we start the next thing, we validate our idea.

Think of a board used for tracking work. Done is not the end. Validated is.

References

[1] Hussman, D. 2012, “Dude’s Law”, Shinkle, C., Video Source Site Reference

https://www.nuagility.com/glossary/dude's-law

[2] Zuill, W. and Meadows, K., 2022, “Software Teaming, A Mob Programming, Whole-Team Approach. Second Edition”

https://softwareteaming.com/