I have seen many so-called Scrum Teams that never received any formal training. However, they heard about Scrum, read a few articles, and started to use some of its aspects. Maybe they even read The Scrum Guide. So, what is the usual result? Nothing very effective, including:
Parts and Pieces get cobbled together
Many untrained Scrum Teams look like a patchwork quilt, or maybe Frankenstein – it ain’t pretty. By picking and choosing only some aspects of Scrum and perhaps other agile frameworks, the result is messy and usually ineffective. Some people might call this “hybrid,” but I call it disastrous.
No one understands the terms
There are a lot of new and jargon-y terms that come with Scrum. Technical and impressive buzzwords (like velocity, burndown chart, and minimal viable product) may spill out of someone’s mouth. Still, if they don’t know what they mean, there is a high chance of miscommunication and misunderstanding.
Lack of Transparency
One of the three pillars of empiricism in Scrum is Transparency. Teams untrained in Scrum probably didn’t get the memo on this. Often, such groups will operate under the radar, and no one in the organization knows what they’re doing or delivering (if anything). And they typically don’t hold Sprint Reviews because they either: 1) don’t know about them or 2) don’t find them valuable (meaning they’re not showing their work or getting any feedback).
Blind leading the Blind
I have often seen half-baked Scrum Teams with one or two people who have agile experience in school or at previous organizations. Usually, these “experts” guide the team on their practices, and in most cases, it’s like the blind leading the blind – they don’t know how to teach or train and end up implementing what has been termed “fragile.” They bring their own experiences, which may or may not be good.
No Accountability
If there’s no transparency, how can there be any accountability? There can’t be. If the team isn’t planning and working toward a unifying Sprint Goal, there is little chance of hitting their target because there isn’t one! And the work of a Scrum Team should be visible and inspectable at any moment in time throughout each Sprint. At the end, an increment that is working and potentially releasable should be delivered.
Never-ending “Sprints”
Immature and untrained Scrum Teams don’t always understand the concept of time-boxing. They might call the period they’re working in a Sprint, but it usually isn’t – it’s more like an unending length of time that never concludes because there’s no date on the calendar that they’re supposed to end. The work continuously moves, and the Sprints get ignored as container events.
Irregular Sprint Lengths
As bad as the never-ending Sprint are varying Sprint lengths. Scrum Teams without training often pick a random choice for each Sprint. It might be two weeks, then three, then four, then back to two, etc. Having irregular Sprint lengths is a bad practice, leading to inconsistency in the ability to plan and deliver and the inability to meet customers’ expectations.
Lack of Consistency
Customers and Stakeholders prefer to know what’s coming and when. Basic forecasting can help a trained Scrum Team to determine and communicate this information. But when there is no training, no one knows how to forecast, and there’s little to no consistency. A result of never-ending or irregular Sprints leads to a total lack of consistency.
Event Confusion
There are only a few official events in Scrum, but somehow, I’ve seen many untrained people who confuse them. The two activities most often confused are the Sprint Review and Sprint Retrospective – people don’t know what each event is for and who should be there. With proper training, there’s no confusion, and the purpose and outcomes of each event are clear.
Never getting to “Done”
Remember that missing target? It’s called not having a definition of “Done.” Without one, most teams wander aimlessly and never know when they’re done. This is one of the commitments Scrum Teams are supposed to make, and teams without training aren’t even aware that they should have a list of criteria that mean an item is officially complete.
Lots of Wasted Time
Scrum Teams without training spend a lot of time going around in circles, resulting in wasted effort. And as we all know, time is money, so it’s also a financial loss when teams waste their time. Another thing that happens often is the creation of technical debt (usually unknowingly) that later requires extensive refactoring, which is also wasteful.
Over-reliance on Tools
Immature Scrum Teams often rely too much on their management tools, such as Jira, Azure DevOps, or similar software. Rather than molding the applications to their process, they let the program dictate how they work. They also use tools like these to avoid conversations, preferring to communicate digitally. There’s no substitute for talking to people when you have a question or need to work something out.
Final Thoughts
“Scrum is simple to understand but difficult to master.” When Scrum Teams come together with little or no training, failure is almost inevitable. The result of this hodgepodge approach to implementing Scrum is that there’s tons of confusion and few valuable outcomes.
What do you think? Have you seen any untrained teams succeed with Scrum? What did they do to avoid failure? Let me know in the comments box below!