Regardless of the framework chosen, any iterative and incremental product development approach can be reduced to one goal: Creating a working product in short cycles.
A working product is “Done”. Done means “there is nothing left to do”.
“There is nothing left to do” implies that the result of the work is in a state that can be used by the end-users when released. Not only does it address the core functionalities but it also includes all performance and security-related concerns.
Ken Schwaber, co-creator of one of the most popular frameworks to deal with complex problems, explains it here crystal clear:
Ken Schwaber talks about the Definition of Done.
Furthermore, a short cycle is “a frequency that is short enough to reduce the risk of spending time on the wrong solution for too long (also known as a waste of money)”.
For instance, in Scrum, a Sprint is a short cycle that should not exceed one calendar month. It results in “Done” increments (working product) at latest at the end of the time box, but ideally multiple times during the process:
The 2019 Accelerate State of DevOps: Elite performance, productivity, and scaling (note: this is for software development context, and Scrum is not limited by software development)
A working product is the primary measure of progress. Powerpoint presentations or RAG status reports to monitor the state of delivery are more to manage stakeholder expectations than dealing with reality.
Heavy focus on the latter activities (circumstantial metrics) over outcomes is an open invitation to increase obscurity, dependencies, risk and negative ROI. It might pave the way for local concerns, fear, lying and a sycophancy culture. Some grave consequences are associated with that. If you don’t believe me, ask Nokia top/middle managers, engineers and external experts.
Is delivering a “working product” in short cycles enough?
So far everything we have talked is about “time to market”.
Reducing time to market requires technical excellence, ability to make changes to the product in an easy and fast way.
Technical excellence requires good engineering practices, automation, tooling e.g. and it eliminates a great amount of intrinsic & extraneous cognitive load.
John Sweller’s Cognitive Load theory adapted to Software Development context (inspired by Team Topologies) — the visual created by Sahin Guvenilir
But what about “delivering value”? Although reducing “time to market” enables delivering more value sooner (because the only way to deliver value sooner is… hmmm to release something sooner?), it does not guarantee it.
Well, the definition of value can be different based on the context. The criteria to take into account when defining value is not that complex though:
Simply, value is the benefit to the organisation (money, the return of investment), its customers (happiness) and society (number of people whose lives get better) that is generated as the result of using a product/service. So, consider these three as the high-level beneficiaries of value.
Now, imagine a team that can deploy into production on demand, multiple times a day. Their “change failure rate” is <10%. Their “lead time to change” from code committed to code running in production is less than a day. They also build an incredibly resilient/reliable system, and the “mean time to restore” doesn’t take longer than the blink of an eye.
But what if all they do is to deliver low-value items faster? What if the increments they deliver don’t make their customers happy? (if you rely on a revenue extraction business model, you’ll turn your customers into enemies!)
And that usually is the case when either there is no closed feedback loop between the producer (development teams) and the consumer (users of the product), or inspection is not followed by adaptation.
Take-aways:
- Technical excellence reduces “time to market”.
- Reduced “time to market” enables an organisation to deliver more value sooner.
- (2) is circumstantial. It can only help where constant inspection and adaptation take place. Otherwise, the organisation may end up delivering more non-valuable things faster.
- Ensuring technical excellence, quality and creation of “Done” increments only, even at the cost of delivering fewer outputs, is the accountability of the developers.
- Ensuring “value” is defined, clearly understood by everyone, continuously measured and “Done” increments crafted by the developers deliver the highest value possible is the accountability of the product professionals.
- Treating any threat to (4), (5) as an impediment and resolving (helping developers, product professionals resolve) those impediments is the accountability of the managers and all change agents.
Bonus: But B2C and B2B are different…
Yes, they are. No need to beat around the bush. At least, it’s my experience.
If the decision-makers of a B2B organisation don’t believe they need an iterative and incremental product development approach that requires frequent inspection and adaptation of a working product, that’s understandable. Their responses might be wired in this way since they are responsible for a “contract” that drives those behaviours. Or maybe, they are right?
But they need to ask themselves: “What is the evidence that asserts the big bang delivery would be a better fit to make my customers happy, increase ROI and minimise business risk for my organisation?”
Finally, Bas Vodde and Craig Larman have already discussed the impact of using traditional project contracting for Agile software development initiatives here: Agile Contracts
Introduction of Agile Contracts (https://agilecontracts.org/):
“Agile software development is fundamentally different from traditional project contracting.
Using traditional contracts for an Agile development project can endanger the project execution and causes the company to fail to get the potential benefits of Agile development.
The purpose of this page is to collect references to Agile contracting to support organizations to change their contracting models, reduce risk and get more benefits out of adopting Agile development.”
If I’d catch a Leprechaun, I’d sacrifice one of my wishes to have everyone in any organisation read their suggestions on the aforementioned document and think deeper about “contracting with a client and its impact on ways of working”.
Please feel free to write a comment or contact me to share your perspectives.