Sometimes I use the phrase, “novice Scrum team,” to describe a team that’s new to Scrum, still settling into the routine of sprints, and still getting a handle on the underlying values of Scrum. Often, these teams are in the process of adopting unfamiliar technical practices like test-driven development and unfamiliar processes like continuous integration, and learning to collaborate across roles that had been sequestered in functional silos before the cross-functional Scrum team was established. They’re learning a lot of new things at the same time.
Quite a few people appear puzzled or bemused by the phrase. It occurs to me they may think of Scrum as a fixed set of rules to follow, rather than as a starting point for ongoing improvement. You either follow the rules or you don’t. There’s no concept of “novice Scrum team” because there’s no concept of ongoing improvement: When you follow the rules of Scrum, you’re doing Scrum. You either do Scrum or you don’t. That’s all there is.
Dark Scrum and the Eighth Circle of Hell
I’m reminded of an engagement at a well-known company that will go unnamed in this post. Their IT department had “gone agile” a few years before. I was engaged as an agile coach at the team level. It was a team of software developers responsible for a particular internal-use product. They were doing greenfield development. The conditions were ideal for a well-functioning Scrum team to deliver value incrementally.
The ScrumMaster for this team told me that prior to this job he had worked at such-and-such a company where he had “done Scrum perfectly for six years.” After joining the present company, he had continued to “do Scrum perfectly” for the next two years.
The team had been working together for two years under the guidance of this expert ScrumMaster. They had never delivered anything whatsoever. The code was in such bad shape that no developer could run a full build of the entire product, neither on his/her workstation nor in the test environment. (There was no production environment.) Developers focused on modifying just the code units they had to touch to complete a User Story (don’t look too closely at what “complete” meant; it will make you sad) and didn’t worry about the rest of the code. There were so many red indicators in the IDE window that the directory tree looked like a nighttime photo of a traffic jam. There were hundreds of known bugs. They had three different test automation tools installed, but no meaningful or reliable automated tests. Developers kept code checked out across multiple sprints without committing. Their technical lead was thoroughly unqualified for the role. He was a master politician whose primary job-related skill was tying a Full Windsor knot, a thing he did less perfectly than he did Scrum.
The whole place was a hell of dark Scrum, and this team was the Eighth Circle. I’m at a loss to choose which bolgia into which to toss these sinners, but the choice of Circle is right: The Circle of fraud.
The team followed all the superficial decorations of Scrum with none of the substance. The ScrumMaster and technical lead were proud of it, and not shy about saying so. Frequently. Loudly. Defiantly.
The team could check all the boxes. Daily Scrum, check. Sprint Planning, check. Sprint Review, check. Retrospective, check. They had stuff pinned to the walls. They had a Blame Wheel they could spin when someone made a mistake, to determine their penalty: to buy snacks or sing a song or clean the team area or whatever. Every day, they stood in a circle, put their hands in the middle, and shouted a cheer while raising their arms high. They always maintained fake smiles, and they never complained or raised any concerns. They remembered what happened to the last person who raised a concern; how suddenly they had disappeared, their name scraped from the stelae as if they had never existed.
This is what can happen if you approach Scrum as a set of rules to follow. It’s undoubtedly an extreme case, but perhaps that makes it all the more useful as a negative example.
Scrum as a start, not an end
Scrum can be very effective when an organization is operating in a kind of chaotic churn, where no one is quite sure what to do, how to do it, how long it might take to do it, or who’s doing it; where people are organized into functional silos, and no one has visibility into the purpose or context of their work; they’re just knocking out an endless series of one-off requests for small tasks. Open a port on that router. Test this application. Add an index to this database table. Add one more conditional block to this routine. Lift that bale. Tote that barge. Why? No one knows. Autonomy, mastery, and purpose? Not likely. High customer satisfaction? Well…how could we even tell?
Scrum helps in that situation by breaking down the functional silos – at least, as far as that’s possible initially – organizing teams around products or value streams, and connecting business stakeholders with delivery teams so that people can figure out what to do, how to do it, how long it might take, and who’s doing it. Scrum establishes a clear cadence for incremental delivery, so that teams have a basis for learning how to slice the work and get things finished. Teams have visibility into the purpose and context of their work; they’re not just knocking out a series of one-off requests. Autonomy, mastery, and purpose become (at least) conceivable. Customers can begin to believe the company is (at least) interested in their satisfaction. And…we have a way to tell.
But to be useful in that way, we have to apply Scrum mindfully, with clear understanding of the purpose and value of the various Scrum events. We can’t just say we’re “doing Scrum perfectly” because we can check all the boxes for the things listed in the Scrum Guide, with a nod and a wink regarding the real meaning of those things.
Your mileage may vary, but I see all of the Scrum events as overhead. In Lean terms, they’re non-value-add activities. That perspective guides me toward looking for ways to minimize or eliminate some of those events. The only useful way to do that is to learn to operate as a team in such a way that we can deliver effectively without depending on the events. That doesn’t mean we can just stop the events. We have to earn the ability to discontinue or reduce an event by demonstrating that we can deliver without it. In turn, the only practical way to achieve that is to practice continuous improvement to the best of our ability, remaining constantly alert to anything that can help us deliver more effectively.
That’s the basis of a previous post of mine in which I liken Scrum to Forrest Gump’s braces. At first, he needed the braces just to stand and walk. When he was ready to run, he had to shed them or they would hold him back.
If we see Scrum as just a set of rules to follow, we’ll never think about how to “improve.” We’ll just keep following the rules by rote, and claim we’re “doing Scrum perfectly.” The idea of a “novice Scrum team” won’t make sense, because we’ll assume one can either do Scrum or not do it, and that’s all there is.