The agile blender blunder
Nothing wrong with re-using existing material…
Imagine you are going to develop a new software component, a framework, something like Angular for web front-end development or Apache Kafka for messaging. These frameworks are huge. You cannot possibly write every single line of code yourself. You don’t want to re-invent the wheel, so you will rely on existing code, existing 3rd party libraries, as part of the building blocks for your framework. There is nothing wrong with that. After all, the NIH-syndrome is way worse. But there is a caveat: not all open source libraries apply the same license. There is GPL, LGPL, MIT, BSD, Apache, to name a few. Not all licenses allow commercial usage, so if you would consider selling your framework, you better watch out which components you would re-use… For more about open source software licenses, check out this page at opensource.org.
Also outside software development
Now, for re-use of non-software components, there are similar licenses too. Best known is the Creative Commons license with its different variations: some allow free usage, but no copying, other allow copying and even commercializing derived work. It all depends how far the original author/creator wants to go. Similar to the example I gave about the software component, you could say that you don’t want to re-invent the wheel if you want to create a new methodology or extend an existing one. So if there are good concepts or techniques that would perfectly fit in your methodology, why not re-use it? As long as you respect the Creative Commons license the authors had selected for their work, there shouldn’t be an issue. Yes, depending on the license, you are allowed to “remix” (as it is called) someone else’s content. If you want to know more about the different CreativeCommons licenses, check out this page on creativecommons.org.
Lately however I often read posts and articles about known agile concepts being quoted without reference to the original authors or even being miss-quoted (or deliberately changed). Some articles are very detailed about e.g. statements from the Scrum guide that were copied and changed to fit in the context of the ones copying the information, like this one. Bottom line of these articles is not just about the fact these concepts were mis-quoted, but more about the fact that the original idea and mindset got entirely lost.
Also Manuel Pais recently posted a message on LinkedIn about Team Topologies stating that certain things about team topologies were not explained correctly, or the way they were meant to be.
This made me think about several things I noticed myself. It feels like some agile (or other) concepts were copied from an original idea, and put in a blender to make it blend nicely and smoothly with the basic ideas of the framework. Doing so, some words or letters got lost so they had to be replaced by something else. Coincidentally, also the author of the original piece got lost/dissolved in the blending process…
Here is my list of things I noticed that got “blended” away…
TL;DR
- Story splitting patterns with some name changes and the addition of an unrelated “pattern” use case scenario’s
- INVEST, where the V stands for Verifiable (or not?)
- Planning poker becomes Estimating Poker
- Deming’s PDCA cycle where the A stands for Adjust instead of Act
- DevOps being explained using the acronym CALMR instead of CALMS
Story splitting patterns
Richard Lawrence spent a lot of effort explaining how to properly split user stories, including his story splitting flowchart that has already been translated in many languages. To me this has always been my preferred resource for explaining how to split user stories to a sprintable size. He talks about 9 story splitting patterns:
- Workflow steps
- Operations
- Business rule variations
- Variations in data
- Data entry methods (in the flowchart called interface variations)
- Major effort
- Simple/Complex
- Defer performance
- Break out a spike
Without referring to Richard’s work these patterns find their way, somehow, in slightly modified form in a document called “User Story Primer”. The document however contains no reference at all to the original material nor its author. This is what comes out of the blender:
- Defer System Qualities
agreed, Richard mentions that this is also about other non-functional requirements, but why not stick to the original wordings? - Break-out Spike (?)
what does that even mean?
And by surprise something entirely new came out of the blender: Use case scenarios. Use case scenarios? As story splitting pattern? As far as I know, stories are something entirely different than use cases. They serve a different need:
- a user story is something temporarily, an invitation to talk about the required change, that can be discarded once implemented
- a use case is persistent documentation about the system, offering an overview of all the (high level) features of a system and their involved actors.
Alistair Cockburn once said about use cases and user stories: “A user story is to a use case as a gazelle is to a gazebo”. They sound similar, have some letters in common, but are different things. So why user story scenarios got into the User Story Primer as story splitting pattern is still a mystery to me… You could think that this was based on or refers to Use Case 2.0 but that can’t be: the user story primer dates from 2009 whereas Use Case 2.0 is a spec from 2011 (unless a certain mister D.L had a preview of the spec in progress).
INVEST user stories
We all know that INVEST stands for:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
For some reason that same User Story Primer document explains the V of Valuable as Verifiable. Most likely this is a mistake, because further in the document it is correctly explained as Valuable. I just wonder what the difference should be between Verifiable and Testable though…
The document User Story Primer is a rather old document by the way, copyright and dated 2009. It is just strange that this document never got corrected and that the same version can still be downloaded from the website of a large scaling framework.
Planning poker
Planning poker is an activity we know as a way to quickly come to a relative estimation of backlog items. No need to explain the process of Planning Poker: Mike Cohn has very good documentation on planning poker.
And yes, some people tend to flip the words around, talk about poker planning, but the correct term is planning poker, not otherwise. Somehow, when adding the concept to the large drawing of a scaling framework, the word Planning got lost in the blender. Some people now call it Estimating Poker. Well yes, the purpose is to have estimations, but the entire world knows it as Planning Poker, so why yet another name and call it Estimating Poker? Besides, the text assumes that you always estimate using the modified Fibonacci numbers. And what about t-shirt sizes, to get a rough guestimate and avoid being paralyzed by numbers?
The PDCA cycle
The PDCA cycle is a concept known from Lean manufacturing, a creation of Deming (hence also called the Deming wheel). The entire world explains these 4 letters as:
- Plan
- Do
- Check
- Act
Deming is often referred to and quoted in the bespoke framework, so in this case it is extra strange to see that Deming’s concept of cyclic improvements, the PDCA cycle, got “mixed up” in the blender: the A of Adjust instead of Act.
DevOps in 5 letters
When asked how to explain DevOps in 5 letters, the entire world will use the acronym CALMS:
- Culture
- Automation
- Lean principles
- Measuring
- Sharing
At a certain point that particular scaling framework also added DevOps to their large drawing, but explained it with the following acronym: CALMR. Clearly inspired by the CALMS acronym, again, a letter got lost in the blender. The S became an R. But bottomline, both things kind of mean the same. It is just that “Recover” (what the R stands for) to me is a matter of properly applying Lean principles (stop the line — the Andon cord in the car industry) and automation.
Mixed up
I happen to know the concepts I mentioned above longer than I know the framework that copied and blended them. So I have a reference point. And that’s why I get more and more annoyed when I see yet another concept being “blended” into the framework, with some modifications and without reference to the original author. But imagine that the large drawing of the framework is the only thing you know about agile… You take the content for granted, because you don’t know of anything else. You didn’t take the red pill (yet?). But imagine you end up in a discussion about e.g. DevOps (been there, done that) and you talk about CALMS whereas someone else says: “No, it is CALMR”. Or worse: “We shouldn’t confuse our colleagues. We are implementing <a particular framework> so we should talk about the terminology of that framework” (in this case they meant CALMR). To me that is not ignorance, that is denying your heritage.
