Join the Mastering Agility Discord community!
Even though many organizations now understand the mechanics of the Scrum framework, the adjoining change in approach to product delivery is often harder to grasp. Just the other day the traditional question arises: can you deliver product X by this deadline, within budget?
Ah, the old, trusted iron triangle. We couldn’t live with you, could we? Well, turns out we can! Fixed-date, fixed-budget projects will still continue to exist. Sometimes things have to be delivered before a certain deadline. A client comes to you and asks “Can you deliver by x date, and what is it going to cost me?”. Of course, we can deliver something. Let’s have a look.
Forecasting price range
A new product development effort requires a Scrum Master, a Product Owner, and 7 Developers. They have a deadline of six months from now. For the sake of argument, let’s say the average hourly rate is $100. They all work full-time (40 hours per week). Six months has roughly 130 working days, assuming no one would take a day off.
1 day of work = 8 hours x $100 = $800
130 total working days x $800=$104000
We have a team of nine people, so $104000 x 9 = $936000, purely based on labor. Add some resources like licensing etc. and we end up somewhere near a million dollars.
Photo by Christine Roy on Unsplash
Now, what’s going to happen if it appears during development, that we need more people because of underestimated complexity, missing skills that we assumed we had, or whatever other reason? In a worst-case scenario, we have to add 3 developers. Based on the previous calculation, $312000 would be additionally required. And that gives us a range to communicate. Giving a single digit, especially in the best-case scenario, really is putting the thumbscrew on. Unfortunately, I’ve seen too often money brings out the absolute worst in people.
“Dear stakeholder, we can deliver, and it will cost somewhere between a million and $1.312.000, based on the arguments mentioned above.”
“Alright, but there’s a fixed budget of 1.2 million dollars. What does that mean?”
The devil is in the details
The scope is where change should and will arise.
Keeping scope fixed, while budget and time are just as fixed, will lead to decreased quality. Things are likely to get rushed, and before you know it, testing, for instance, gets skipped. “We’ll fix issues when they pop up”. The thing is, this is actually costing you a whole lot more. Untested work could lead to poorer decision-making, as you don’t know if things will work as expected. Building on top of poor decisions leads to less qualitative work.
When those issues are only fixed when they pop up, there’s a chance you’ll destabilize the entire product. You could end up redoing a whole chunk of the product, just because a release was pushed and testing was skipped.
Photo by Romain Dancre on Unsplash
What is the first thing you hear when you didn’t deliver within budget or date? “But our contract says…”. And that’s where we need to go. Before starting this development, we need to add some provisions to the contract:
- Product Backlog Items that are yet to be picked up, can be swapped with one of the relatively same sizes
- The order in the Product Backlog can change at any time
- Additional releases may be requested, granted additional time and material fees
- In the case that the product has provided satisfying value levels, the contract can be terminated for 20% of the remaining unbilled value
Adding these lines in the contract provides flexibility in the scope and creates more focus on value, rather than delivering full scope. On the other hand, it gives the customer the option to terminate the development, in case the value expectations have been met in advance of the deadline.
Yes, we can work with a fixed-date, fixed-price projects
But we need to add some provisions to the contract. The majority of the stakeholders that I’ve worked with always wanted every single requirement, delivered yesterday, and for the lowest price possible. Of course, it goes without saying the quality levels should be top-notch.
And I would love to give my kids a unicorn, but that’s not gonna happen. The best thing that I could do to make a horse look like a unicorn is by taping a toy horn to its head. It’s not very transparent, but that’s pretty much what we would be serving our customers by keeping the iron triangle in place.
Adding those lines to the contract provides a more realistic scenario. Do we really need a unicorn, or is a horse sufficient? Respect is not a one-way street. Scrum Teams should give respect to the customer to create value with a realistic scope, and customers should give respect to the Scrum Team to bring that reality to the table. Don’t say “we can delivery on time, on budget, and on scope”, when you know you probably can’t.
Tell me, what’s the biggest organizational unicorn you’ve ever seen?