If you buy a duck, then treat it like a duck deserves to be treated. Don’t expect it to jump fences. Same thing applies to agile terminology.
For starters and the sake of clarity, I consider myself to be an Agnostic Agilist. This doesn’t mean much more than the fact that I see Agile as an umbrella concept, a mindset, in which various methodologies, models and customs can find their place. I surely do see the value of Lean, XP, Scrum, design thinking and other commonly used Agile techniques, but I also see the value of waterfall or Prince II if these add value in a certain situation for a specific organization.
So I certainly do not evangelize that all and only “modern” methodologies used are always good for every organization, but there is something that really annoys me however. The heartless and deliberate misuse of the terms used within different techniques and frameworks.
Not only does this unfairly give a bad name to these practices, but it also creates a false picture of the value that these applications can provide for organizations that use agile terminology incorrectly.
2 examples:
‘We are delivering a Minimum Viable Product!’
The term Minimum Viable Product (MVP) was coined in 2001 by Frank Robinson but became really popular and known by the book of Eric Ries “the lean startup”. The essence of an MVP is “a product with just enough features to satisfy early customers and provide feedback for future product development.” Or how I personally like to describe it. “Can your product just survive and breath without it? Then it is probably not a part of your MVP!”
Although the term MVP is nowhere mentioned in the Scrum guide, the use of it fits perfectly in the proven effectiveness of delivering incremental pieces of working products. Working with MVP’s provide great inspect and adapt opportunities.
Scrum proved especially effective in iterative and incremental knowledge transfer. — Scrum guide 2017
True story: When I stepped into this organization that had been working on their Agile transition for a while and I spoke to one of the teams, they told me the following. “When we started working in these newly formed teams 6 months ago, we did an ‘Agile awareness training’ of 3 days. At the end of this training we prepared our MVP proposal and presented it to our stakeholders. After the MVP was determined together with them, we started developing it as a team. “ Doesn’t sound crazy in itself, does it?
So I asked them how they’ve experienced the development of their initial MVP? What did they deliver? What were their learnings? Their answer was “We don’t know yet, we are still working on the MVP”. Wait? Stop for a moment … you have been working with the team for 6 months and the initial MVP has not yet been delivered? Let me see.
I learned that the “MVP” they were talking about was the complete migration of a business application to the cloud. A project with many dependencies and risks.
When I did some further inquiries, it turned out that at the start of the Agile transition, this migration had been characterized as ‘critical to achieving the financial objectives’ this year and therefore got the label “Minimum Viable Product”.
MVP reality versus expectation
‘We are organised in Value Streams!’
Values streams can be described as “ a representation of the flow of goods from supplier to customer through your organization.” In this description a value stream is represented as an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end-user. Value stream mapping became a popular practice with the rise of Lean in the second half of 20th century as part of the Toyota Production System. Probably the most recognizable it is also embedded in the SAFe framework. In SAFe, there are two types of value streams described
- Operational value streams — The steps used to provide goods or services to a customer, be they internal or external.
- Development value streams — The steps used to develop new products, systems, or services capabilities.
Since the core role of the Product Owner in Scrum is to be “ the value maximiser” the concept of using Value Streams can be of great help for him/her to achieve the goal in building the right thing. Besides the benefits for the Product Owner it has also proven to be a great guidance for the development team in the context of self organisation and building the thing right.
The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. Scrum guide 2017
The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team. — Scrum guide 2017
True story: Talking to a senior manager during an intake interview. “Ok, so you scaled up the agile transition about 3 months ago by implementing SAFe. What was the reason for choosing this specific scaling framework and what value do you get out of it right now?” The man has to think about it for a moment … “Well, why we specifically choose SAFe I don’t know exactly, but the agile program board together with << large consultancy firm Incorporated>> advised this framework. And we are starting to get a better view of the value it delivers because we are now aligning the organization along value streams. “ When I asked a bit deeper to inquire how those value streams took shape, it turned out that they saw “value streams” as the combination of process steps in the product journey where the greatest impact could be made on improving the $ net profit. They connected the principle “value” directly towards financial parameters. Sounds good in the yearly shareholders meeting of course, and eliminating waste never hurts, but the chance that the customer value (operational value stream ) or the development team value (development value stream) will improve with this approach is not that big.
Conclusion
Using the term MVP while the delivery is expected to be a complete project is killing for a successful transformation. Leadership has the impression that the objective is easily obtainable. (it is estimated as just a MVP right?, how difficult can that be? ) Teams started feeling the pressure that they’d given a commitment to deliver this project instead of a forecast. They were not given the ability to experiment, learn and grow as a team. Finally, when the migration is not delivered as expected, the organisation is likely to say “working with MVP’s is just consultant bullshit”. Same with the described misinterpretation of what a Value stream actually is. By abusing these kind of thoroughly overthought and practiced agile terminology, the real value they can bring is denied.
You could argue that using the terms like they choose to, it is part of the “self organisation” of the company of even refer to Shu-Ha-Ri, where the end state is to be able to bend the rules. I state against it that in order to be able as an organisation to create a new/own version of a framework it should first master the practices as intended.
The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage. — Scrum guide
First you should synchronise on things like a common language, follow the rules and events as describes before you take the lead and are ready for a handover towards your own journey.
If you start on the wrong foot, and create misunderstanding over the words that are being used, you know what could happen…
If you liked this article, check The Dangers of Agile for your Organisation.
