There are different levels of understanding Agile.
The first one is where you care about rules. You take every best practice, guide, book, training suggestion and you make a strict process out of context and without interpreting the reality. That’s not Agile. That’s you using Agile to cover your need of implementing bureaucratic policies.That’s you not willing to change, to listen to the people around you, not capable of reading the room, not flexible enough to adapt.
If you think of Agile as something static that once implemented doesn’t change, you are wrong. Agile is meant to evolve. Agile implementation for your team and organization needs to be tailored and follow the growth respecting the diversity of each context, industry situation. Is everything relative? No. That’s why the Agile Manifesto is made of values and principles rather than rules and commandments.
Welcome changing requirements, even late in development.
One of the common misconceptions in the initial phase of Agile implementation and particularly of Scrum implementation is thatSprint Scope cannot or shouldn’t change. Or if we accept a change as a team, we are not doing pure scrum (what does that even mean?) or the team feels dirty (not making pure scrum) or wicked (saying yes to everything).
The Agile Manifesto is quite clear on this:
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
In Scrum according to the maturity of the team, you can welcome changes also during the sprint.
Product Owners and Teams assess if the request for change endangers or change the sprint goals. If so, the Request for change (RFC) needs to wait for the next train or the sprint should be canceled. If not, the Scrum Master is there to facilitate the negotiation process and observe if the requested deviation is acceptable or not. If it is happening at the right moment or not. If this type of request is an exception or it is a chaotic norm that skew progress metrics, reliability and predictability.
For instance, if your sprint is 2 weeks welcoming 1 small change every 10 days is not a big deal. If the team is asked to make 10 changes a day then it means there is something wrong.
I was attending a Scrum training for Product Owners when one asked the instructor “If there are many requests for change during the sprint, could it be just due to the industry or product complexity?“.
The trainer memorably answered straight forward: “No, it means you don’t know what you are doing“.
Customer collaboration over contract negotiation
You ask developers when it is ready, how long it takes… but you are not capable of seeing 10 days ahead. Your client wants a weekly status update.
It is difficult to have a roadmap; to write sprint goals; to manage your customers; to understand what users want; to beat competitors; to innovate. Sure it is difficult, but that’s the job. The product manager’s job. If it was like playing roulette, it wouldn’t require qualified professionals.
With experience the good product owner acquires the skills to manage the portfolio, catch big and small signs from customers, analyse data to picture more details as possible on how the product will or may evolve.
Collaborate with your customer, know the industry history and evolution, competitors and partners. Look for feedback in a short cycle and don’t get lazy: invite your customers to sprint reviews. Don’t assume your customer has no time. Don’t think they aren’t agile. Agile adoption goes beyond IT and development to other organizations in the business. Don’t be afraid to have developers, business analysts, UI/UX and clients in the same room. It is not awkward unless you make it so. Technical roles are people, consumers, end-users of services and products in practically every industry (or almost).
There may be periods where you don’t get many feedback from clients and then several requests come all at once like London buses.
While in traditional project management that is an issue, teams welcome changes in Agile, because there are patterns to manage these requests, to keep them under control, to prioritise them by value and to understand where the 80% of the value resides.
Money for Nothing and Your Change for Free
If the customer maintains full participation in Scrum during the entire project, the customer should be able to make changes to the scope without incurring any additional cost if total scope of contracted work is not changed. New features may be added for free at Sprint boundaries if items of equal scope are removed from the contract.
If both your customer and your agility are mature enough, you may be ready to get to the next level.
“The Money for Nothing and Your Change for Free” strategy has been widely deployed as the basis of many agile contracts. The principle is simple. Old contracts make customer pay for requests for change. The customer is punished for giving feedback and for discovering what they want. Companies want to keep customers happy so they will try to minimise or accommodate requests for change. The extra bill arrives in the form of more days (delays) and every side accepts the painful status quo. In projects where customers are billed not by delivered value but by available resources per day, dragging a project longer than necessary becomes the business model.
The Old way of thinking may sound like: “Finishing the project before? Are you crazy? What do you sell after? Do we send developers home?”
With these premises, no surprise that changes are usually not welcome. With such absence of vision, lack of entrepreneurship and innovation, the logical consequences are project delays, extra costs, issues with customer satisfaction…
The Money for Nothing and Change for Free contract pattern challenges the traditional view and provides a radically innovative business model.
Here a quick example on how the contract would work:
A Scrum software house signed a $10 million contract to deliver a software over a 20-month time frame.If the customer firm wanted to terminate at any time, they would pay 20% of the value of the remaining contract. This encourages both parties to collaborate to achieve a common goal: make the software work the way the customer wants ahead of time.
The Scrum team starts sprinting, customers attend reviews and provide feedback directly. Customers redirect developers’ efforts towards more valuable features. They repeat this for a couple of months. After the 6th sprint, the customer got the software in production with the amount value they needed and terminated the contract.
Let’s recap the finances
In the first 3 months of the contract, the customer paid out $1.5 million to the Scrum software house. Early termination requires the customer to pay 20% of the remaining $8.5 million which is $1.7 million.
They were ok with paying $10 million for a software that would take 20 months. They got what suits their needs for a total of $3.2 million and 17 months earlier!
On the other side the Scrum software house, let’s say, was expecting roughly a profit margin of 15% which means in the first 3 months they spent $1.3 million for development.
Receiving $3.2 million their profit margin jumps from 15% to 60% – a 400% increase in earnings. And their developers are now ready to work on the next project!
If you run at 5-10x of your competitors velocity and quality, you should generate 5-10x more revenue.
Why do so few great Agile teams do this?
There are many reasons and the topic probably requires a series of articles. Let me give you a hint.
Scrum is designed to create hyper-productive teams. These teams require to be immersed in a highly open, transparent, generative environment.
These teams need to be surrounded by Agile leaders. Extreme success requires the whole organisation to embrace and implement extreme agility. DevSecOps, compliance, legal, marketing, finance, HR, R&D, business, development, sales, management, executives…
If even one of the departments is not ready to understand the importance of implementing agile culture, there will be obstacles in accelerating success and revenues.
According to the 14th annual State of Agile survey, the top 5 responses cited as barriers to adopting and scaling Agile practices are:
- General organization resistance to change
- Not enough leadership participation
- Inconsistent processes and practices across teams
- Organizational culture at odds with agile values
- Inadequate management support and sponsorship
* * *
I write about organizational patterns, transformational leadership, healthy businesses, high-performing teams, future of workplace, culture, mindset, biases and more. My focus is in leading, training, and coaching teams and organizations in improving their agile adoption. Articles are the result of my ideas, studies, reading, research, courses, and learning. The postings on this site and any social profile are my own and do not represent or relate to the postings, strategies, opinions, events, situations of any current or former employer.
This article has been published for the first time on danieledavi.com by the author Daniele Davi’.
© Daniele Davi’, 2021. No part of this article or the materials available through this website may be copied, photocopied, reproduced, translated, distributed, transmitted, displayed, published, broadcast or reduced to any electronic medium, human or machine-readable form, in whole or in part, without prior written consent of the author, Daniele Davi’.