Scrum: a Flashlight, a Spotlight, and a Nightlight
Scrum is claimed to do many things. Create awesome software in no time, immediately turn average teams into unstoppable juggernauts, cure cancer, etc.
In reality, Scrum doesn’t do anything. It’s simply a framework to help teams handle complex projects prone to change. I think of Scrum as simply shining a few different types of light on projects and development teams.
Scrum is a Flashlight
The first retro I ever ran didn’t go so well. As a young, wide-eyed developer-playing-ScrumMaster 3 months out of college, I burst into the room 30 minutes early to set up my grand vision of whiteboard columns, flipcharts, and sticky notes. In my head I pictured a perfect retro, where the team would ask themselves hard questions, question everything about their process, and have profound epiphanies about how to become the perfect team. Of course reality didn’t match expectation, and upon asking “What went well?”, I faced a sea of blank expressions. Worse, the “imagine the team in one year” exercise bombed so hard a treaty was signed in Geneva over it. Although I had prepared the floor for rigorous self-reflection, the team was only one sprint in, and we hadn’t developed the data or skills needed to fully self-reflect. The team had been given flashlights to shine light on our good & bad practices, but we were still trying to turn the darn things on.
Shinning a Flashlight on Issues
One of the most common complaints about Scrum adaptations early-on is that the team seems to have more problems than they did before. “I thought this Scrum thing was supposed to solve our problems, not make more of them!” the team members exclaim at their third retrospective. In reality these problems have always been there, they’ve just been unexposed up until now. Scrum demands a lot. The team has to deliver production-ready functionality fast. Therefore problems that the team could ignore for months at a time previously now have a profound effect on their sprint goals. What was a niddly inconvenience previously now needs to be addressed & remediated quickly.
Luckily Scrum provides tools for rooting out underlying impediments and inefficiencies. The sprint retrospective is the most obvious tool. Great Scrum team members will reflect throughout the week on which larger impediments are generally affecting them, and raise them to the Scrum Master as soon as they’re discovered. Although that’s the ideal state, in reality team members have sprint commitments, families, and football games to watch, so continuous reflection on larger impediments often doesn’t happen automatically. Therefore a timeboxed event to discuss and discover larger impediments is necessary. The Scrum master should both bring up impediments at retro, and coach the team to discover their own larger impediments.
The daily stand-up/scrum is the first line of defense. In a good stand-up each team member will describe either what they got done, or any blockers that kept them from getting things done yesterday. Blockers that would have gone days without being brought-up are now raised to the team within 24 hours, and the team’s collective knowledge usually means a much speedier resolution. Of course a high-performing team will raise blockers as soon as they arise. One could think of stand-up as a training tool for teams, transitioning them from hiding their blockers to continuous collaboration over what’s slowing the team down.
Shinning a Flashlight on Progress
Scrum makes B.S.’ing project progress reports hard, and that’s a good thing. With Waterfall, discovering the team’s progress is often a complete guess, based on months-long benchmarks and assumed velocity. With Scrum, regular progress updates that stakeholders can touch and feel shines a light on how the team’s moving through the project.
I won’t claim that Scrum means perfect estimation and dead-on project schedules. Teams will mis-estimate sprint tasks, and sprint planning should be considered a projection, not a promise. Although the team should do everything within their power to deliver something that’s production-ready, it may not have all desired bells and whistles. Plans should change to reflect reality, since the converse is usually impossible or costly long-term.
With that caviat, an emperically found velocity combined with a well-groomed backlog does provide more planning accuracy than Waterfall. And by defining done for sprint goals as production-grade functionality, a team can progress through the project plan at an even pace, instead of pulling a Microsoft loading bar and hanging at “almost done!” for weeks at a time.
Scrum is a Spotlight
A few years ago I interned at a large company that was celebrating a major anniversary. A large convention center was reserved, acrobats were brought in, and a band was hired to write a brand-new song for this event. Unfortunately 90% of the celebration was one executive congratulating another, and although their leadership was key to the company’s success, only one mention was made of the ~2,000 employees that handled the heavy lifting and turned leadership’s plans into reality.
In some corporations it’s common for individual contributors to feel underappreciated. Managers are lauded for project successes, while team members are blamed for project failures.
Worse is when managers handle all planning activities, while the team has no place at the table. All the Advanced COCOMO and “Procedural Estimation Techniques” in the world fall apart when the project plan is shown to the developers, who exclaim “There’s no way we can build that in x time, you dingbats!”.
Scrum places the development team front and center. Though the Product Owner handles the backlog items & prioritization, the team (and only the team) sets the sprint goal, and pulls in the functionality they think they can deliver. The result may not be what management wants to hear, but it’s usually an accurate forecast of the team’s capabilities. ‘Tis better to rip the band-aid off early, than to provide a brutal shock to stakeholders weeks (or months) down the road.
Scrum is a Nightlight
Software development, due to its unpredictable nature and price tags that encourage tight schedules, is a field often defined by failure. A project running over budget & over schedule is not so much a rarity, as a common reality. To respond, we have two options:
- Lower expectations, by significantly overestimating budget & scope on every project
- Reduce the cost of failure, by making failure less costly & less dramatic (on a money, time, & personal level)
#1 seems nice at first. If we set bars low enough, we’ll almost always clear them, and everybody gets to throw celebratory pizza parties at the end of every successful project. But the only things that grow are egos, and the pizza place’s revenue. With each padded project Parkinson’s law kicks in, and our execution grows sloppy. With nothing to challenge the team, there’s no good reason to cut waste, develop skills, or sharpen capabilities. We get stuck in a holding pattern of apathy and mediocrity.
In many organizations, failure can feel like (or mean) career death. No one wants to be thrown under the bus and chewed-out by upper management. Stuck between this and the safety blanket of option #1, we rationally choose the blanket, sacrificing growth.
Enter option #2. By making failures smaller, less costly, and building a culture of respect & curiosity instead of blame, option #1 starts looking less like the obvious rational path. Once teams start buying into the objectives of their project, and discover the joys of freely challenging themselves without a pit of spikes awaiting any missteps, the need to pad estimates slowly diminishes.
Scrum is tailor-made to enable option #2. With sprints, failure discussions where the stakes were once years worth of investment now only involve a few weeks worth of work. Reviews & retrospectives provide a forum for discussing these failures in a straightforward, blameless, productive manner that leads to learning, growth, & pivots instead of terminations & tears (when done right). The short iteration cycles of scrum reduce the cost of each failure, providing the safety of option #1 while still enabling growth & adaptation. Scrum’s the nightlight that helps ward off our greatest corporate fears.
