Consider how you could take a similar path, how through the work, you might collectively come to value customer collaboration over contract negotiation, or responding to change over following a plan. Passionate advocacy doesn’t do that job. Shared experience does.
In this episode, Richard and Peter answer a listener question about whether an Agile approach can work with a customer-funded project model or whether you have to change your funding approach to work in an Agile way. They address the implications of Agile for things like funding, why project funding works for some orgs, and how to change things like funding in an Agile way.
Referenced Resources
Humanizing Work Show Episode 77:They’re All Customers
Learn More
Join the Humanizing Work Community and rsvp for upcoming sessions here. Our next session:
They’re All Customers: Customer Research to Improve Stakeholder Relationships
November 16, 2023, from 5:00 PM to 6:30 PM MST
All the tools for customer research aren’t really about understanding customers. They’re about understanding other humans. You can use customer research tools—sometimes with a little adaptation—to understand needs, problems, and possible solutions for anyone in almost any context. In this sense, they’re all customers.
In this session, Richard and Peter look at how customer research tools are useful in all kinds of contexts beyond product development. Got a relationship with a stakeholder at work that you’d like to improve? Learn how you can use customer research tools to better understand that stakeholder’s needs and how you and your team can help solve them.
Contact Us
We’d love to hear from you! Tell us what you’ve found useful on the show. Tell us what you’d like to hear us talk about more. Maybe share a challenge you’re facing in your work that would benefit from a Humanizing Work Show perspective. Shoot us a quick email at mailbag@humanizingwork.com.
Episode Transcript
Peter Green
Welcome to the Humanizing Work Mailbag, where we answer questions from the Humanizing Work Community!
Richard Lawrence
This week, we’re answering a question from a listener about Agile and project funding. There was a whole back and forth email thread, but to summarize:
In this person’s organization, there’s a mix of different Agile and traditional approaches across different teams. Work is mostly structured as projects and, importantly, projects delivering specific features for specific B2B customers who are funding the work. The PMO leadership there recently halted any moves towards a larger Agile transformation because the project funding model can’t go away.
And so, our listener asked us to reflect on whether an Agile transformation requires a change to the funding model.
Peter
Richard, let’s ground this first in what we mean by Agile, and how that might relate to different project funding models. The original Agile Manifesto lists four value pairs, and most of our listeners will be familiar with these, but in case anyone listening isn’t, here’s what the authors of the Agile Manifesto said:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan.
That is, while there’s value in the items on the right, we value the items on the left more.”
So, the situation that our listener is describing sounds to me primarily like a conflict related to those third and fourth value pairs; the customer collaboration over contract negotiation and responding to change over following a plan. So, it really is a conflict about “should we take an Agile approach here? Do we value the right side items more, or the left?”
Richard
This is an interesting situation because the PMO leaders opposing the Agile transformation actually see an implication of Agile that many proponents of an Agile approach miss.
Put simply, if we’re learning as we do the work what’s most valuable and what’s not, and if we’re always trying to focus on the most valuable thing a team could be doing, funding a big batch of work when we know as little as we’re ever going to know about it is pretty counterproductive. Which is to say, Agile, taken seriously, implies changes way beyond the team, including things like funding.
Most organizations see an opportunity there. This one sees a threat. So, to start, let’s think about why…
I think we can use the “stakeholders as customers” idea that we talk about in episode 77, and we can treat the project model as a product people hire to do jobs for them. What might those jobs be?
Peter
Thinking about the jobs that model might be doing for, for example, this company’s leadership, I imagine they would include things like:
- It’s straightforward to sell a batch of work for a certain price.
- It concentrates decision-making on scope into a short period of time rather than sort of leaking it out over a long period of time.
- It probably limits the negotiation and back-and-forth—sign off on all the scope at once.
- It’s almost certainly simpler account management because scope isn’t changing that frequently.
- The risk model is clear.
- The comp model for salespeople selling projects is well established and super clear.
Richard
And I think there are also some jobs the project model is doing for the PMO in their role:
- Competence
- I feel successful when I deliver projects
- I know how to manage scope and cost
- Status
- Maybe there are even some status jobs there that are threatened. Like, other roles in an Agile approach take much of what were historically PM functions
Peter
All this to say, there may be very good reasons to stick with that project funding model. Or, at the very least, there are benefits to that model for the organization today that you’d want to try to maintain if you changed the funding model. Going back to that idea of a shift from right to left in the agile value pairs, the company has built what sounds like a pretty successful business model around good contract negotiation and following plans, and possibly for charging more to change those plans. So you can’t just decide to change a shared value or declare it to be so. There are all kinds of trade-offs, unintended consequences, and a variety of incentives in place that will fight tooth and nail against changes at that level. Notice the sentence just before the values in the Agile Manifesto, where they say “through this work, we have come to value…”
Of course, there’s nothing preventing you from choosing to see a project through, even if some of what you originally planned to do no longer seems valuable. If finishing it all has value for the buyer, that’s a business decision. The Agile approach certainly gives more options for spending, but no one’s actually requiring you to change how you spend your budget.
Richard
Let’s get a little more practical on this: I want to dig into two questions, I guess:
- What would it look like to retain a customer-funded project model while adopting elements of an Agile approach across an organization like this one?
- What’s an “Agile” way to explore changing the funding model without putting what seems to be a functioning business model at risk?
So, on that first question, I actually experienced this. My last role before going independent in 2008 included leading software development projects for my employer’s clients. The company I worked for would sell large software projects to businesses, to nonprofits, to government agencies under pretty typical consulting agreements. There were scope, time, budget and there was this whole process for change orders and additional charges. As a pioneer for an Agile approach in that organization, I had to work within that structure, at least at the start.
So, what were we able to use from an Agile approach on those teams?
Several things. First off, there was nothing preventing us from building a cross-functional team.
We were able to work in short iterations delivering increments of value, and we modeled those with features and user stories, much like I teach today,
We used reviews to get early feedback from stakeholders, we used retrospectives to refine how we worked together.
Even just this—just basic Scrum—improved our experience of work by allowing us to collaborate closely and see meaningful progress every few days, and it reduced delivery risk for our project because we had this real measure of progress every day, not just status reports.
We took it even a little bit further: We prioritized the work, which further reduced delivery risk and even began to allow incremental releases, which improved the value for our customers.
Now, onto the second question, “What’s an ‘Agile’ way to explore changing the funding model without putting the business at risk?” Because we started prioritizing the work to put value and complexity first and started releasing incrementally, it became clear that the original project that we’d estimated and planned and written a contract for wasn’t really want the customer ended up needing.
So, we had to renegotiate the scope to maximize the value. Sometimes, we ended up coming in early and under budget (which I actually got in trouble for once—I didn’t realize how much the business model was built around change orders and scope increases). That’s a different story.
After a handful of experiences with delivering more value than planned and with learning along the way, we were able to begin having conversations about alternative funding and contracting models like relational contracts instead of scope-based contracts. And over time, the Agile approach did expand out into budgeting, but it was via small experiments with alternative approaches. Not a big change all at once.
Peter
I think there’s a key point here, which is that it wasn’t a binary choice, like you can either do long-running funding of value streams, kind of an Agile approach to it, OR fixed-scope projects funded by customers. You started exploring this wide range of options for funding and contracting that made different tradeoffs.
Anyone who’s listening, let us know if you want us to talk more about those types of options in a future episode.
Richard
Ya, that’s right. But notice how that change in my story happened. It wasn’t a big overhaul of the funding approach. It was working within the project funding model until it became clear that an alternative would be mutually beneficial for both us and for our customers, and that was the point where we started experimenting. So, it still wasn’t “Let’s think along this continuum and pick the best one theoretically. It was “Let’s make space to experiment, and then do the experiments.”
Peter
Richard, I love in your example that, when you wanted to shift from the right to the left on those value pairs, you didn’t simply declare “we’re Agile, we value this now.” Instead, you examined how the current value served you and the organization, how the other values, the more Agile values in the manifesto, might better serve you and the organization, and then what you’d need to trade off if you shifted those values. Then, as you began to see some real benefits in that shift, you still didn’t just leap over. You couldn’t think or argue your way into it, you and the organization really had to experience the actual upside and downside for yourselves. And then you did it incrementally, learning what would happen, and building trust over time that the new thing is actually better.
So for our audience, consider how you could take a similar approach to Richard’s in this example, and to the original authors of the Agile Manifesto. How, through the work, you might collectively come to value customer collaboration over contract negotiation, or responding to change over following a plan. In my experience, passionate advocacy doesn’t do that job. Shared experience does.
Richard
So, to summarize:
- An Agile approach does ultimately imply changes to many things beyond the team, including funding and budgeting.
- A project-based funding model does valuable jobs for individuals and organizations. And any change to the funding model needs to be aware of these jobs and either still meet those needs or somehow mitigate for their loss.
- You can get significant benefits from elements of an Agile approach within traditional funding models. There will eventually be friction and waste, like I experienced, but you don’t need to solve for this on day one.
- And finally, the way to transition from project funding to a more Agile funding approach is to show the potential first and then experiment with alternatives.
Peter
Ya, I love that advice. Thanks for tuning into the episode. If you liked our take on this, please share it with others who might benefit. Liking, subscribing, commenting and sharing on YouTube make a big difference to how many people might see the show, and rating and reviewing in your podcast app if you’re listening there is super appreciated. You can also get more content like this from us with our weekly newsletter, where we share one key idea every week that has helped us and our clients. You can subscribe on the footer of any page at humanizingwork.com.
Last updated