When Scrum Becomes Too Abstract To Function
Real knowledge is to know the extent of one’s ignorance — Confucius
TLDR: We need to do away with the idea that we are all already experts in Scrum, which does nothing to help us achieve our essential goal: to create and deliver working software in a happy workplace.
We Are Losing Sight Of Scrum! Why? How?
A framework, or idea, carries meaning not only based on its application in the tangible world but also through a shared understanding of what the idea signifies. That is, we cannot hope to understand each other if when I say “scrum” you think “buffalo”.
Without a shared understanding of what ideas mean they begin to lose shape. They become messy and hard to grasp and this could be due to all sorts of perfectly naturally occurring phenomena: cultural differences, language barriers, or unchecked implicit associations.
So while I believe that we should embrace a culture which encourages positive, open dialogue about differences of opinion in order to best learn from these differences, we would also do well to at times remember a certain anecdote: a jack of all trades is a master of none. It
We cannot all be experts in everything. In fact, many of us will only become experts at one or a few key skills; and this is already enough for us to make valuable contributions in any area where such skills apply.
So why then is it so hard sometimes to say “I don’t know enough about this to have an informed opinion — I’m not sure what I can contribute here”. I know I sometimes struggle to admit this (although I may privately be thinking it!)
In the case of Scrum, and perhaps for many things in a startup world, I would argue that we have formed a few key assumptions to our own detriment, and they are thus:
- It’s socially undesirable to identify as having no or little knowledge about popular ideas in the workplace, which in turn causes the language and terms we use to describe these ideas to lack substance
- People should be able to learn about new things quickly, no matter how complex the topic is, and this is especially true when it comes to being knowledgeable about Scrum
These assumptions can harm our shared understandings of an idea. They create “experts” out of novices, encourage process inflation, and ultimately push us away from being open to learning new things and flourishing in the workplace— something all of us (I assume?) would advocate for.
So let’s dive in, poke a bit of fun at ourselves, and explore some of the quirks of language, startup culture, and Scrum!
How Language Shapes Our Work Environment
A lot of the language that is used to talk about Scrum is ill defined, confusing, and void of meaning.
Thus every Tom, Dick, and Harry is now a Servant Leader, or a Rockstar Programmer; and each of them can deliver Maximum Value whilst Unifying Processes; because they are all Scrum Ninjas trained in the secret art of Gratifying Gobbledygook.
I admit that the last phrase in the above list doesn’t appear as often as the first do in this modern, buzzword-saturated, and cushy developer ecosystem — but that doesn’t make it any less true.
Although the Merriam-Webster dictionary offers a perfectly suitable definition of the term (“wordy and generally unintelligible jargon”), the Oxford Living dictionary’s definition is a tad more appropriate for our setting: “language that is meaningless or made unintelligible by excessive use of technical terms”.
Considering how loudly and excessively our Tom, Dick, and Harry's often proclaim their incredible abstract awesomeness it’s even more appropriate that the Oxford Living dictionary also states the origin as: “1940s (originally US): probably imitating a turkey’s gobble”.
Absurdly apt etymologies aside; the Scrum implementation of Agile is disappearing so far up its own popularity it’s becoming difficult to find people who don’t consider themselves the Doctor Who of your average retrospective.
That is to say: the predominant attitude from certain Scrum practitioners is essentially that they have nothing more to learn about the topic; because they have an uncanny ability to bandy around catch phrases like “Agile is a framework, not a methodology” which they think suddenly brings authenticity to any and all of their claims.
The language we use to describe our team, our work, our processes, and ourselves is a reflection of the broader culture and foundations on which many startup businesses are built and we need to be careful that the dialogue we’re engaged in helps instead of hinders our ability to learn new things.
In the case of Scrum we could all benefit by using a more inclusive, encouraging, and friendly vocabulary that doesn’t demand total dominion over the subject. To paraphrase a brilliant and gifted philosophy lecturer I had the good fortune to learn from, we would all do well to “wear our intelligence lightly”.
The Assumption Of Simplicity
Guess what you little Scrum Ninjas? The Scrum philosophy and the Agile manifesto are complex.
This is not to say that they are complicated. In fact part of the reason Agile even formed in the first place was in reaction to the bloated, process-heavy (and at times authoritarian) agendas encountered in prior development systems like waterfall and the Project Manager’s Body of Knowledge (or PMBOK).
But a system designed to protect and uphold a set of values and principles which at their core are meant to be easy to understand doesn’t make those values and principles easy to implement.
It’s really, really hard to get a sound grasp of the many processes that are often encountered inside of a Scrum team let alone understand the relationship between these processes and the ideas, values, and principles they aim to protect.
But the fact remains that many people still feel or think as if they should be, or are, entirely qualified and experienced Scrum practitioners even if they might not have had much experience with Scrum at all.
This claim isn’t exactly news. This nearly six and a half year old question on the Software Engineering Stack Exchange website lays bare a problem many Human Resource departments are still facing this day: how do we identify the pretenders?
When people would rather pretend (or truly believe) that they are authentic knowledge bearers of some topic, the task of finding and hiring people that really do know about that topic becomes increasingly difficult. The pressure to be a Scrum savant in combination with the assumption that Scrum, like many things, is something easy to learn and implement thus has far reaching consequences.
The startup ecosystem would thus benefit from a relaxation of Scrum hiring requirements. This would afford potential hires the freedom to be new to scrum and would encourage more people to learn on the job. It could help us to reassess our own merits and subsequently identify people who have a wealth of experience we could draw from (ideally because now there would be less scrum pretenders in the room).
Here it is especially important that we lead by example: when people admit their own shortcomings and openly discuss areas they wish to improve, this gives permission to those around them to do the same. This is what we mean by establishing a fail-friendly culture.
Processes, Processes, Processes
Somewhat ironically, Scrum can be one of the driving forces behind the proliferation of processes that can kill a team’s productivity. The irony stems from forgetting the first and perhaps most cited principle of The Agile Manifesto:
When processes become rigid they hinder productivity by failing to adapt to the changing requirements of the product in question, or by not evolving to meet the all-too-human and ever-changing needs of the different people that make up a team.
A tragic example: somewhere along the line someone adapted the Kolb Learning Cycle (a psychological model for learning based on experience) and crudely moulded it into a badly themed retrospective action system often referred to as the Active Learning Cycle (an action/principle application model meant to implement retrospective learnings).
Now it’s no coincidence that both of these systems are deemed “learning cycles”. David Kolb was the first to record and systematize this model of learning (although he took inspiration from earlier psychological studies) and anything named or modelled after it — whether the designer realizes it or not — is (in)directly adhering to the learning model Kolb suggested and argued was the most accurate.
While there are variations to the above theme, and I’m sure whoever thought of this meant no harm, there are some fundamental differences between a psychological model of experiential learning and a Scrum team full of developers, product managers, quality assurance people, and the like trying to respond to retrospective action points:
- the Active Learning Cycle is primarily a perception-based, “feeling and doing” action system (i.e. does this make the team feel happy or sad?) which entirely focuses on team perceptions and thus relies on just a single mode of learning, which according to Kolb is the “concrete experience” type of learner
- the Kolb Learning Cycle further specifies distinct methods for moving between these modes (accommodating, diverging, assimilating, converging) while the Active Learning Cycle doesn’t explicitly define any methods or reasoning for moving between the different stages therein, aside from asking “do we feel like this is working?”
- the Kolb Learning Cycle specifies no upper limit to (nor does it try and quantify) the amount of “actions” or “points” any single person can simultaneously learn which is something vital to highly adaptive teams that need to feel motivated in order to accept and promote healthy change
What this means is that teams often end up with seven, eight, or even upwards of ten different retrospective points sitting in the “happy” or “unhappy” columns with no real motivator to actively engage with these topics in order to keep the listed ideas fresh and relevant to any current challenges faced by the team.
The worst part is that, despite this process often failing the team, people sometimes cling to the Active Learning Cycle as if it will somehow and eventually all fall into place. Thus we keep adding more retrospective items to the list and wondering how and why people aren’t adhering to these points or why they end up ignoring them completely.
This is when Scrum becomes too abstract to function. This is how we end up sitting at our desks feeling overwhelmed by the sudden influx of Scrum Ninjas in the workplace throwing infuriatingly predictable slogans around as if they will somehow magic up a productive team.
The Way Forward: Keeping It Real
When terms like Servant Leader and System Crusher become more important than delivering stuff that works the whole industry suffers. Combine this with an immense amount of pressure on people to keep up with all the trends and learn things quickly this can in turn lead to a belief that systems, or tools, or ideas, must themselves be simple and easy to apprehend.
The cycle continues and we end up chasing our tails: we invent new and even catchier terms because everyone has caught on to the last one and now Servant Leader has lost it’s meaning — a term too abstract to function between the opines of Tom, Dick, and Harry.
But all is not lost!
We can, I believe, get back to the core tenants of the Agile Manifesto and the first thing we need is to do away with this industry-dominant attitude that everyone needs to be a Scrum Pro.
We also need to think about the sort of language we use inside this incredible, challenging, and wonderful startup culture. We need to allow ourselves time to grow and to be a Scrum Newb sometimes, as we do with all things.
We all start off somewhere — and it’s probably not Overlord.
As a philosophy graduate with a passion for ethics and constructivism, I love what Scrum sets out to achieve because the Agile Manifesto makes an honest attempt at promoting happy, productive teams with a sound philosophical and scientific basis. But that doesn’t make me a Scrum Pro.
Much like Peter Norvig; I’m an advocate of the attitude that with deliberate practise and regular challenges I can probably become a really, really good programmer in somewhere close to ten years:
Why don’t we have this same respect for Scrum?
Why does it take less than a week to get a Scrum Certification and become a Scrum Master when the most influential composers, poets, developers, and significant practitioners of any epoch tend to have been working in their field for over 30 years?
Get comfortable with the idea that nearly all of us are actually Scrum Rookies. It was, after all, a system pioneered by Ken Schwaber and Jeff Sutherland only after the 2001 Utah Summit where it all began some 16 years ago.
That means at best you’ve been practising Scrum for 16 years (and probably much closer to 2 or 3).
Finally, and perhaps most importantly, we all need to stop clinging onto processes or principles unless they clearly and demonstrably promote happiness and a productive workplace. Let’s stop busying ourselves with sounding like we know all there is to know about Scrum and start being honest about what works and what doesn’t.
To borrow an idea from that rather interesting Googley/Intel alignment model (Objective Key Results): when you define a principle, idea, or action you want to try out with your team you should at the same time define a metric for its success.
Sometimes this metric can be as simple as asking the team whether an idea feels like it’s working or not — but this is merely one of a myriad of means — it is certainly not the only way to gauge if something is working. If you or your team want an easy way to check if something is too abstract ask yourself this question: how can I prove this is working?
If there is no way I can measure a thing’s application (i.e. if we cannot quantify it) then chances are it’s just another abstract concept loaded with feelings and intent likely to be lost inside an ecosystem that too often cannot see the forest for the trees.
We are all guilty of occasionally losing track of what’s important. And we’re all guilty of using language which, at times, polarises instead of unites us in our common cause.
Let’s refocus, recalibrate, and revitalise… uh oh…
Did we just coin another catch phrase?
