Are you doing scrum wrong?
Yes, it is possible that people are doing it wrong, including you and your teams.
Is your company doing massive plannings, probably every quarter, including having BAs to come up with requirements, and maybe architects and their design documents? Then the developers are asked to “plan in sprints” for a scope that is fixed and basically they have some sort of iterative development phase, all to be later gated in the end by a specific test phase and delivery or deployment phase? Maybe from delivery to inception, it takes no less than 6 months?
Does it look like a little the picture below?
If so, you are doing Scrum wrong! And Agile even more so…
What it might be is something called ScrumFall or Water-Scrum-Fall. And the issue with that is that… you are not benefiting from actual learning, actual reduced delivery time, and increased shift-left quality. Basically, maybe only your development teams are learning how to be more agile, if at all.
In this post, I want to help you by clearing more Scrum misconceptions, and we are going to take a look at each event. If you are unsure about the definitions of each event, I invite you to check out this blog post before.
The Sprint Planning
Quick definition: define a plan and a goal for the iteration. The team owns the plan, which means they can do whatever adjustment needed to make it to the goal by the end of the sprint.
Traps and Misconceptions to watch out for
- People don’t know or lose track of the objective of the Sprint Planning. It is “a meeting” that we have to do in the beginning of the scrum, nothing else.
- People let the success of the sprint be decided by chance; they talk about the work, decide what to do, but do not commit to it. The sprint planning became a place of “hope”, in which a lot is discussed and possibilities are talked about, but the end of the sprint is always a suspense: will we make it?
- People get stuck on a format that does not clearly allow for commitment. It can happen with overzealous Scrum Masters or some other type of personality dominance: we might see that one person only speaks, no collaboration is invited, no clear accountability described for the team that they own the plan.
- The backlog is in terrible shape, so it is hard to derive value, understand what is important. The Product Backlog should be clearly articulated in value and ordered/prioritized. It is a prerequisite. If the backlog is not neat, most of the time will be spent trying to decipher it instead of actually planning and committing.
- The team has very little autonomy so the planning is actually a moment for work to be pushed on them. In many companies new to Scrum it is somewhat understood that this is the meeting in which we tell people what they need to do. In such cases, give them 20 hours for the Sprint Planning and the plan still going to be wonky.
- Sometimes Sprint Planning are basically useless because people cut it short. People decide they have only 30 minutes to plan, that they will just take the first five stories from the top of the backlog. But it so happens the team does not have mature practices or a fantastically organized backlog in place to do it or the work they do is actually rather complex. The idea that stories are all already well taken care of, estimated, and small is only true if the team is putting in the effort to refine them.
The Daily Scrum
Quick definition: look at the plan. Look at what has been accomplished so far. Are we making it to the goal? If not, adjust!
Traps and Misconceptions to watch out for
- Like for planning, if people don’t understand why it is there, can you imagine how annoying is that to have a meeting that you have to attend every single day? People will attend sessions they take value from. And the first step toward getting the most off of a session is to understand its intended outcome.
- Status reporting is not a Daily Scrum. It is not uncommon that teams that operated on more traditional project management styles might interpret the meeting as a moment to give line of sight on their resource allocation. This is not only not good because people feel singled out but also it creates a lot of noise when people decide to talk about all the other stuff they’ve been doing (to prove that they are busy!), that has nothing to do with the Sprint goal.
- Not talking about the problems, blockers and help needed openly. The point is exactly to be transparent about what needs course-correction and what seems to be running smooth, so people can make decisions on where to invest their time and how. A team that is having a hard time on that front might be living in a culture of blame or heroes, so no one wants to be perceived as the low performer.
- Given the last 3 points, unsurprisingly some people see the Daily Scrum as optional because they derive no value from it or because people are hiding from the high exposure to scrutiny. Teams where safety and trust are not established will quite often experience that.
- Not looking at the board, not reaffirming the Sprint Goal, not looking into the team metrics in place. If we want to inspect progress and readjust towards the goal we need to have a clear vision of where we are at. Boards and burndowns are not just “visual aids”. They are a representation of what we say is true, and a great helper for transparency: they reflect our progress to the world outside, so that people don’t come ask us us every five minutes. There should be no mismatch between what we say and how we represent them and these items should be present on a Daily Scrum and help us make sense of the sprint so far.
- Not taking the opportunity to make decisions: re-plan, swarm or pair on a specific task, abandon specific work items, etc. We progress toward the sprint goal itself, not towards tasks or work items on the sprint backlog. If tasks are in danger of not getting complete or they just become obsolete, we should make decisions to resolve/discard them every single day.
The Sprint Review
Quick definition: ask the stakeholders “have we done enough for the product?” and “Do you want to change anything?”. If there is no interaction had in a Sprint Review it is not a sprint review.
Traps and Misconceptions to watch out for
- Like all the other events, if people don’t understand the concept this is yet another meeting and one that is considered “expensive” to prepare for. One in which the invitee list is many times mismatching with its intent, in which clients and stakeholders are missing. This can happen when traditional companies moving into Scrum think this is “one of those team meetings” and no interested party should bother to attend.
- Boring power point meeting. As much as some people can make engaging presentations, the Sprint Review is by nature an interactive event. We want to interact with our stakeholder, we invite their feedback and learn as much as possible what is their take on what has been accomplished. Presentations are not forbidden, but we should keep in mind this is not an informational, a “read-only” type of session.
- Not talking about future backlog is a big miss. If we can show the value of what has been accomplished, we should be able to then reorder, remove, add, simply re-evaluate the Product backlog in light of what we all learned, including the stakeholders. We are not committing right there about what we are going to do next, but we are looking for convergence about the next steps.
- Quite often the one above is lacking and yet this one seems overly present in big corporations: the boring talk on story points and velocity. Metrics that only make sense to the team, that helps the team progress and self-organize have no place in this event. They will make sense to no one else, as they vary for every single team. I honestly believe this is a reminiscent of command and control in certain companies’ cultures, a tight hold on the habit of resource allocation. It might derail the conversation towards utilization instead of moving towards value.
- Also missing, or shy on the agenda, is the talking about what went wrong. How can we prepare and be sure certain impediments on processes, environments, technologies and other resources will be removed from the team’s way? The Sprint Review is a great moment for the team to ask for help and generate lessons learned for everybody.
The Sprint Retrospective
Quick definition: answer the question “how can we get better as a team?”. Let it take the time it takes, but don’t skip it. If there is nothing to learn, this is not a retrospective.
Traps and Misconceptions to watch out for
- Confusion about who is invited. Can managers come in? Is the Product Owner part of the team? This is an event to assess quality of processes and of ways of doing things. It is a moment for team inspection. In order to be honest and useful, clearly a safe space is needed. For certain teams it means just core team members. For others, it can mean anyone who helped in the sprint is invited.
- The Scrum Master speaks a lot. It happens with the best of intentions: the Scrum Master detected some pattern and uses the session to call out the team’s behavior. But be mindful to present the observations and let the team take the discussion and insight where they need it to.
- Boring “bla-blah” meeting. I’ve seen retrospectives where the team is just venting about how the sprint went. It becomes a space to commiserate from which very little learning or action results. While everybody needs a place to express themselves _and the beginning of the retrospective can accommodate that_ complaining does very little to fix problems. So take the complaints as a starting point and do something useful to never have that complaint happen again!
- Or sometimes the opposite: “kumbaya” meetings. Retrospectives are a great place for team bonding but if they never get uncomfortable you are doing it wrong. It is not a party or just a celebration of the good stuff. Make room for Kudos and celebration, but balance it out with actionable items for next sprint(s). If you are just singing kumbaya you are missing an opportunity to learn and grow, which ultimately translates into much better days working together. Think of it, what is best: ONE meeting where everybody feels good and all the other days of the sprint are painful, or ONE meeting where it gets uncomfortable but that gradually makes team life easier on a daily basis?
Consider
Are you doing scrum wrong?
Keep the reminder that Scrum as a framework is conceived for inspection, adaption, and transparency. It attempts to elicit focus and commitment. It requires an environment of openness and respect and courage. Every piece you remove, be it a role, an event, a principle, makes it not Scrum. There is no problem in adapting as you see fit, but you should not be surprised if you or your teams are not collecting the intended results. If you want to modify it you will have to give it a deeper thought on what is it that you are removing and how you are going to solve the gap. You might end up with more meetings or with new names to already existing ones. In any case, you will be creating your own framework. That is perfectly fine and actually it can be an awesome thing. But there is no magic or easy solution.
I would say, though, if Scrum seems too painful for your teams, take a note on what are the pain points, why there are “too many meetings” and the cultural shift that might be necessary to bravely adopt a framework like Scrum. Consider the items discussed on each event in this article. And ultimately, remember that you don’t have to use Scrum to be Agile. But if you do use Scrum, you should be prepared for discomfort and dysfunctions that Scrum might unearth. Working in Agile requires adopting a new mindset, when in fact many companies actually just attempt to “deploy structures” on their teams and call it a day.
Interested in learning more about Scrum?
If you are interested in learning more about Scrum, check out my e-book. Scrum is very simple, and you can learn how to use it in a day. If you never worked with agile before it most certainly introduces you to agility in a very practical way.
