When Good Scrum Goes Bad — Identifying Bad Agile Smells
Find agile government news, case studies, videos, training, and more at www.agilegovleaders.org.
“Okay, Sara, tell us what you’re working on, what you did yesterday, and if you have any blockers.”
“Well, I’m just working on the same stuff as yesterday. That’s my update.”
For some teams, a scrum update like this is the norm. Over time, the team has become accustomed to providing a minimal amount of information in an effort to avoid difficult conversations or to get out of the scrum meeting as quickly as possible. To borrow Martin Fowler’s analogy of ‘code smell’, there may be agile practices you experience on a daily basis that have a bad smell — indicative of a deeper problem.
Here are several smells to watch out for — and how to combat them.
1. Your team is having trouble managing the scope of their sprints.
There are a variety of reasons a team may find itself changing scope mid-sprint.
Some teams independently increase their scope of work by adding unnecessary UI improvements or automation that was not requested, causing other work to falter. Many developers view scope-stretching as a good thing because they want to exceed customer expectations. However, this often delays other work — which had been prioritized during sprint planning — from being completed on time.
To avoid this, give developers input into the story writing process. And remember that once a story is part of a sprint, the team can update and clarify the story as needed. If a developer finds during the course of a sprint that a particular feature or styling may add a lot of value to a story, they can discuss the idea with the product owner and scrum master. At that point, you can decide to include the change in this sprint, or defer to a future iteration.
Another culprit of scope creep is when stakeholders pull the developers’ attention away from work that is in the sprint with seemingly small requests. A small data request may seem harmless, but the time it takes for a developer to switch the context of their work can be quite costly. Extrapolate this to multiple developers and multiple times per week and you can see how it becomes a big problem. Rather than allowing users to call developers directly, route communication through the scrum master or project manager.
Finally — and this one can be difficult to spot as you may be the source of the issue — are you second guessing your decisions for the product? Sometimes a team will start building a new feature with the direction provided in the user story and show you an early prototype. You look at the prototype and wonder, “Why did I ask for this when solving the problem in another way would have been better?!”
That’s a great question and it’s also the perfect time to pump the brakes on the new feature being developed. Rather than stringing the team on and asking them to try this or that, stop the development of the new feature and think through what you want. In the next development cycle, the team can start work on the updates.
2. You think you are getting X but you get Y at the end of the sprint.
Articulating a vision for an application can be quite difficult. You may think you are describing things clearly but the development team is hearing something totally different. This is the nature of the software development beast — sometimes things just don’t translate very well.
To mitigate this risk, ask your development team during the sprint planning meeting to explain the business problem back to you using simplified language. If the team is having trouble re-explaining the business requirement, that’s a good sign there is a gap in communication. Additionally, have developers bring you into the review process while they are coding. Remember, a story is a promise to have a conversation — it is not the end of the conversation about the feature. This could be as simple as reviewing a wireframe or going through a workflow prior to validations being developed. Great things happen when users see early feature demos.
3. Scrum updates are generic or lack detail.
This often occurs when teams do not have their task board pulled up and displayed for the group. The task board — or for some teams, Kanban board — is vital to a productive scrum meeting. Your scrum master should be using the board as a guide for the discussion: “Lee, tell us about ticket JK-123.” Whereas before Lee may have said “I’m just working on the same stuff,” he is now responding, “I started work on JK-123 yesterday and hit some snags with the javascript.” Your team just got a lot more feedback and the super smart javascript developer on the team learned that Lee is blocked and will swoop in to help.
4. The team is continually blocked by outside factors.
Your team may constantly report that they can’t do X because they haven’t received the latest SSL certificate, or they are waiting for an account on system Y. The first line of defense against this problem is the scrum master — they should act as a servant leader to address the team’s needs first and foremost. In many cases, the scrum master will work to unblock the team by making calls, following up with individuals, or even hunting down signatures for approval.
However, there are also times when the product owner is in a position to provide some extra ‘oomph’ to an issue and move it to an unblocked state. The product owner knows more about the organization and is often in a better position to raise questions or concerns up the chain of command to keep things moving.
Regardless of where support comes from, make sure sure your team clearly identifies when a particular story or task is blocked by changing the ticket color or moving it to a ‘blocked’ status.
5. At the end of a sprint, the team often demos work that has bugs.
Whether this is a problem depends on whether your team has engaged you to review any of the stories before the end of the sprint. If not, ask them to incorporate this into their process. Your review at the end of a sprint should not reveal anything new. Instead, it should be a comprehensive demo where the team shows all of the stories working together.
If the team is reviewing stories with you during the sprint, you are in a great place. Bugs are a routine part of development and one of the reasons why your team engages you early, gaining a fresh set of eyes on a feature that is being developed. However, your time is valuable and if you find yourself meeting about each user story multiple times, it may be a sign the scope isn’t fully described or there is a lack of quality in what is being delivered.
If you are routinely finding extra things to add to a ticket or small requirements that were overlooked, put those into a separate ticket. Some teams will pick up tickets that are considered ‘nice-to-have’ at the end of a sprint — or simply forward them to the next iteration. If quality of reviews are a problem, ask the scrum master or project manager to review the changes first. Doing so will increase the scrum master’s visibility of the project and start to change the behavior of developers. If you are still having difficulty, ask the team to share their tests so that you may understand what they are doing before it comes to you.
6. “That’s a lot of work, we cannot even begin to estimate that.”
This is a typical response when you ask a large question such as, “How do we wrap our heads around this data quality issue?” or “That nightly sync routine always has problems — how can we fix that?” The best approach when a story is too large to be estimated is to split it into smaller pieces that can be estimated.
Sometimes the better question is: what do we need to learn about X so that we can make better decisions about it later? Prioritizing an analysis story to have one or more developers investigate an issue can be an invaluable addition to your sprint cycle. As a result of the analysis, the developer should be able to write a series of user stories that address all or most of the large issue. You can prioritize those stories in your next sprint. This sets your teams up for success and helps you tackle persistent issues that everyone was previously scared to touch!
7. Arguments often arise in your group over agile practices or semantics.
Each team will have their own flavor of agile even between projects, not just between departments. Debates about the ‘right way to do agile’ can be frustrating and painful. Rather than focusing on why your stories are another team’s tasks, look at the similarities between your approaches. If necessary, appeal decisions to the scrum master and then to the executive. Let them make the final call.
It is better to have leadership say “We hear your opinion, but we are going to do agile this way for the next few months, and then we will reconsider our approach,” than to have everybody squabbling. Impassioned people care about details, but executives get paid to make decisions like this. At the end of the day, what matters is that releasable code is shipped. How teams get there is less important.
8. Deployments take a long time and routinely run into issues.
It’s important, especially for product owners, to know how much actual time the team is spending deploying changes to production. If you are only being told when the release is completed, check with the team to learn about deployment length and process.
If the average deployment takes over an hour, that’s a good sign things aren’t going well. Long release times can be caused by the team having to perform a large number of manual steps or spending time troubleshooting issues throughout the deployment. These practices introduce risk into your deployments which may result in downtime or other unintended consequences.
Rapid — and even continuous — automated testing and deployment is a strenuous art practiced by the highest-performing teams. You have a responsibility to invest in decreasing deployment time adequately enough to provide a good ROI for your team — and for users, who will experience less downtime and unexpected outages.
9. Your team is regularly working on three sprints at once.
If your team seems to often be working not only on the current sprint, but also on the past and future ones, ask why this is the case. Is the team unable to deploy their changes at the end of a sprint? Are actual deployments taking too long? Are stories being counted as “done” when in reality they don’t pass quality assurance and are too buggy to be released?
A valuable discipline is to make each sprint releasable. This doesn’t mean you actually have to release it, but you should come as close to a full “dress rehearsal” as possible. The very best teams at elite companies like Facebook and Google have compressed release times down to days and hours. If you cannot achieve that, you can strive for making each sprint as releasable as it can be.
If a bug would prevent the software from being released, then the story must not be counted as passing QA, or else you are twisting your velocity into something inaccurate. It is far better to be truthful about how slow you are going than to fool yourself about how fast you would like to be going.
Now that you’re familiar with some common bad agile smells, you’ll be able to spot it quickly if your good scrum starts going bad. If you are diligent to watch for these tendencies, you can identify problems early and solve them effectively — which is, in a nutshell, why you started doing agile in the first place.
About AGL:
Agile Government Leadership is a group of agile professionals bringing government experience and perspective from federal, local, state, and industry. You can visit our website for free resources, news, training, case studies, and more: www.agilegovleaders.org
