When I first started doing what I believed to be “Scrum” there were very few rules.
At it’s heart, in the beginning1, scrum was really just about working inside of a self organising cross functional team (of any size) where everything happened at once, instead of in sequential phases. Simple, but also radical. It also wasn’t limited to (or indeed for) software. As time went by thou, things got added to Scrum, although if I’m being totally honest I didn’t really notice that until much later.
The first and perhaps majority of these newly added things were summed up in Ken Schwaber’s seminal book “Agile Software Development with Scrum” (aka The Black Book) – and so that quickly became The Bible. The things that had been added since I first tried it, were, on reflection, largely to do with how you did Scrum than they were about changing what Scrum was. But then something interesting happened. “Agile Software Development with Scrum” began to define Scrum. The How started to become the What.
And almost overnight Scrum became a set of practices.2
Much like a phone stopped being a thing in its own right and became just another app on our Smartphones. The Self Organising Cross Functional Team stopped being the definition of Scrum, and simply became another one of the practices. And not only! All of a sudden those teams were restricted to covens of 7 +/- 2 members. The rules had arrived.3
In the early days of the the 21st Century, Scrum was rather uncontrolled & ungoverned. Whilst The Black Book certainly added new rules, roles and restrictions to what was previously a very open framework, it still focussed a lot on what Scrum was, and why we needed it.
Talk to a few older Agilists and you might find that it’s one of their favourite books, even if they now regard it as a bit dated. It covers many esoteric topics. There is a section entitled “The Kuhnian View on Scrum” which is closely followed by a treatise on “Knowledge Management”, and it was, for a great many people, their first taste of complexity and the works of Ralph Stacey. It was rich with well documented references. It was in some ways more of a proof of Scrum than it was anything else. A way to convince you that this seemingly crazy idea might just work.
The CSM appeared a few years later, around 2003 and at the time it was a prerequisite that you must have read The Black Book before attending. All 158 pages of it. And that was pretty much the only “control” placed on Scrum.
With the students having read the book, and attempted to practice Scrum, in those early days, the the CSM® was much less about the practices and more about the spirit of Scrum. The Philosophy. I have fond memories of Ken teaching a CSM in much the same way a philosophy professor might teach at a University, presenting conundrums to the class which on the Surface appeared to have nothing at all to do with Scrum, but in truth offered transformative learnings to all those ready to listen. Some readers might find a smile appearing on their lips at the mention of “Squirrel Burger”. It was not all roses of course, I remember fines for being late to both your Daily Scrum and being back to class, something that seems outright harsh and clumsy today, but generally it felt like we were focussing on the right things.
Since then, the CSM® has changed, and so has Scrum.
Looking at what passes for Scrum in some places these days, you do have to wonder what happened. I’m tired of reading blog posts about how awful Scrum is and then reading about a process that doesn’t sound remotely like any Scrum I’ve Ever practiced. And there is no point saying that, because you’ll just get the reply “That’s what Scrum is now, I’ve never seen anything different. It’s not a conversation worth having.
And this is happening in a world, where Scrum is now defined and controlled. We have the Scrum Guide! Ownership has been declared! We even have two Separate Certification bodies based off of it.
There is a missing set of years thou, a wilderness, a time after The Black Book but before The Scrum Guide, where existing practices were quietly altered and new practices were semi-officially or defacto added to Scrum. And all the while the community would declare “Scrum has not changed” — even thou Sprints went from “Strictly 30 days or it’s not Scrum”4 to almost universally two weeks long, and the meteoric rise in the number of “Agile Coaches”, started to deeply infringe on the territory of the ScrumMaster — a role so new that it was only barely beginning to find its feet.
But apparently Scrum had not changed.
A Tale of Two Scrums
It’s taken me a while to get this all straight in my head. My first point of call, was of course, like every other coach and trainer “You’re Doing it Wrong” — “Yeah, I know it says X, but it means Y not X”. Some people accepted it, some did not. It worked better back in the days when people got help from the get go. It works less well now when people struggle with Agile for months before getting assistance, long after everything has gotten its own local and binding definition.5
I then started to feel more compassion for my clients — especially since I noticed that so many of them were getting it “wrong” all in the same way. I then took a hard look at the wording of Scrum as it was then defined and realised that it was very ambiguous.6. I started talking about what I called “Misunderstandability“7 with friends and at Conferences — and after some encouragement eventually wrote about it.
As it turns out, people don’t like to think that they’ve misunderstood something anymore than they like to be told that they’re wrong, after all those are very similar things, on the surface it seems to indicate that the person themselves is at fault here.8 (Even thou my original intent was to ascribe blame to the object of the misunderstanding and not the person — which I think is still a useful concept)
Additionally, some people seemed to like this New Scrum.9. And with the Scrum Guide in hand they were now able to defend it.
Sure it wasn’t a Scrum that I recognised, but it was spreading. Fast. Depending on when you encountered “agile” in your career, it may well be the only Scrum you’ve ever seen. Even if you’re an “Agile Coach”.
So what shall we call this New Scrum?
The problem with the term “New Scrum” is that it sounds better. So that’s out. As is the term “Modern Scrum”. And “Scrum In Name Only or SINO”, sounds kind of narky. As does Scrum Coloured Paint. Additionally with these last two we’ve ventured into the territory of not doing Scrum at all, but calling what we’re doing Scrum, and that’s not at all what I mean. By New Scrum, I mean people who are certain they are doing Scrum, and can, to some degree prove it (with maybe an audit).
So perhaps the answer lays in letting this “New Scrum” steal the term from us and relable the old — but that didn’t work very well either.
“Real Scrum” is obviously inflammatory and implies, once again, that you are Doing It Wrong™. “Original Scrum” and “Scrum Classic” have exactly the same problem as “New Scrum”, but in reverse.10
It’s a veritable mine mind field. There is change, but no progress. How do we label it?
A Parting of the Ways
And then it hit me, if we didn’t have an evolution or a progression (which we most certainly didn’t) and we didn’t have a devolution either (jury’s still out on that one) — then perhaps what we had was a separation.
A separation of mechanics from meaning.11
A separation of Syntax from Semantics.
And maybe that was OK.
It was time to separate the Syntax from the Semantics of Scrum.
Syntax is the rules. It’s the processes. The ordering.
Syntax is not only easy to write down, it is what’s written down.
Syntax is the instructions.
Here is an example:
The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. The Daily Scrum is held at the same time and place each day to reduce complexity. The agenda of the Daily Scrum is as follows:
What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
You now know:
1. Who should attend the Daily Scrum (assuming that you know the Definition of “Development Team”)
2. How long the daily Scrum should be (15 minutes)
3. The fact that it should be held at the same time every day
The Syntax of Scrum is the easy part. Hell, you can learn it all in two days!
Once we start talking about Syntax thou, there are of course additionally details which people might want to know such as:12
- What should we do if the timebox is exceeded?
- What time of the day exactly should we hold the meeting?
- What is the definition of an impediment?
- Does every day also include weekends?
- What should we do if one or more teams members is not present? Late? On Holiday? Sick?
- What is the definition of a Sprint Goal?
- What if we don’t have a Sprint Goal? (Because we’ve not implemented that part of the Syntax yet)
- If the Daily Scrum is held at 0900 one day, but not until 1015 the following day, how do we know what to do in the hour and fifteen minutes of unplanned time!!! (given that the team only plans out the next 24 hours)
- Who ensures that people do what they say they will do?
- What kinds of punishments are appropriate for violations
- Is Gary an impediment?
Syntax tends to lead to a hunger for more syntax. It’s the nature of the beast. You don’t (have to) think, instead you (just have to) apply, which means when you encounter a case which is not covered by your existing rules13 you either wait for external input or go off piste.
Syntax also has another property that makes it very appealing to the average enterprise – it scales. Syntax is way of creating standards (in action if not output) — it’s no wonder that SAFe is popular in some circles as it’s a massive amount of Syntax, it provides a huge degree of comfort to a certain kind of person. “Well I don’t know whether or not Gary is an impediment, but I’m sure the SAFe Guidance will tell us” — you don’t have to read it, but you do have to know it’s there for this to work. It is also of course easy to measure and manage. I have literally seen consultants from a well known, but will remain nameless consultancy running around timing how long each team’s stand-up (Sorry Daily Scrum) took — and then creating a lovely Control Chart in PowerPoint.
Syntax is absolutely vital, but it also (obviously) has it limitations. Which is why we need Semantics
Semantic Scrum is different. It’s hard to explain exactly how in writing, because that’s the nature of it.
Semantics are the part that’s not Syntax, semantics are the meaning.
If Syntax flawlessly communicated the Semantics then we would have no need of the two words.
Semantics are built out of context, knowledge and experience. And that’s where the problem begins — we’ve all got different knowledge, contexts and experiences.
Not all semantics are hard to explain. Some contexts and experiences are sufficiently shared that it’s fairly easy to explain general if not precise meanings. If you had never, for example experienced “mustard” before, I could quickly convey its meaning to you by saying “It’s a condiment, like tomato ketchup” — and this analogy (because analogy and metaphor are both very useful tools for conveying semantics) would help you understand some very useful things such as:
- This is added to food, but is not food (unless you are four)
- It generally makes the food taste better
- It is savoury, not sweet
But the semantics of Scrum are actually hard to explain — and that’s the central issue. Scrum represents and has always represented a paradigm shift from the default way in which the majority of organisations operate14. This is where the conflict comes in, why “you’re doing it wrong” was the catch cry of the mid 2000’s and also why it was so poorly received. People just kept thinking “but this way makes more sense to me”.
Engaging only with the syntax of Scrum allows us all to avoid that discomfort. By focussing on the syntax and simply assuming you already know what the semantics are meant to be made Scrum seem easy, more palatable. It made it popular.15
But it also changed it.
When we defined Scrum purely by the syntax. The rituals, the artefacts, the roles. The shell became static, fixed. But the underlying meaning was allowed to alter, change and vanish. And suddenly it wasn’t there anymore. And there was also no useful way to talk about it. It was like watching an actor for a character change on a beloved TV show. You knew it wasn’t the same, you could feel it, but everybody was insisting it was the same person and that nothing at all had changed.
So the pitfall here, is, once again, to tell people they’re doing it wrong. It’s a trap that’s so easy to fall into. It’s sitting right there in front of us, begging us to say “Ah, but the real meaning is this”. Now we’re double dumb. Not only are we wrong, we were tricked! That sucks. Hulk Smash.
And whilst they’re the original semantics to me, they are probably are not to you.16
And nobody really cares what the author thinks after they leave the room.
Instead, I think it’s more useful for us to embrace the concept of alternate semantics. What is original for you is almost certainly not what is original for me, and even authors find later and alternate meanings in their own works.17
Alternate Semantics allow us to get rid of the tyranny of “is” and “should” — it allows all parties to accept that the meaning they have ascribed to the Scrum Practices may not be the same as those of the practitioners that came before them, will come after them, or in any way match the original author’s intent. But at the same time, this does not mean that they are right or wrong. At least in some absolute sense of the words. They are at best, logically coherent and justifiable.
I have noted on many occasions of late, that most of the organisations that are, for want of a better phrase “Doing Scrum Wrong” — would never, ever have attempted it, if they had grokked the original semantics. A particularly enlightened example can be found here.
The concept of Alternate Semantics needs a friend thou. Whilst I’m prepared to accept that multiple interpretations can have value, albeit different kinds of value. I’m not at all prepared to accept that all interpretations are useful. For this to work, we need some level of congruence. That our actions, driven by our interpretations, somehow link up to our goals, and if they don’t, then we have a mandate to explore whether or not it’s our interpretations that might need some revision. Moving away from the rather binary right and wrong, into the world of better.
Room for both
I like this separation. To me, it allows Scrum to be free. It allows both the Semantics of Scrum that I knew (and still believe to contain value) to co-exist peacefully with the Defined by the Syntax Scrum that in 2019, people love to hate.
I also think it adds something important to the conversation, that context is everything, that simply following the steps is not necessarily going to give you the same results as every other Scrum “Success Story” — it also might give you pause to stop and think critically about what people might actually mean when they say “We are doing Scrum” — sure, they might be following the rules, but what is the meaning behind those rules. What are their goals? Do they line up?
Whilst I’m a known vocal critic of “Waterfall with Stand Up’s” style Agile, that has more to do with me than anything else. It also comes from my assumption that the people who are doing it “wrong”, want to be doing it “right”. And that’s really not a reasonable assumption to make anymore.
All I ever really wanted is for the Original Semantics of Scrum to not disappear. Not fade away. To be remembered for what it was. To always remain as an option for those wanting it to try it. To have a handle onto which to hang the concept. And now I’ve found it.
So now you can practice your Scrum and I’ll practice mine and there is no need at all to have a war about it.
Syntax Diverges Syntax Improves
Whilst it’s never possible to create a perfect string of syntax that will universally and unambiguously conveys the semantics you intend it to.
It is of course possible to improve on your syntax, especially as the context you’re working in changes, matures and is understood better.
Not the least of which is what semantics have people ascribed to your syntax?
I’d like to think that that’s what’s happening with the Scrum Guide. Whilst it’s still far from perfect (primarily because it never can be) it’s lightyears ahead of where it was back in 2008 when I first laid eyes on it. The yearly update cycle, even thou it can get very bogged down in pedantic minutea sometimes, seems to be overall a good thing for it. Perhaps there is hope.
For myself, I’ve continued to evolve how I present my own message, as the audience for it, and the context they come from changes. In many ways this is a dance with the aforementioned misunderstood syntax — as it gathers semantic mould of it’s own, I’m required to refresh the message in ways that are unpolluted and pure. As least as well as I am able to make them.
Mainly, I’m trying to get people to think about the things they often take for granted. To start with the end in mind, to ask what am I trying to achieve, how am I trying to achieve it? What beliefs underly that approach? Is this in line with my organisation’s goals and beliefs?
How about the other people I work with? Are we sufficiently in alignment? (If the immediate answer that comes to mind is “yes”, then I’d recommend counting to 30 and asking again)
Whilst this sounds like it might be hard work, at least compared to following a set of rules and accepting whatever semantics your context and experience automatically ascribe to them. It’s ultimately a far more meaningful, far more effective and dare I say it friendly and relaxing way to approach the world.
Viva la difference.
- A decade or more before the Agile Manifesto. ↩
- If you for example read “The New New Product Development Game” you will find little to nothing on the how of Scrum. But rather a treatise on the underlying philosophy along with a few real world project examples (none of them software and all devoid of implementation details). It is so devoid of “how to do Scrum” that if you took the word Scrum out of it (which doesn’t actually feature prominently) many readers would fail to associate what is being described as Scrum at all. ↩
- Yes, this particular rule changed a few years back to 3-9. Just in case you didn’t think I was paying attention. ↩
- Which is why I’m amused that the the Scrum Alliance, at least for a period declared that no Sprint may be longer than 28 days, which is of course 2 days short of the “original” 30. Syntax is tricky. ↩
- Not to mention it’s now possible to hire a an “Agile Coach” or “Trainer” who will provide you with any definition of Agile or Scrum that you want! ↩
- Sure it was less ambiguous if you followed all the rules, which was close to impossible if you misinterpreted them, but by that stage people had adopted a “linear scrum” approach whereby you could just follow the rules or practices, one by by one in isolation. That approach is ripe for problems. Which is probably why there is such a large Agile Industry out there right now. ↩
- Misunderstanabilability is the natural pre-disposition that an idea has towards being misunderstood. It is not the same as ambiguity, where you are uncertain of a meaning, but rather where something clearly appears to mean something, when it, in fact does not. (And often the opposite) ↩
- Or worse, the boss has misunderstood and no correspondence will be entered into with you, the designated implementer. ↩
- Don’t get me wrong thou lots more people hated it. Mostly those to whom were made to comply without any say in the matter. ↩
- My favourite terms of all was “Honest to God 20th Century Schwaberian Scrum” — which represented the Scrum as described in “The Black Book”. I used it for a number of years, and it took off mildly with a small audience for a short period of time. ↩
- I first covered this topic in my Agile 2011 Workshop “Scrum as a Thinking Toolkit” where (amongst other things) the participants learned to interpret the Scrum Practices from the point of view of various stakeholder persona’s. We even threw Cynefin into the mix. It was a fun day. ↩
- I’ve had all these questions asked of me. I’m sure there are more. ↩
- Either because the author didn’t think of it, or because putting in every single case would be tedious and unwieldy. ↩
- That HBR article is called “The New New Product Development Game” not the “Same Old Project Management Game” ↩
- Which to be fair is how most adults get through the day. Encountering fundamental context or paradigm shifts is the exception, not the rule. ↩
- If you ever bother to lose a week researching all the early writings on Scrum as I did a year or so back, you will quickly discover that around the turn of the century there were already semantic and syntactic disagreements between Schwaber and Sutherland. I can only imagine that the Scrum Guide when it came out (endorsed by the both of them and declaring themselves as the “co-creators of Scrum”) was some kind of peace treaty, designed to create a single merged syntax at the bare minimum. Whether or not their personal semantic views have now aligned I could not however say. I guess my point here is that, if Ken and Jeff could not entirely agree on the meaning of the Scrum practices, back when they were creating them, we should not feel too bad about our own personal interpretations clashing with others. Even Ken and/or Jeff. Lastly, each practice may have many potential meanings and benefits, and what we’re often seeing is not disagreement, but rather emphasis and awareness. ↩
- If you don’t believe me that this is true for Scrum, you need only look to the early writings, where the ScrumMaster was described explicitly as a manager, and had authority over the team. Ten Years later and this manager has become a servant leader, who has no direct authority over anybody. The weirdest part about Scrum is that nobody talks about these quite extreme changes in official position. ↩