No, We Are Not Taking Agile Too Far.
Written by Jan Vesterlund Mikkelsen, Manager | The 19th of May 2021
On April 9th, 2021 Colin Bryar and Bill Carr (former Amazon) released an article in Harvard Business Review (hbr.org) asking: “Have We Taken Agile Too Far?” Their article addresses the question if organizations “sprint” into coding too fast. The authors suggest adding Amazon’s Backward Thinking Model to make up for the agile shortcomings in product discovery as a tool to think about how to form your product and not waste time on useless coding.
This article is one of many recently released articles addressing misconceptions, issues, or shortcomings with the agile frameworks. It is important to remember the agile frameworks are frameworks and they will not prescribe what tools or models or technology your team(s) should use, even though some frameworks make persuasive arguments for several tools or models. Unfortunately, a lot of these suggestions send wrong signals or noise on something that is not based on agile.
The Agile Frameworks
The Agile Manifesto has just turned 20 years old – it has never been more popular, and it has also started becoming the default mindset of graduating talents from many universities and business schools. At the same time, there have never been more questions and resistance from “users”, and the number of articles and discussion forums debating challenges and problems are exploding. A key part of Agile is a growth mindset, so learning and questioning is a natural part of the journey.
Agile is not without problems and challenges, and the agile frameworks each have their advantages and areas where they will struggle. An experienced Scrum Master will know this and will help search how to mitigate these frictions.
That said, agile is frequently assigned properties which have nothing to do with agile or the agile frameworks, and it creates misunderstandings and discredits agile when the problem is somewhere else.
“Backward Thinking Model”
The article “Have We Taken Agile Too Far?” claims organizations will “sprint” into premature coding before the Scrum Teams have any idea what to build. The solution is to Introduce an Amazon practice called “Backward Thinking Model ” where the team is asked to imagine the product is ready to ship by drafting a press release announcing the product availability for its customers. If the team creates a compelling offer, they continue their discovery with their stakeholder.
The agile frameworks (Scrum, SAFe, etc.) do not prescribe how the work in the first sprint should be done. The only commitment for the team is to create “any aspect of a usable Increment each Sprint” (Scrum Guide 2020). There are no requirements from Scrum or SAFe or any other agile framework to jump into coding. Often teams will do this as a default reaction or habit that product value is created by coding, but if the team can create something that could be useful and valuable build with duct tape, it is good enough. “Sprint” does not mean how fast we can get the developers to sit in front of their keyboards, but it means we need to learn as fast as possible.
When to use “The Backward Thinking Model”
The “Backward Thinking Model” fits into the agile frameworks. It forces the Scrum Team to think further than the current sprint, and, without a lot of experience with the model, I believe it is a way for the Product Owner and the Development Team to craft a Product Goal. It seems Amazon has great success with this model and that is great, and the article is hopefully a great inspiration for an organization in a similar place in their product cycle. But it does not fit into all organizations or for any product. The “Backward Thinking Model” is a tool to be pulled out by the Scrum Team or the Product Owner if/when they believe it can add value to understand what to build.
There is a vast number of tools and methods that work well in the agile context – and an experienced Scrum Team can know when to use what and why. The Scrum Master will of course assist if needed.
CMP is dedicated to helping our clients succeed – we strongly believe solving complex challenges need an agile mindset and a supporting toolbox to ensure valuable outcome to the customers. Our consultants are experienced with Scrum and SAFe to take roles as product managers/owners, developers, Scrum Masters, RTEs, or Agile Coaches. Let’s talk over a cup of coffee to see where CMP can help.
ABOUT CMP
Our name, Capital Market Partners, reflects what we define as our core service: Business understanding based on extensive experience in applying technology in the capital market area.
As a business partner, we offer consulting services based on our combination of business understanding and IT know-how. Our work analyzes, implementation of IT systems and other projects supports strategic decisions at different levels in complex business contexts.
For further information – Please contact:
Lars Christiansen
Managing Partner
Tel: +45 2993 4678
