In every industry, and at any point in time there are invariably a number of “buzz words” that seem to pervade conversations. Due to the rapidly changing nature of technology, and especially computer software, this is much more common in these fields than in others.
As someone who has been in the field for multiple decades, I can attest to the seriousness of the problems that occur when words are used for something other than their core meaning, or when the interpretation of them is at odds with that meaning.
While the list of such words is immense, I would like to focus on three specific terms that often appear in the same conversation: Agile, Scrum and Kanban. One will hear these words frequently, and it become clear almost immediately that the speakers are often talking about significantly different things.
To help allieviate this situation, I recommend going back to the definitive source:
With the relevant source material in hand, get four different colored highlighters and use them as follows to markup the document:
When the exercise is complete, the entire document should be highlighted in one of the four above colors.
Observe how much of the document is green, and now much is one of the other colors. While nobody (in my experience) has ever been 100% green, this exercise has shown some very interesting results when performed in group settings.
Of all of the insights this exercise can provide, the one relevant here is how much of the document is Green, or at least Yellow? Significant amounts of Grey indicate a distancing of the actual practices and the term being used to desbribe them. Even a small amount of red can be a crticial flag indicating a serious departure.
If your team(s) are part of the majority where there is a mismatch, then there are three possible actions moving forward.
The first is to continue using the term, knowing that it does not reflect the situation. I strongly advise against this path.
The second is to establish a plan to bring practices into alignment with the with the reference material. In nearly every case, there are some aspects where this is the desired direction; but there are invariably some areas where this will not be possible, practical or desired.
The third to to step back from these terms (at least for a moment) and adopt semantics that actually reflect the current situation. This is a course that I suggest all teams should at least consider.
In general, there are a number of more general terms that can be applied. Typically one of the following is appropriate:
Alas, these do not have nize “buzz words”, but most teams that have been using any of the original terms will find their objectives fit into one of the last two; but there are some conditions where the first approach is appriate, often those where there is regulatory considerations and/or health and safety issues are directly involved.
To throw one last term into the mix for this post, the term ScrumBan is increasing in popularity. There are good arguments that such an approach is neither Scrum nor Kanban. Quite often, an analysis will reveal that the situation is one of an Iterative Process at the strategic level, with a Continuous Flow as the tactical levels.
Hopefully this post will get you to think about the term(s) you are using, the meaning you are attempting to convey, and the applicability of such terms to your actual situation.
NOTE 1: Kanban is the most challenging to find a source that is tracable to the original, largely because the field of Software Development is so far removed from the original use-case [automotive manufacturing]. At the root, there are a number of apsects that must be addressed: The existance of a multi-stage pipeline; the imposition of work-in-progress [WIP] limits (or limits on the amount of material that is between stages), and the ability of resources and people to be re-assigned forwards and backwards in this pipeline to maximize flow and remove bottlenecks identified by hitting the WIP limits.