There are different levels of understanding\u00a0Agile.
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.<\/p>\n\n\n\n
Welcome changing requirements, even late in development.\u00a0 The Agile Manifesto is quite clear on this: In Scrum according to the maturity of the team, you can welcome changes also during the sprint. 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?<\/em>“. Customer collaboration over contract negotiation<\/strong><\/p>\n\n\n\n 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. With experience the\u00a0good 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.<\/p>\n\n\n\n Collaborate with your customer, know the industry history and evolution, competitors and partners.\u00a0Look for feedback in a short cycle and don’t get lazy: invite your customers to sprint reviews.\u00a0\u00a0Don’t assume your customer has no time. Don’t think they aren’t agile.\u00a0Agile 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\u00a0unless you make it so. Technical roles are people, consumers, end-users of services\u00a0and products in practically every industry\u00a0(or almost).\u00a0 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 both your customer and your agility are mature enough, you may be ready to get to the next level. The Money for Nothing and Change for Free<\/strong> contract<\/a> pattern challenges the traditional view and provides a radically innovative business model.\u00a0<\/p>\n\n\n\n Here a quick example on how the contract would work:<\/p>\n\n\n\n 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<\/strong>. Let’s recap the finances<\/strong><\/p>\n\n\n\n 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. If you run at 5-10x of your competitors velocity and quality, you should generate 5-10x more revenue.\u00a0<\/p>\n\n\n\n Why do so few great Agile teams do this? Scrum is designed to create hyper-productive teams.<\/strong> These teams require to be immersed in a highly open, transparent, generative environment.
<\/strong>
One of the common misconceptions in the initial phase of Agile implementation and particularly\u00a0of 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).<\/p>\n\n\n\n
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.<\/strong><\/p>\n\n\n\n
Product Owners and Teams assess if the request for change endangers or change the sprint goals.\u00a0If so, the Request for change (RFC) needs to wait for the\u00a0next train or the sprint should be canceled. If not, the Scrum Master is there to facilitate the negotiation\u00a0process and observe if the requested deviation is acceptable or not.\u00a0If it is happening at the right moment or not. If this type of request is an exception or it is a chaotic\u00a0norm 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.<\/p>\n\n\n\n
The trainer memorably answered\u00a0straight forward: “No, it means you don’t know what you are doing<\/em>“.\u00a0\u00a0<\/p>\n\n\n\n
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.\u00a0If it was like playing roulette, it wouldn’t require qualified\u00a0professionals. <\/p>\n\n\n\n
There may be periods where you don’t get many feedback from clients and then several requests come all at once like London buses.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/strong>
If the customer maintains full participation in Scrum\u00a0during 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.<\/p>\n\n\n\n
“The Money for Nothing and Your Change for Free<\/a>” 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.\u00a0The 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.\u00a0The 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.\u00a0
The Old way of thinking may sound\u00a0like: “Finishing the project before? Are you crazy? What do you sell after? Do we send developers home?”<\/em>
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\u00a0customer satisfaction…<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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!<\/strong>
On the other side the\u00a0Scrum 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.\u00a0And their developers are now ready to work on the next project<\/strong>!<\/p>\n\n\n\n
<\/strong>
There are many reasons and the topic probably requires a series of articles. Let me give you a hint.<\/p>\n\n\n\n
These teams need to be surrounded by Agile leaders. Extreme success requires the whole organisation to embrace and implement extreme agility.\u00a0DevSecOps, 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.<\/p>\n\n\n\n