When I first attended Scrummaster training, I went in wide-eyed and excited to learn all of the secrets behind this amazing “new” agile project-management strategy called Scrum. I immediately donned the rose-colored glasses they handed out, and gobbled up the information that was presented. It all seemed so perfect… until I went back to my job.
I quickly realized that the idealistic parameters that were presented in class were not always present in real life. But my employer had just paid for me to go through the training, and I was expected to help improve their development processes. I thought maybe we could borrow some of the ideas from Scrum without using it exclusively, but Scrum tells you not to do that — and my peers would not let me forget it! So there I was, caught between a rock and a hard place, with no way out and no way forward…
***
Me: “Hi, I’m Mark, and I’m a Scrummaster.”
Support group: “Hi, Mark…”
It started out innocent enough. I wanted to be like my friends, and all of my friends were doing it. We’d stand around in a circle with it before work and then just go about our business. It didn’t seem to affect us much… until the ceremonies started. That’s when it got bad. We’d spend hours — work hours, even — doing nothing. My productivity suffered. Executives and business partners started to notice. It got so bad that the CEO outlawed Agile altogether. That’s when I knew I had a problem.
Thanks to a change of scenery and some great support from my colleagues at Modus, I’m on the road to recovery. I hope that by sharing my story, I can help others who face similar struggles. Remember — you’re not in this alone!
***
Now that I’m done being dramatic, let me say this: I’m not actually trying to get you all to quit Scrum. Scrum is popular for good reason, and it brings a lot of concrete ideas to the abstract concept of “agile” (echoes: agile… agile…). What I am asking you to do is to not be religious about any prescribed system. I tend to be a serious rule-follower, and over the years I have found myself and my teams held hostage by a framework that is supposed to be liberating. We were so rigorous about following the rules that we completely missed the spirit of agile software development.
As I said before, Scrum is one of the most successful attempts at putting some skin on the bones of agile development practices. We need to make sure, however, that we don’t lose sight of Agile principles as we go about implementing Scrum. If a certain pillar of Scrum doesn’t work for a particular team or even a particular project for the same team, guess what? You have the freedom to change it! As of this writing, no government has passed any law criminalizing the “Scrumbutt” system (i.e. we use Scrum, but…). So if you want to use Scrum as your guide, do it — but make it fit.
Let’s take a look at some of the major tenets of Scrum. We’ll unpack the why of each one so you can make good decisions when the what of Scrum seems to be holding you back.
What Scrum Says:
Divide work into Sprints.
What Scrum Means:
This is the one that I have the hardest time with. How often have you estimated and divvied up the work so accurately that everyone involved is wrapping up their last task at the end of the last day of the sprint? For teams that I’ve been a part of, the frequency hovers somewhere around 10%. Scrum does provide a solution for that: get the whole team together and re-negotiate the sprint. So our system, which is meant to streamline things, actually introduces more systems when the systems don’t work!
Consider the purpose of having sprints in the first place:
- To subdivide the work into bite-sized chunks, especially for larger projects.
- To provide a regular cadence so you don’t forget to do critical things like planning and retrospectives.
- To provide a framework for communicating delivery dates to business stakeholders.
The important thing is that you’re accounting for the goals above. If the strict division of work isn’t working for you, then change it! Maybe you keep the bi-weekly schedule of planning meetings, but allow individuals to pull in work as needed and don’t sweat it when the occasional ticket spills into the next sprint. You won’t get arrested or struck by lightning, but by tweaking the system slightly, you might just find that your team is more productive and, dare I say, even more motivated?
What Scrum Says:
Hold periodic Sprint Planning meetings, timeboxed up to 5% of sprint time.
What Scrum Means:
Whenever you try to commit to a precise amount of work in a set amount of time, it’s important to take some time to estimate, delegate, and strategize the work if you want to have any chance at getting it right. If your “set amount of time” is 2 weeks, then that means you need to hold this type of planning session once every 2 weeks. Plus, in my experience, 5% of sprint time is often not enough to understand the work, put time estimates on a bunch of it (yes, story points are just an abstraction of time — don’t @ me!), and figure out which of the estimated stories can fit in the sprint. Timeboxes are a nice idea, but what do you do if you can’t accomplish everything you need to accomplish inside of your box? It spills out one way or another, so I’ve found timeboxes to be more of a goal or suggestion than a strict boundary.
As I mentioned in the previous section, the real-world success rate of hitting sprint targets is low anyway, so any effort spent trying to plan for that low success rate is time that could be better spent elsewhere. If you and your team find yourselves bogged down with Sprint Planning, take a step back and consider the sprint purposes we discussed earlier. For example, one of my teams years ago would often get really “into the weeds” of every solution during Sprint Planning. The intention was to uncover any possible surprises, but the effect was that it took 5 people twice as long as it would’ve taken one person to get the same information. What I would recommend instead, now that I’m older and wiser, is to bring the business stakeholders closer and work on a more human understanding of the needs and risks, allowing for less stringent estimates and stronger trust.
What Scrum Says:
Hold periodic Sprint Review and Retrospective meetings, timeboxed up to 5% of sprint time (combined).
What Scrum Means:
Reviews and Retros were the biggest game-changers for me when I first learned Scrum. Having a set time where all stakeholders could get together, evaluate, and improve upon the latest iteration, as well as a more private time for the delivery team to do the same, led to lots of great improvements that would not have happened otherwise. Where these processes often fall short, especially on teams that are simply relying on the system to fix their people problems, is participation and follow-up.
Has this one ever happened to you?
“Ok, what did we do well this sprint?”
Crickets.
Yeah, me too. For an introvert like me, open-ended questions are just invitations to awkwardness. Plus, I think as our work culture becomes less and less formal, a conversational approach to discussions is often a better fit. When I lead a retrospective, I like to lead with something more light-hearted, casual, and emotion-based. “How are you guys feeling about the workflow? Did anything excite you this cycle? Did anything get in your way?” I also think it’s helpful when the facilitator has been closely involved with the team and can come prepared with some observations to use as conversation starters if needed. This might not fit cleanly into Scrum’s definition of a Scrummaster, but we’ll talk about my feelings on the Scrum roles in the next section.
One gap in the Scrum framework is retrospective follow-up. There seems to be a ceremony or prescription for everything else, but this is something my teams and I have had to figure out on our own. Don’t just make a list of grievances. Make a plan. Who is responsible for this change? How do we know if it happened? How do we know if it worked or not? I’d encourage you to go beyond the Scrum framework here and do what it takes to make sure that you and your team are getting better and better with each iteration.
Then there’s this gem from the Sprint Retrospective section in The Scrum Guide:
The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next sprint.
The pressure to stick strictly to Scrum is not just made up — Scrum tells you not to mess with it. Consider this article my Declaration of Independence. Don’t tread on me, Scrum.
What Scrum Says:
Participants have strict roles and responsibilities.
What Scrum Means:
Scrum’s idealism might be its greatest weakness. Scrum presents some great ideas for how people in the various roles should interact… in an ideal world. The problem is, our world is far from ideal. In The Scrum Guide, specific roles are defined, and specific authorities are given to each role. When one of these roles is not present, or when individuals don’t completely live up to the ideals of Scrum, things tend to fall apart.
I can already hear someone thinking, “Well, of course, it doesn’t work if you don’t do it right.” We don’t always have full control over our circumstances, however. Often a team that is trying to be agile has to work with a “product owner” who is more invested in the business team than the delivery team. Other teams try to do Scrum with an untrained or under-performing Scrummaster, or they might not be able to afford to hire an individual dedicated to Scrummastering, and they get discouraged because they’re attempting an idealistic system in a less-than-idealistic environment. Is Scrum really an all-or-nothing commitment? Are we only allowed to do Scrum if we have all of the resources to do it exactly by the book?
I think it’s important to give yourself and your team the freedom to figure out the best way for you to work together. Learn from Scrum. Use the tools, guidelines, and ideas it provides to make your team better, but don’t be dogmatic about it. The nature of “agile” software development is flexibility, so don’t get yourself locked into yet another restrictive system. Instead, treat it like a starting point, a pattern that worked for somebody else and will help you get where you’re going.
Conclusion
When you add up all of the ceremonies that Scrum suggests, you end up with more than 10% of everyone’s time devoted to upholding the framework. And that’s if you abide by the suggested time limits. Past teams of mine have often found the overhead to require even more time. I don’t think this is what the creators of Scrum intended, and it’s certainly not what you want for your company’s success. That’s why most of the teams I work with now take a much looser approach to Scrum (if they even use Scrum at all). Scrum is a tool, not the law, so let’s not get so bogged down with keeping the rules that our productivity suffers.
The nature of “agile” software development is flexibility, so don’t get yourself locked into yet another restrictive system.
If you’re having trouble getting Scrum, Kanban, or any other lean/agile framework to work for your team, give us a jingle. Modus Create boasts a wide range of agile development experts who can help you refine the process from concept to delivery. We’d love to join your team and provide the shot-in-the-arm that you need to go from struggling to succeeding.
What other aspects of Scrum have been challenging for your team? What solutions have you found to overcome those obstacles? Share them with us in the comments below!
