Dispatches from the Seventh Circle of Scrum: Episode Ⅰ
Few ideologies or concepts have been as transformative in the realm of project delivery over the past couple of decades as Scrum. Now celebrating 25 years in existence and deeply embedded at tech startups and tech giants alike, Scrum has practically become a household name ( – though not quite, as evidenced by recurring questions from my wife: “What exactly are you a master of?” and “What’s a… scrum?”). Yet the facts on the ground show actual Scrum implementation in the workplace is universally riddled with misunderstandings and poor execution. Even the defining document of Scrum, The Scrum Guide, attributed the simple framework as “difficult to master”¹ (that is, up until the recent revision in November 2020). In my experience, the disparity between the principles and the practice of Scrum often leads to work environments where management is either frustrated by inefficiencies or else blissfully oblivious, and developers feel oppressed by too much time spent planning, estimating, and reporting, and too little time spent developing. So if you aspire to see the sort of efficiencies and productivity that Scrum espouses, yet like so many others, you experience only clogged calendars and unreliable estimates – make some adjustments! Working within Scrum doesn’t need to be a hellish struggle. Now is the perfect time to get a fresh start with Scrum in 2021.
To that end, here are a few pro tips to breathe new life into your Agile practice, and just maybe start reaping the rewards of a cross-functional, self-managed, and adaptive delivery team.
✘ DON’T: Compromise with Scrum “LITE.”
It might be pitched as a new, more evolved approach: Customizing Agile to the needs of your business! Introducing Scrum LITE, an adaptive strategy to make your team leaner with the “best parts” of Scrum! Now with more fiber! Don’t buy the hype. The cake is a lie.² Scrum is inherently uncompromising in its implementation. It is designed to be practiced in its entirety without exception. Anything less is not Scrum. Of course, bits and pieces of Scrum can be incorporated into a team’s delivery management practices, and the team may even find these elements beneficial. This approach is also generally accompanied by the distasteful “ScrumBut”³ – which is what you get when an organization says “Scrum is great! BUT… we make modifications a, b, and c to accommodate our unique business needs.” ScrumButs generally reflect an organizational problem rather than special circumstances, and the workaround is a bandage. In reality, Scrum is an intentionally lightweight framework designed for adaptability and elaboration, just not modification. Each component of the Scrum framework exists with a purpose and an interdependence, which collectively support organizational transformation. To implement something less than is to not implement Scrum, and it amounts to a forfeiture of the full potential Scrum can generate. Living out Scrum in full takes COURAGE (a Scrum Value), but also yields dividends.
✔ DO: Empower your Scrum Team.
This may seem like a no-brainer. Of course, we all want to see our teams thriving and delivering. But the unfortunate reality is that Developers are often hamstrung by unnecessary external control. A Product Owner’s autonomy often dies in committee. And a Scrum Master may not have the organizational support (from inside or outside the Scrum Team) to properly apply the framework and truly advocate for Scrum principles. One of the core precepts of Scrum is that the team is self-managing.⁴ This means the people on the team decide collectively what goals to set, how much work to commit to, how to divide up the work, and how to deliver on their goals. Many organizations wouldn’t hear of giving a single person the authority to control the order of the Product Backlog, preferring to spread the power across a governing team or committee, or maybe to hand down decisions on project goals from above. But Scrum requires autonomy for the Product Owner, for a number of reasons. (NOTE: Autonomy does not trump accountability.) It may also come as a surprise to some that no one aside from the Developers (not even the Scrum Master) is expected to be present at the daily scrum meetings. Others are not prohibited from joining – but their role in these meetings would be limited to the support of the self-managing Developers.⁵ Scrum is built upon roles with defined accountabilities, and an organization must be willing to trust the team with the autonomy to deliver on those accountabilities, adapt to feedback from stakeholders, and meet their commitments for Scrum to work. This is the essence of the Scrum Value of RESPECT.
✘ DON’T: Over-structure, over-staff, or over-commit Scrum events.
The aforementioned autonomy of the Scrum Team (or lack thereof) is often reflected in the composition of the corresponding meetings, aka Scrum events. A common pitfall is to allow collaboration to become a hindrance. The meetings that comprise Sprint Planning, Daily Scrum, and Sprint Retrospective are all intended for the Scrum Team, and only the Scrum Team. Sprint Planning may include others by invitation of the Scrum Team, to help inform the decisions being made there by the Team. But it is not a place for management to show up and ensure that certain backlog items make it into the Sprint. Likewise, the Daily Scrum is no place for a business partner to sit in and provide requirements. (Nor is it the place of the Product Owner or Scrum Master to prescribe to the Developers how to manage their Daily Scrum.) The Sprint Review is the singular event intended for dialogue between the Scrum Team and the project stakeholders. And ‘dialogue’ is a key term here because this meeting is an important opportunity for critical feedback to inform the next phase of work for the Scrum Team. To structure the meeting into a one-way presentation from the Scrum Team to the stakeholders would be to lose out on the real value of the Sprint Review. So be sure to make room for discussion, collaboration, and work.⁶ Of course other meetings outside of the Scrum Events can be used to answer questions and inform development, but the priorities, questions, and intentions for each Scrum Event should be carefully guarded. This practice helps cultivate the Scrum Value of FOCUS. And don’t be afraid to embrace ELMO.⁷
Scrum takes work and patience. Like parenting, you can expect to see maturity develop, both in the Scrum team(s) and in the organization, over time. So in the spirit of Scrum, take these concepts, apply them, then inspect and adapt.
We’ll be back next time with even more Scrum pro tips, so keep an eye out for Episode II. And of course, if you have a project or product but lack the Scrum Team to make it a reality, PMsquare is ready with a trained and certified team to carry your goals across the finish line. Happy Scrumming!
Next Steps
We hope you found this article informative. Be sure to subscribe to our newsletter for data and analytics news, updates, and insights delivered directly to your inbox.
If you have any questions or would like PMsquare to provide guidance and support for your analytics solution, contact us today.
¹ https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf
² https://knowyourmeme.com/memes/the-cake-is-a-lie
³ https://www.scrum.org/resources/what-scrumbut
⁴ The Scrum Guide (2017) previously described the Scrum Team as “self-organizing,” exhibiting autonomy in how and by whom the work of the team is accomplished. In 2020 the revised Scrum Guide replaced the term with “self-managing” and further expounded that the Scrum Team is also responsible for determining what work will be accomplished. See https://www.scrumguides.org/revisions.html
⁵ https://www.scrum.org/resources/blog/myth-scrum-master-must-be-present-during-daily-scrum
⁶ https://www.scrum.org/resources/blog/sprint-review-much-more-just-demo
⁷ Saying “Enough, Let’s Move On,” can be an important technique in keeping meetings productive, relevant, and held to the confines of the time-box.
