Scrum is a framework comprised of roles, events, artifacts and rules along with a set of values to be lived by Scrum Teams. We have seen Scrum done well and, in many instances, Scrum not done so well. Here's our insights into some of the more common anti-patterns where many Scrum Teams lose the intent, and more importantly, the personal and business impacts that Scrum could bring to their teams and their organizations.
Scrum framework
The Daily Scrum is just a status meeting
Many organizations treat the Daily Scrum, or Standup, as the opportunity to provide your fellow team members updates on what you did yesterday, what you are going to do today and what's getting in your way (impediments). That's good but this is more like a status meeting and you are missing out on the key value of the Daily Scrum. This is your team's opportunity to re-synchronize the plans made from Sprint Planning based on where you sit today towards achieving the Sprint Goal and update plans to maximize the value delivered by the Scrum Team. If you never challenge each other on what got done yesterday, where is the accountability to each other to meet the Sprint Goal? If you do not adapt the plans provided by each team member for today, are you really maximizing the chances of achieving the Sprint Goal? If you do not outline clear actions and accountability for addressing the impediments, what's the chances that those impediments will get removed from blocking the path towards the Sprint Goal? So, Daily Scrum is NOT a status meeting. It is your daily opportunity to re-synchronize as a team based on what's been done and what is left to be done to get to the finish line.
We are doing standups, so we are doing Scrum
We have heard all too often from teams believing they are "agile" because they are doing daily 15-minute meetings. Scrum is proud to be "lightweight", but it is not that lightweight! In Scrum, daily standups are really only meaningful in the context of driving towards a Sprint Goal and discussing how to adapt today's plans to maximize the chances of hitting that Goal. We determine that Sprint Goal in Sprint Planning. Scrum inspects and adapts what the team builds and how it builds that product in the Sprint Review and Sprint Retrospective, respectively. Scrum has defined roles of Product Owner, Scrum Master, and the Development Team which ensures responsibility for making Scrum tick are clearly owned. Scrum has artifacts of the Product Backlog, Sprint Backlog and Product Increment to guide what the team should build next and its plans for how it should be building the next working increment of the product. So, if you are just doing standups, you are NOT doing Scrum.
Only the Product Owner can refine / groom the Product Backlog
Many teams believe that it is the Product Owner's job to groom the Backlog. That is a correct statement, but it is also the rest of the Scrum Team's job to groom the Backlog. Product Owners are responsible for managing the Product Backlog and therefore should feel accountable for ensuring the refinement of the Backlog occurs continuously so that the Scrum Team always has "ready" stories for the next Sprint Planning meeting. However, the actual grooming of the Backlog is a team sport - all Scrum Team members should participate in the process of refining the understanding of the intent of backlog items and moving them to that "ready" state.
The Sprint Review is just a demo
Demoing working software at the end of the Sprint is one of the most tangible signs of teams living and breathing the Agile Manifesto (I.e., Working software over comprehensive documentation). If Sprint Reviews are focused on demonstrating working software, that is goodness. However, good Sprint Reviews have even more. First, the Product Owner should start the Review with which Product Backlog items got to "Done" and which have not. If you are just demoing the "done" stories and sweeping under the rug the stories not done, you are missing out on a key pillar of Scrum - transparency. The Product Owner also needs to collect the feedback from the Review, provide an update on the state of the Product Backlog, and update the Product Backlog based on that feedback. This way, the Sprint Review becomes a critical feedback loop of the direction of the product being developed. So, a demo is a great and important part of Sprint Reviews, but do not forget all the other value that can come from it.
The Product Owner should not attend the Sprint Retrospective
Many teams have Product Owners that are very busy. Some teams believe that the Product Owners are the key detractors from the team's effectiveness. These issues often lead teams to believe that the Product Owner does not need to attend the Sprint Retrospective. Well, the Product Owner is a member of the Scrum Team and they have a place at the Sprint Review and need to make time to contribute to and hear from the rest of the Scrum Team. Scrum is about value flow - turning a product idea into working software. The Product Owner has a critical role in making sure that flow is enabled and that the Scrum Team has a great Product Backlog from which to build. If that part of the flow is not working as well as it could be, the Product Owner needs participate with the team to reflect on what could be done to improve. The Product Owner also typically has insights from the broader organization on how the Scrum Team is fulfilling its mission. Those insights can provide a valuable perspective for the Scrum Team to consider how it maximizes the value delivered to the organization as a whole. So, make sure to include the Product Owner on the Retrospective invite.
Teams do not really need a Definition of Done
When Scrum Teams form, they often skip some key steps like establishing Team Norms and creating a well crafted Definition of Ready and Definition of Done. The impact of skipping (or paying lip service to) a Definition of Done (DoD) are twofold. First, without a DoD, there is not a standard of quality established for the team. Without that quality bar, there is a higher chance for teams spending time correcting production defects rather than spending all their time building the next increment of product. You also will find yourself as a team declaring stories as "done" only to find out that they are really not ready for release. Second, a DoD provides a basis for Scrum Teams to develop a Sprint Backlog with tasks / activities targeted to meet a specific quality standard. If you have established a solid DoD, this will serve as a guidepost for ensuring the Scrum Team spends time on the right tasks to get to that quality level.
If these myths resonate with how your team behaves or thinks today, take a step back and consider: 1) reading the Scrum Guide, 2) reading some great books on Scrum (Ken Rubin's "Essential Scrum" is a good one), or 3) bringing in some coaching to tune up your team. As George Orwell said, "Myths which are believed in become true." Use this opportunity to dispel these common myths in your team before they become an irrevocable reality and move closer to the intent and value Scrum could be bringing to your organization.