Scrum Maturity Journey
I am having an interesting experience. A little background first. I had the pleasure of picking up Scrum master duties on a few seasoned scrum teams about 2 years ago. In retrospect, I would say that they taught me as much about creating complex analytics software as I taught them about working in scrum framework, Agile methodology. By the end of 2 years, we were the envy of every scrum team in the company. We had reached Ri (Google shu ha ri).
Fast forward to the recent past and I’ve been asked to step in for a scrummaster in a different division of the company just starting to implement scrum. I relished the opportunity to jump in and get to see how some new teams are reacting to the company’s implementation.
The teams had been practicing scrum for 12 weeks, so I was excited to see how they were doing. I started with my usual base line survey of agile maturity and not surprisingly the reactions were mixed. Here is what I heard…
There are too many meetings
We have all heard this from new teams so there were no surprises there. It is funny that when you point out that typically the Scrum ceremonies take up less than 15% of their time allocation that the tunes change a little bit. Still the stigma exists.
For me, it wasnt the length of the ceremonies that the team should have been worried about, but rather the ineffectiveness. The teams would often miss the purpose of the meeting and failed to gain the desired outcomes. Scrum masters need to guide new teams not only in the framework but the reasons the ceremonies are laid out this way in the first place.
Your job at this stage is to teach. For example Stand ups are not status updates to the Scrum Master , but an opportunity for fine grained coordination amongst the team members. Also stand up is time and place that the team members should be striving to hold each other accountable to the teams sprint commitment. This isn’t something they will be comfortable with in most cases. You have to teach them. It’s your job. Guide them.
We would like to complete all stories but…
Another item that came out of the survey was that teams struggle with completing all stories. This is common even with experienced teams, so again it wasn’t surprising.
The teams will mention lots of causes. Team makeup has the wrong developer to qa ratio, causing bottlenecks. Stories are not well written. The developers are getting stories to Qa to late in the sprint for testing. The team is probably 100% on the nose too.
Your job as a servant leader is to get them out of this mess. You will feel it deep down that you need to fix the issues and fix it now. “Should I push them to use kanban. Are the devs pairing with the testers? Where is the definition of done?” All valid questions to ask.
My advice here comes from the school of hard knocks. DON’T RUSH IT. You have to evaluate each of these areas and identify root causes, then set an action plan for tackling the issues. You just end up with alot of resistance and little movement if you don’t work the plan one at a time.
Let’s take user stories for example. If the team says stories aren’t well written, dig deeper to find why they are feel this way. Inspect the backlog refinement session to determine if the team is asking the right questions of the product owner.
- What are your conditions of satisfaction on this story?
- How should we test this story?
- How do you what us to demonstrate this new functionality in iteration review?
Lead your team. Teach them to get what they need. Have regular meetings with the Product Owner to review the stories near the top of the backlog. There are many approaches to address this common problem. Do what it takes to dig to the root causes on one of your issues before trying to solve the rest.
The organization doesn’t match the scrum framework
Probably the toughest obstacle I am facing with these teams is from the organization itself. As the division was new to scrum, they were still feeling out where everyone fits in the framework. This presents issues for the scrummaster.
It’s not your place to determine what to do with anyone in a role that scrum doesn’t call for. “But Scrum has no dev manager listed as a role”, you say. “How do teams self organize when the dev manager underminds that principle at every turn?” Again, I agree they are valid questions that need to addressed, but not necessarily by you.
What is your responsibility is to continue to be an agent for change. Teaching the organization’s leaders the benefits of agile and the scrum framework. Pushing them on areas of improvement. Guiding them to create an organization that mimics the framework’s prescribed structure.
Keep a couple thoughts in mind though. First, the organizational goal is not to be more agile. Read that last line again. That is not the goal. As a scrummaster, you may feel that way because you are responsible to make sure everyone understands the framework but being more agile is just a method to get to the organization’s goal: producing better software.
Second thing to keep in mind is that if you do you job well enough, you will not be needed any longer. Sure occasionally checking in on a team might be necessary but for the most part you too can become obsolete. Be mindful of that before you recommend the company remove dev managers.
I know these teams and organization has a long road ahead, but I am looking forward to helping lead them through this agile journey. Just like most journeys, they start with a single step. In this case, that step was to do an initial assessment.
Without one, it’s impossible to track progress the teams make. I would highly recommend you do one if you are steping into someplace new.
Good luck to anyone taking on a new team. I feel your pain. The challenge is real…Just continue to learn from others, strive for continous improvement in yourself and always work towards your ultimate job as a scrummaster: Delivering a high performing team.
I look forward to your feedback as well.