Ideas Needed to Help a Good Team Identify Areas to Improve
Hello, I have not been on here in a long time. I started a new Scrum Master position just in the last 3 months. I've been a Scrum Master for about 10 years now and my experience has ranged from a small non-profit of less than 2 hundred people to huge companies of more than 10,000 employees. You would think, with 10 years of experience, I would come up with ideas on this, but have run into something I have not had before.
The team I am with is great! So far, in my 3 months with them, they have not had a single story move forward from 1 sprint to the other. They are planning great and estimating great and are getting everything done. In a couple of sprints, they have been able to pull in an extra story or 2 and got those done, as well. They communicate well with each other and with other teams. They cross train on their own. They pair when it's beneficial and do so on their own initiative. Our PO is fantastic! We have regular refinement meetings and there has been a consistent 2-3 (sometimes 4) sprints refined and ready to go.
All of that to say, in my 3 months with them, we have not had any good improvement items come out of our retros. We've had a few general things to consider, to be aware of constantly, but those are ongoing things. They have not had any actionable, measurable items to do.
I learned they could use some reminders and teaching on the basics of Scrum, the Scrum values, etc., but we have a separate forum that is dedicated to that.
So . . . any ideas on how I can help them identify actionable improvement items and make retros more productive than general encouragement and "shout outs"? Or, is this ok for a while, as long as the team is functioning as they are?
Thanks!
A few questions as I didn't see mention of these essential concepts, as this feels a bit mechanical to me:
- Do they deliver a valuable, useful, 'done' product Increment at least once a Sprint and every Sprint?
- Do they have a Sprint Goal and consistently meet it?
- How is customer value being measured and validated against a Product Goal?
The team might be great, yet what empirical evidence can be shown especially around customer value, innovation, and time to market? Customers and end users don't care that you're estimating great, finishing work without carryover, and that the team is pairing if you're not releasing early and often and delivering value. Perhaps have a look at Evidence Based Management and use those measurements to inspect and adapt in your Sprint Retrospective.
All the best!
The team I am with is great! So far, in my 3 months with them, they have not had a single story move forward from 1 sprint to the other.
That's a red flag to me. Not because it's a bad thing...but because if that's somehow a measure of success, it suggests the team just has a woodpile of work and is sawing away at it efficiently. Their effectiveness at innovating, and at managing risk and complexity in Sprint time-frames, somehow doesn't seem to be on the map.
What good Sprint Goals have they achieved recently, and how effectively has validated learning been leveraged to optimize product value?
I learned they could use some reminders and teaching on the basics of Scrum, the Scrum values, etc., but we have a separate forum that is dedicated to that.
If the basics of Scrum aren't established any success is likely to be a veneer. Why has this matter been sidelined to the forum you refer to, and why aren't the consequences of any delinquency being felt?
I agree with @Chris and @Ian. You appear to be focusing on the wrong things as indicators of success. Since you made no mention of Sprint Goals or delivery of valuable increments at least once per Sprint, I would suspect that they are just completing a lot of items from the Product Backlog. If I were in your place, I would start to ask questions about how the team feels about the value they are delivering and how they determine that value. Sometimes complacency can lead to the situation you describe and a false sense of accomplishment is felt.
Thanks everyone for the comments thus far. You raise good points and part of my focusing on these things is most of what I know, being pretty new. The team isn't identifying a lot to improve on. I just haven't quite put my finger on it to help guide them and yall's input is good. I'm still learning how their work fits with the other teams we work with in the same business unit.
To answer the concern about sprint goals, we do have defined sprint goals, from our PO, every sprint and team delivers. At this point, I have been trusting the team and the PO more on those as I've been learning. That being said, that's a good start that I can take away and consider the goals and work . . . are they valuable to the customer and can we make things more valuable? Also, I will absolutely look into the EBM article you linked @Chris.
@Ian, I can use retros as a time to reinforce Scrum basics, but this "forum" to which I referred is a meeting that happens once a sprint. This org has designated the last day of the sprint a "learning day." It's a bit of innovation day, but the team members can decide what they want to learn more about, work with each other on something, KT across teams, or whatever, as long as it is work related learning. One of the opportunities that I, and my fellow SMs, have is Agile and Scrum basics training. They don't all come to that, so retros could still be a valid opportunity to educate and coach.
Thanks for the input! (If anyone else has anything, please let me know.)