Treating Zombie Scrum and ScrumBut
Hi,
For about a year I've been the nominal scrum master for an IT team that has been (nominally) practising scrum for several years. I am facing several problems for which I'm having difficulty finding a solution. I'm seeking advice not so much on addressing each of these problems, but moreso on how to approach my role and what our team is trying to do in terms of methodology.
The main 'problem' - our team is not praticing scrum
From my understanding, there are many key elements of the scrum framework to which we do not adhere. Two examples:
- We are not delivering clearly defined, usable increments to customers each sprint
- The team is not fully self-directed - and are assigned a set of tasks each sprint by the PO.
- User story estimation is performed only by developers (not QA or BAs), and a developer only scores (individually), the stories that the PO plans to assign them
Complicating factors
Assuming (and I acknowledge this may be a faulty assumption), that moving in line with scrum is our best way forward, I have tried to encourage discussion or propose changes to address these points above. There are a few factors that have made this tricky:
- Multiple concurrent 'projects': we operate a platform on which we release new applications (variations on a central product) fairly frequently. Generally, once the application is released there are very few updates. We're in a very large organization and as such have a lot of various business stakeholders so we essentially have a constant revolving door of customers. This and the fact that we have multiple implementations at various stages of progress mean I find it hard to suggest how we can plan and produce a clear increment that means something to the whole team and our stakeholders
- Team size: somewhat connected to the above.. we have almost 20 people in this team. There is a fairly clear delineation between some of the topics that would allow the team to be separated into two, but the team themselves are strongly against this (there is still enough crossover between all topics that they feel they need to be in the same standups etc.
- 'Environmental factors': there are several surrounding non-delivery circumstances that make change hard: I do not feel like I have the confidence or experience to advocate for changes to our ways of working, especially as the team quite often has counter arguments to suggestions, and I feel compelled to back down.. I don't want to force some process on them when I don't have confidence I can coach them into make it successful.
- Example 1: I think changing our estimatation processes could improve how we measure velocity and subsequently allow us to better reflect and adapt. I have propsed that we should try poker planning, that all development team members should score, and that we should utilize group scoring. The team said they tried this when they first began scrum, and that it doesn't make sense to them to have testers or designers scoring technical tasks.
Square peg in round hole?
We don't have much top down support for implementing proper scrum, and some of the particulars of our team makeup and commitments are making it hard for me to implement the methodology. Does it sound like we are just ill suited to a scrum approach?
Generally, the team is delivering fairly well - but I am wondering if the scrum ceremonies are just arbitrary timewasters, if we aren't practising the values.
Summary
I know that this is quite a rambling post. But, I am somewhat overwhelmed and am feeling like the task at hand is getting the better of me. I just want to feel like I'm helping this team, or contributing something positive - and right now, I couldn't feel further away from that. I'd really appreciate any general advice on how I can get a handle on the situation. Thanks in advance
Each one of those challenges mentioned are impediments, whether it be 20 people on a team, high work-in-progress limits from multiple projects, POs assigning work, not having a useful valuable Increment each Sprint, or lack of self-management. A great Scrum Master never tolerates impediments, and will work hard to make them transparent and to be a catalyst that causes change.
Change isn't going to happen over night, and you don't need to do this on your own. The impediments you listed become your transformation backlog. How can you partner with other Scrum Masters, leaders, and other people in your organization to understand and make the impediments transparent? Perhaps form an enablement team. Could you use a Liberating Structure such as 15% solutions?
More on 15% solutions:
- What is made possible? You can reveal the actions, however small, that everyone can do immediately. At a minimum, these will create momentum, and that may make a BIG difference. 15% Solutions show that there is no reason to wait around, feel powerless, or fearful. They help people pick it up a level. They get individuals and the group to focus on what is within their discretion instead of what they cannot change. With a very simple question, you can flip the conversation to what can be done and find solutions to big problems that are often distributed widely in places not known in advance. Shifting a few grains of sand may trigger a landslide and change the whole landscape.
There's also a book called Zombie Scrum, which not only shares the symptoms such as you are describing, it gives some antidotes to experiment with.
I'd really appreciate any general advice on how I can get a handle on the situation.
The situation appears to be one of missed opportunities. Can you get a handle on those? Each one of the impediments you describe will restrict innovation, and before a gap can be navigated people must first see it.
The main problem is probably not that the team is not practicing Scrum. If the business objectives are achieved, this doesn't really matter. Scrum exists to help solving business problems. Scrum does not exist for the sake of Scrum...
How I tend to approach these situations:
1/ Make transparent what the main challenge is the team is facing. What is their biggest struggle? And keep them away of everything that has to do with Scrum here. What is really the thing that gives them a hard time? Is it delivery, is it quality, whatever...
2/ What is the impact of this struggle? What happens because of this?
3/ What are possible causes of this struggle? What triggers this? How did we get in this situation?
4/ See how 2 and 3 connect. You will probably have some intermediate boxes to fill out. But very likely, the impact of the struggle leads to other behaviors or events, which in turn leads back to the causes.
You have just created a Doom Loop (part of Systems Thinking). More at https://less.works/less/principles/systems-thinking
Now with the team, see where the Doom Loop can be broken. What needs to change so this loop stops.
And maybe Scrum can help you with this (my experience is it will)... Maybe not (hey, not everything can be solved with the same framework).
If you can do this (or similar) as part of a collaborative effort with your team, for sure they will see your added value.
Hope this helps.