WeBlog
  • Agile Culture
    • Agile methodologies
    • Skills and expertises
    • Creativity and innovation
  • Management and Organization
    • Leadership
    • Work ethic
    • Team collaboration
  • Tech and Digital
    • DevOps and Craftsmanship
    • User experience and Digital Delivery
    • Data and Cybersecurity
  • EN
No result found
View all result
Discover Wemanity
WeBlog
  • Agile Culture
    • Agile methodologies
    • Skills and expertises
    • Creativity and innovation
  • Management and Organization
    • Leadership
    • Work ethic
    • Team collaboration
  • Tech and Digital
    • DevOps and Craftsmanship
    • User experience and Digital Delivery
    • Data and Cybersecurity
  • EN
No result found
View all result
Discover Wemanity
WeBlog

Let’s Stop the Abuse of Agile Terminology

by Marty de Jonge
12/2019
in Agile Culture
Agile terminology Wemanity

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”.

Let's Stop the Abuse of Agile Terminology

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.
Related post:  What are anti-patterns in Agile Contracting?
Let's Stop the Abuse of Agile Terminology
https://www.scaledagileframework.com/value-streams/

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…

Let's Stop the Abuse of Agile Terminology

If you liked this article, check The Dangers of Agile for your Organisation.

Marty de Jonge

Marty de Jonge

Related posts

Scrum Guide 2020: Is It Still Agile?
Agile Culture

Scrum Guide 2020: Is It Still Agile?

On November 11th, 2020, Ken Schwaber and Jeff Sutherland published the latest update of the Scrum Guide. With a first-ever...

3 months ago
What are anti-patterns in Agile Contracting?
Agile Culture

What are anti-patterns in Agile Contracting?

In recent years, the IT industry, in particular, is turning towards transparency and the adoption of agile contracts in partner...

3 months ago
7Ps Framework: give your meetings the thought and preparation they deserve
Agile Culture

7Ps Framework: Give your Meetings the Thought and Preparation they Deserve

How much of your life have you wasted on pointless meetings? Do you tend to find yourself saying: ‘This meeting...

4 months ago
Méthode OKR : pourquoi et comment l’adopter ? (avec exemples)
Agile Culture

The OKR Method: Why and How to Adopt It? (With Examples)

A project management technique popularised by Google, the OKR (Objectives and Key Results) method is used in many agile organisations....

4 months ago

Recommended

Why Your Well-Paid Developers Hate Your KPIs

Why Your Well-Paid Developers Hate Your KPIs

January 12, 2016
How Jurgen Appelo joined Europe's largest Agile Community

How Jurgen Appelo joined Europe’s largest Agile Community

January 23, 2018
The Product Approach: the Magical Ingredient Behind Digital Transformations

The Product Approach: the Magical Ingredient Behind Digital Transformations

October 6, 2021
Isomorphism, and How to Bring Your Webapp to the Next Level

Isomorphism, and How to Bring Your Webapp to the Next Level

January 19, 2016

Categories

  • Agile Culture
  • Management and Organization
  • Tech and Digital
  • Transformation & Change
Powered by Wemanity logo

Categories

  • Agile Culture
  • Management and Organization
  • Tech and Digital
  • Transformation & Change

Join our community and receive our newsletter.

Rejoignez notre communauté et recevez nos dernières actus.

Sluit je aan bij onze community en verkrijg onze newsletter.

No result found
View all result
  • Agile Culture
    • Agile methodologies
    • Skills and expertises
    • Creativity and innovation
  • Management and Organization
    • Leadership
    • Work ethic
    • Team collaboration
  • Tech and Digital
    • DevOps and Craftsmanship
    • User experience and Digital Delivery
    • Data and Cybersecurity
  • EN