It’s October, so why not write a Halloween type post. I have been writing a lot recently about Scrum and can think of nothing more scary in that context then Scrum done poorly.
“Agile now means, we do half of Scrum poorly and use Jira.” – Andy Hunt
This statements brings a giggle, but is also scary because of how much truth is behind it.
What does doing Scrum poorly look like, and what is the cause?
Forced Scrum
Scrum forced on people as a means of “being Agile”, will fail. It is usually introduced by management that have not been a part of any real organizations or teams working in an agile way. Or, this management has some experience, but it was what we lovingly refer to as “Dark Scrum”.
Forced Scrum is management dictating who, when, and how people will do their work. It imposes a standardized cadence that all management structured teams will follow. This is not done with malice, these people honestly are trying to do something to help everyone. But these people are often not properly trained in agile values and principles or the Scrum values and framework. This leaves the people on the teams with a clear understanding of how they usually did their jobs, but no clue how to work in their new Scrum role.
Daily Scrum Status Meeting
The Daily Scrum is intended to allow the team to inspect and adapt their progress and plan towards achieving the Sprint Goal. The output from the Daily Scrum is a solid plan of how the team intends to organize the work for the day.
The Daily Scrum Status Meeting however goes very differently. The “Scrum Master” or Manager over this newly created Scrum Team pulls some teeth to get answers as to progress on PBI’s. Who is working on which one, and when will it be done before someone dictates who will do what, how, with whom, and when. Not to mention the fire spitting and blame for things that weren’t done yesterday.
Standardized Scheduled Backlog Refinement Meetings
Part of forced Scrum often is the predetermined cadence and scheduling of the Scrum Events. But this one gets me a little bit. Yes, Product Backlog Refinement is a real thing. And yes, it needs to happen. But nowhere in Scrum does it dictate that you need to have a whole team Product Backlog Refinement meeting 2 or 3 times every Sprint lasting a minimum of an hour.
I am guilty of this as well, thinking this is fine to implement when starting out using Scrum as a means to organize and stay on the same page about the work that is coming next. But it is not something that is prescribed in the Scrum Guide. And can actually be quite counter-productive. I actually think I picked it up from Mike Cohn some time ago.
That being said, the product itself and the way the team works best should drive how and when backlog refinement occurs. I view product backlog refinement as a very fluid thing. At times, it may require the entire team, and others, just a couple members of the team. One key I would like to point out though is to keep your product backlog as lean as possible. We do not want things we think we need to do sometime down the road loaded into the product backlog like a wish list or dumping ground.
Sprint Review/Demo/Assessment
The Sprint Review is intended to be used for the Scrum Team and Stakeholders to see the current state of the product, what was accomplished during the last Sprint and provide some guidance on what moving forward would look like.
What typically happens however is a demo of sorts of all of the Product Backlog Items that were demanded of the team for the last Sprint. Sometimes there is a clear Sprint Goal that ties these things together, but most often it is just a list of the things demanded to get done. A demo of what was built is shown to the stakeholders, more often then not it isn’t everything that was pushed on to the team as it was too much, it isn’t really that good and the overall disappointment, anger and frustration grows.
I personally like doing Sprint Reviews a little different. I like having our customers/users/stakeholders use the latest increment of the product in front of the team. Every time they have a question about how to do something, or come up with some change to the product, we capture that. We then have a conversation around what would be vision of the product moving forward over the next iteration.
Almost Scrum Teams
A Scrum Team is defined as small (<10), cross-functional, self-managing group of people with all of the skills necessary to create value each Sprint.
With Dark Scrum you will find teams constructed of specialties but working as sub-teams.
- UI Team
- API Team
- Database Team
- Deployment Team
- QA Team
- PMO/UX Team
This results in delays, dependencies and hand-offs. It also brings a scary side effect of a version of Sprinting over a modified waterfall process.
- PMO/UX Team defines requirements gives to UI, API and Database Teams.
- Teams break the work down by their specific areas and load their Sprints.
- Teams build their pieces by the end of their Sprints. In the best case scenario it is all done.
- Then these teams need to integrate. Sounds like an integration Sprint is needed.
- Oh wait, it hasn’t been tested. Sounds like a Testing Sprint is needed.
- Ok, lets release it. Wait, need a Change Management Ticket for the Deployment Team that needs to go through CAB Approval.
- Ok we are ready to release. What is our release window? Oh it is 5 hours. Fantastic
I know I kind of ranted on that list a little. But this is what happens.
To me, building a Scrum Team is the same as any other agile team. We need UI, API, Database, QA, Deployment, Product and UX skills on the team. Working together on the product on the most important thing to do next one at a time. And that ultimately also requires right-sizing the work. I talk about this the Story Narrowing post.
Multiple Product Owners/Interrupting Stakeholders/Managers
Scrum defines a single Product Owner responsible for maximizing the value of the product. This single person prioritizes the Product Backlog and is empowered to make decisions as to what is to be added to the product.
With Dark Scrum, their are often teams with multiple Business Analysts instead of a Product Owner. Each Business Analyst represents different business needs and demands. I have experienced three outcomes:
- An area of business is continuously ignored in favor of the loudest person in the room.
- Stakeholders reach out directly to either Development Managers or directly to Developers to “just do this little thing” for them on the side.
- Team ends up dividing their capacity for each business area in order to try and appease everyone.
These all have varying levels of bad. And deeper issues then just not having a single Product Owner. But what Scrum is proactively trying to achieve is that this one person, this Product Owner, is that filter for all of the Stakeholders to bring their requests too. And then this Product Owner has the responsibility of ultimately deciding what is the priority.
Missing or Misused Definition of Done
The Definition of Done is critical to a Scrum Team. It is defined as the formal description of the state of the increment when it meets the quality measures required for the product.
Often with Dark Scrum, the Definition of Done is either not created, or created but ignored. I can keep this section rather short. If the Scrum Team does not create a Definition of Done, please work with them to do that immediately so everyone can have a shared understanding of what a done increment looks like.
If the Definition of Done is ignored, address why it is ignored and if the current DoD makes no sense and needs to be revisited.
Ignoring Scrum Exposures
For me, the most valuable part of Scrum is that it shows you where you suck. Scrum will very quickly identify pains in your the ways you work from relationships to processes.
Often times with Spooky Scrum, is these things are ignored and even worse, Scrum is blamed for their existence. It isn’t Scrum that introduced these pains, they were already there. In order for Scrum to be successful, these pains need to be resolved.
Closing
I will stop there for now as there are plenty of things I know I left off. I will have another post shortly as a follow up from a recent podcast episode I did with Dan Neumann from AgileThought on Scrum cling-ons and the culture shift where we discuss some things that are often done with Scrum as if they are actually a part of Scrum but are not.
Chris Pipito 