May 29, 2021
We have read or re-read Fixing Your Scrum: Practical Solutions to Common Scrum Problems by Todd Miller and Ryan Ripley cover-to-cover, if you don’t count the index at the back of the book (and I certainly do not). As a wrap-up, I want to briefly consider three points.
(more…)May 22, 2021
Chapter 15 is the final chapter in Fixing Your Scrum by Todd Miller and Ryan Ripley. Next week I will sum up my thoughts on the book and the lessons I have derived during the re-read. We will also announce the next book in the Re-read Saturday series. Right now Monotasking by Staffan Nöteberg is in first place in our poll. Make sure to make your voice heard; vote now below.
May 15, 2021
I have heard the sprint review called everything including a demo, demo day, show and tell and sprint review. If teams and organizations do the sprint review well, I don’t care if you call it jello. Scrum defines the sprint review as a mechanism for the team to inspect what has gone on during the sprint and what was delivered in the increment with all involved stakeholders. The event is collaborative with stakeholders to generate acceptance and feedback. It is also a critical path for change management and decision-making. Sprint reviews are a powerful tool for the team and organization to ensure that what is being built, assembled, and/or configured delivers value.
(more…)May 9, 2021
Work entry, in its simplest form, is the steps needed for work to be triaged to ensure that it is the right work, that it is ready to be worked on, and the priority of the work. This week we talk about five common patterns. On Tuesday I will include the PDF in the feed to see if I can spur a discussion about other patterns.
(more…)May 8, 2021
At the end of every sprint, a team should have a deployable product increment. There are a ton of ideas packed into that single phrase. In this chapter, Mr. Ripley and Miller focus on the concepts of deployable and done. Anyone that has more than an academic knowledge of Scrum knows all the reasons and rationalizations for why having a deployable product increment doesn’t always happen. What is worse, many practitioners believe having something deployable is beyond the realm of possibility in their environment. This is almost always a fallacy.
(more…)May 1, 2021
This chapter deals with one of the crux issues that almost every Scrum master or agile coach faces at some time. The daily meeting has become an almost ubiquitous signal to the world that a team or a company is agile. In some cases, people have convinced themselves that doing the daily Scrum is all they have to do to be agile. There are a myriad of reasons why the daily Scrum goes bad. This chapter of Fixing Your Scrum, Practical Solutions to Common Scrum Problems, by Ryan Ripley and Todd Miller, walks through some of the most important indicators that the event is broken. However, it misses one that I’ll come back to at the end of this entry in Re-read Saturday.
(more…)April 24, 2021
The sprint backlog is the work teams do on a day-to-day basis. A sprint backlog is a tool that the team uses to guide their activities. The backlog is a combination of outputs of other activities such as the sprint goal, accepted product backlog (not the same thing as the sprint backlog), and at least process improvement items and activities, such as sprint planning and day-to-day planning. Quite a mouthful. A less complete but more easily understood description of the sprint backlog is “the things the team needs to do to deliver value.” The sprint backlog gets created over and over during sprint as they discover information and knowledge.
(more…)April 17, 2021
Chapter 10 in Fixing Your Scrum, Practical Solutions to Common Scrum Problems, by Ryan Ripley and Todd Miller, dives into planning.. Sprint planning one of the major events in Scrum. All sprints should start with planning (not planning is one of the silliest but common antipatterns). Todd and Ryan begin the chapter by reminding the reader of the definition of sprint planning and the output of the event. The outputs of planning are a sprint backlog containing a forecast, the Sprint Goal, and knowledge. I am always amazed by the amount of information and knowledge generated during planning, as the whole team knows what they are going to tackle and how they are going to tackle it. Planning is a TEAM EVENT. The scary part of this chapter is that none of the antipatterns Todd and Ryan identify in this chapter are common.
(more…)April 10, 2021
Chapter 9 in Fixing Your Scrum, Practical Solutions to Common Scrum Problems, by Ryan Ripley and Todd Miller, tackles the sprint. To paraphrase the Beach Boys
Everybody’s gone sprintin’
Sprinting’ Scrum-i-a
Along with the Daily Scrum, the sprint has become ubiquitous. The technique of timeboxing using a sprint is one of the first indications that a team is using Scrum. As with any powerful and useful technique, there is a natural tendency to bend, fold, staple, and hybridize the idea leading to all sorts of different problems. I have worked teams that adopted one-week sprints (and got a huge value from the quick feedback) and I have run into teams with multi-month sprints (these almost always end up ending badly). The Scrum Guide (new version), as the authors point out, states that sprints are one month or shorter. The sprint is a timebox in which work is done and a scaffold for the Scrum events.
The first of the antipatterns that Todd and Ryan tackle is one of the most common that I observe, the need for a special Sprint. There are nights when I lay awake contemplating the possibility that someone or some school somewhere is teaching newly minted Scrum Masters to add special sprints. Todd and Ryan point out any number of different variations on the special sprint theme; sprint zero, design sprints, development sprints, integration springs, hardening, testing, bug, and planning sprints. Maybe even sprints for sprints. In the end, what is being described is a timeboxed waterfall approach. If I was going to do waterfall I would want to timebox, but I would not call them sprints NOR would I try to rationalize that this was any form of agile. These special timeboxes are an attempt to deal with organizational issues that can span organization design or lack of training without addressing the underlying problem. A classic example of this issue is the testing sprint (development is done in one sprint and then testing in the next). Having written a few lines of code in my career facing this type of scenario, I can assure you that trying to get back into the same frame of mind as you were when you originally wrote the code isn’t easy and causes a lot of rework and technical debt. These types of issues are often dismissed as “culture.” Remember that culture is a choice, not an excuse.
Another of the common antipatterns is the “variable-length sprint.” Honestly, until three months ago I would have said that I had not seen this antipattern in nearly half a decade. People who don’t like timeboxes generally have gravitated toward Kanban or gone back to waterfall. To my shock, when gathering information to bid on a piece of work, I ran into an organization that blithely announced that they regularly changed the length of a sprint because they weren’t going to get everything done (they also had a testing sprint afterward). The product owner was less than sanguine as she had zero idea of when anything would be delivered and spent a decent amount of time making excuses to customers. I did not bid on the job and note on LinkedIn. Unfortunately, I now have encountered this old bugaboo several more times (all in one geographic area). Some of the issues reflect the lack of knowledge needed to break work down, having hit a velocity standard, or the ability to control work entry. Changing the sprint length does not address the root cause of the behavioral problem, but rather masks them.
The sprint is one of the most ubiquitous artifacts of agile, even when they are not using Scrum. Sprints are timeboxes that help teams to focus on delivering a specific goal and then get feedback quickly. Sprints are great but don’t work well when they are modified to hide organizational problems.
The Coaches Corner in this chapter hit home for me the second time I read the book. The value of works like books, blogs, and podcasts change as we encounter situations in our careers. The exercise in the coaches corners provided me with ideas to help a group of people doing very different and unrelated work identify the common parts of their work-life so they discover how they could work together a little (and a little better).
If you have not bought your copy — what are you waiting for? Fixing Your Scrum: Practical Solutions to Common Scrum Problems
Previous Installments
Week 1: Re-read Logistics and Front Matter – https://bit.ly/3mgz9P6
Week 2: A Brief Introduction To Scrum, and Why Scrum Goes Bad – https://bit.ly/37w4Dv9
Week 3: Breaking Bad Scrum with a Value-Driven Approach – http://bit.ly/3stGc9Q
Week 4: The Product Owner – https://bit.ly/3qpKvSn
Week 5: The Product Backlog – http://bit.ly/3cAEk9c
Week 6: The Development Team – http://bit.ly/2OLVAAs
Week 7: Embracing The Scrum Master Role – https://bit.ly/3m0HB5D
Week 8: Management – https://bit.ly/31Kv39l
March 27, 2021
In SPaMCAST 642 Vasco Duarte made the startling statement that a Scrum Master will be your next CEO. Chapter 7 in Fixing Your Scrum, Practical Solutions to Common Scrum Problems, by Ryan Ripley and Todd Miller echoes the power of that statement by emphasizing the definition of a scrum master. As is the pattern of the book, after delivering context we dive into the antipatterns. You can easily find examples of all of the antipatterns in this chapter in the wild. This is a function of both the role and the business-societal norms. Business norms are hierarchical in nature whereas the Scrum Master, while a leader, exists outside of the standard corporate hierarchy. If you are in the hierarchy (or striving for the ladder), it is easy to brand the role as overhead or as competition to middle management. The two mindsets are at odds with each other which causes many of the anti-patterns noted in the chapter.
(more…)
