Dispatches from the Seventh Circle of Scrum: Episode Ⅱ
Episode Ⅱ: Scrum Strikes Back¹
In a previous post, we discussed several pitfalls common to organizations leveraging the Scrum framework for their product delivery. More importantly, we offered our pro tips for sidestepping those hazards, and for practicing Scrum and living its values in a way that will empower your team to see real returns in efficiency and adaptability. The TL;DR version of Episode I: Have the COURAGE to DO Scrum – all of it; foster an environment of RESPECT that empowers your team to own their work; and FOCUS your Scrum Events (and participants) to accomplish precisely no more and no less than intended.
If you have an active Scrum practice, make a plan to implement one of these tips. Change doesn’t have to be daunting, nor does it have to be forced in all at once. It never hurts to be agile about Agile. In their book Fixing Your Scrum, Ripley and Miller offer an approach to effectively identifying and applying changes within an organization, by asking the simple question: “What’s within my control that I can change to get our organization 15% closer to where it needs to be?”² The Sprint Retrospective itself presents a perfect opportunity to present new ideas to the Scrum Team, and collaboratively identify the right next step toward a more effective Scrum. Anyone on the Team has a right to bring a recommendation and make a case for the benefits it could drive. Have a conversation and then, once the incremental change(s) have been discussed and decided upon, document them so that they can be reviewed at the end of the next Sprint. Implement, inspect, and adapt!
Now that we’re agreed we aren’t trying to change the world in one sprint, let’s take a look at a few more pro tips for renovating your Scrum.
✔ DO: Deliver with each Sprint.
This concept admittedly took some time to sink in for me. Scrum is touted as broadly applicable and flexible – a framework that is just as well-suited for the Government, Manufacturing, and Healthcare sectors as it is for Software Development. But regardless of the application, the guiding philosophy of empiricism is indelible, and with that comes an absolute insistence on early and frequent feedback. In order to get feedback, there must be something to inspect. Whatever the product being delivered, the continuous feedback loop of inspection and adaptation – output and input – requires a “potentially releasable” Increment³ of that product at the end of each sprint. This may sound like an impossible hurdle in many cases, especially in the early stages of developing a new product. How can there possibly be a release after Sprint 1? What about Sprint 0? (Hint: There is no Sprint 0.⁴) But let’s be realistic about what an early Increment may look like. The team’s goal for the first few weeks should not be to get a buggy and untested beta release ready for the first Sprint Review. Rather, the focus should be less on breadth of functionality and more on degree of completion. Not perfection, mind you. Take a small piece of functionality – as small as necessary, but something that can be delivered to the stakeholders at the end of the Sprint for feedback – and develop that functionality start to finish. The resulting conversations about that Increment foster the Scrum value of OPENNESS between the Scrum Team and the stakeholders, which ultimately drives the ability to adapt. Having that valuable feedback from Sprint 1 affects every subsequent sprint, clarifying requirements and reducing waste for the next Increment to be developed.
✘ DON’T: Set up for failure.
Goals must be attainable, immutable, and pursued relentlessly. As I evolved from a field-trained practitioner of something described as “Scrum” in name, to actually understanding how Scrum is defined – one of the learnings that most disrupted my understanding of Scrum was how truly pivotal the Sprint Goal is. And, I should add, undervalued. Stop me if any of this sounds familiar: Your Sprint Team occasionally tweaks the Sprint Goal mid-Sprint to better align with their understanding of the business requirements; or maybe your Team works through as much as they can but realistically completes the Sprint Goal about 50% of the time, or completes 50% of the Goal; sometimes you might abandon your Sprint Goal because it no longer makes sense, or you don’t even set a Sprint Goal. Here’s what Scrum says about a Sprint Goal: It is (emphasis added) “THE SINGLE OBJECTIVE for the Sprint,”⁵ it is never changed, and failure to achieve the Sprint Goal means the Sprint was unsuccessful. Significant motivational power lies behind a Sprint Goal when the entire Scrum Team exhibits the COMMITMENT (another Scrum value) to see that goal accomplished at all costs. It’s the very driving force of Scrum. When coming up short is no longer acceptable, getting to ‘Done’ becomes the norm. The disclaimer here is that the Sprint Goal is not scope, nor is it a list of tasks or business requirements. In fact, elevating the Sprint Goal to its proper level of importance may completely change the way you set goals.⁶ Limiting the Sprint Goal to the possible becomes critical. But the reward is increased efficiency, focus, and morale gained from giving your Developers a clearly-defined target to hit (and expecting them to hit it) each and every Sprint.
✔ DO: Give Scrum the resources to live and breathe.
In many organizations, Time is a scarce and precious resource. To be sure, Scrum comes with a cost when done right, and that cost is measured chiefly in Time. This is definitely a top three, if not number one irritant of Scrum malpractitioners and skeptics, who feel like the demands of weekly and daily Scrum Events occupy too much of the workweek, and should therefore be skipped, streamlined, or otherwise condensed into something “more reasonable.”⁷ The oft beleaguered Sprint Retrospective is an easy target for omission, because managers and developers alike may view it as an unnecessary extravagance and a time suck. To be fair, perception is not entirely false: The Scrum framework allows for as many as 20 hrs/month in Scrum Events for each Developer. Plus time for backlog refinement. Not to mention time for the Product Owner and the Scrum Master. A Scrum Team of five people could feasibly spend over 160 hours each month (20% of their time) just doing Scrum. But just as each role on the Scrum Team has its area of accountability, each Scrum Event commits to producing important information for the Scrum Team. The Events don’t have to fill the maximum allotted time; the Scrum Master can help determine what an appropriate time box should be for each event. But the Scrum Team must have the autonomy to maximize the value of each Event. An Event must never be skipped. And unless the Team determines the appropriate outcome can be fully achieved in a shorter time, restricting the time allowed for any one Event will negatively impact the important cadence of feedback, adaptation, and planning that maximizes the value of Scrum for your organization. Instead of cutting corners, invest in Scrum. Give it time to mature, cultivating the values of COURAGE, RESPECT, FOCUS, OPENNESS and COMMITMENT, and your Scrum practice will begin to offset the investment with gains in productive development.
Wrap Up
No one is going to do Scrum perfectly on the first attempt. Or several attempts. Learning is part of the commitment you take on when adopting Scrum in your organization. But with that comes a freedom to change and grow. Even a years-old Scrum practice can find new footing by taking an honest look at the way things are done vs. the way they could be done. So if any of the tips above ring true for you, take bold but small steps and see how your Scrum practice can adapt.
Next Steps
If you need help steering the ship onto a new course, or have a project or product but lack the Scrum Team to make it a reality, we can help. PMsquare is ready with a trained and certified team to carry your goals across the finish line. Otherwise, best of luck and Scrum On!
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.
¹ Yes I know, the episode numbering is problematic. But Episode II: Attack of the Scrum sounds too Friday night sci-fi B movie.
² Ripley, Ryan, and Todd Miller. Fixing Your Scrum: Practical Solutions to Common Scrum Problems, edited by Dawn Schanafelt, ed. P1.0, pp 40–41. The Pragmatic Bookshelf, 2020. (https://pragprog.com/titles/rrscrum/fixing-your-scrum/)
³ “An Increment is a concrete stepping stone toward the Product Goal” (The 2020 Scrum Guide™)
⁴ https://www.scrum.org/resources/blog/scrubbing-sprint-zero
⁵ https://www.scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf (p 11)
⁶ https://www.scrum.org/resources/blog/getting-done-creating-good-sprint-goals
⁷ https://medium.com/the-liberators/myth-in-scrum-we-spend-too-much-time-in-meetings-1c3909a1da7f
