Am I failing as a scrum master?
I've been a scrum master for 9 months, but I've worked in IT for 7 years. Currently I am tasked with 7 dedicated teams and 2 fluid teams. The company I work for is obsessed with getting things in production as FAST as possible. So, after 6 months of explaining why these 7 teams weren't working well, mostly because they're all completely silo'd. Every team is divided into individual contributors and they all have to act like their own product owners too. The managers of these teams tell me almost nothing about them, I have to dig for impediments and most of the members complain to me that their managers are all micro managing them constantly, and aren't reporting the problems accurately.
The company wanted to spin up fluid teams that would operate for a specific task and then disband, much more scrum than the other teams. Except, the teams aren't project based, they're MVP based. So, 1 single deployment and the team is disbanded. We don't have time for norming hardly much less storming before the team is disbanded. Plus these teams are still not working together on 1 task, they're still dividing up the work and approaching their own parts and then coming together at the end, very scrum fall.
I am tasked with taking notes on these 2 teams daily scrums, and then emailing that up to the management. So, I am the one that has to report if someone isn't on the call, and I'm not their manager so half the time I am not told if they have a sick day or anything like that, so I'm frequently trying to track members down. Most of the teams have 0 moral right now and think scrum is a waste of time and doesn't "fit their work style". Most of the teams hate JIRA and having to document anything they do like at all.
Both of these fluid teams that recently started, I was informed the day of them needing to be started, no lead time at all. Then after scrambling to get everyone on a call, except at least two of the members were out of office or offshore and already gone for the day, so planning was half assed from the start. Both of these teams were given an outline of the work that was expected of them, and then they got to work. Now that it's the end of the sprint they're complaining that planning wasn't handled correctly, that I failed to explain to them the overall point of the project, and that I need to do a better job of instructing the teams on what's important.
I've been having to escalate to management that people are practically ignoring JIRA, all communication is done through email chains that not everyone gets added to, and daily scrums end up being more of a discussion of work than a re-sync, so people are spending 30 - 40 mins on these calls talking, even after I've explained several times that the discussion is great but needs to be a different call etc, they almost get mad at me as if I'm the bully trying to make them go through what they consider to be pointless meetings...
I'm being asked why the new teams aren't bringing the faster delivery they are expecting, and I have to give a presentation today on it. I plan on reporting most of this, but it's not really news, I've been saying stuff like this for a while. Am I just a crap scrum master? I feel like I am being asked to do things that are not my role and I'm being held accountable for people basically not wanting to do their jobs...
Let’s put your abilities as a Scrum Master to one side for the moment. How much awareness is there, in your organization, that Scrum is not being implemented at all?
My suggestion would be to put as much transparency as you can over the gap.
Management has made it very clear to me several times that they're not interested in "following the scrum bible". "Agile is a framework not a set of rules we have to follow", then I'm expected to just make whatever we have work. I completely disagree with this approach, I think they want the benefits of scrum without the sacrifice it'll take to get there.
Our VP is obsessed with metrics and believes that anything can be tracked, and he also has insane expectations for a company that's extremely lean, we're practically starving for employees and yet he's expecting us to run marathons. So, we've got like 100 projects we have to deliver by the end of the year. As far as I'm concerned the scope, cost, and time has already been established, there's no room for error, any delay and we're already behind on our goals for the year. So, that puts so much pressure on the directors to just get anything out the door even if it's taped together.
We have over 800 stories sitting on backlogs that just keep piling up, and I had to really really work to get them to realize we can't just say yes to everything and we have to start prioritizing work and determine what's actually important and then focus on that, but it seems to be that we're still just trying to ram things down the pipe as fast as possible.
At this point I feel completely hog tied, I'm being held accountable for the success of teams that imo are doomed from the start.
I'm assuming management has heard of Pareto's Law - if not, perhaps they should look at some internal numbers (sales, customers, products, etc); though it's not going to show up exactly 80/20, they'd be surprised to see quite a few interesting patterns.
To how many products are those "100 projects" linked to? Per the above, I wouldn't be surprised 70% or more of these "projects" would have reduced priority/business value/whatever, compared to the the other 30%.
Furthermore, those "800 stories sitting on backlogs" need attention; they're not all important, and I bet at least 5-10% are already either obsolete or included in other ones (duplication).
As Ian mentioned, keep transparency as your north star.
Plus, if I were you, I'd generate a couple basic "reports" for managers to understand where you are vs. where you should be. How the org works vs. how you would suggest the org to work. Etc
Yes I'm aware of the Pareto Distribution. I've made things very transparent. I established a Sprint Report meeting every 2 weeks where the teams come together to talk about their cycle times / impediments and they've had 0 response from management. They practically ignored them for the first couple of months, and then finally started coming but they're still on their phones or laptops barely paying attention. I ask them to step in on some of these things and they tell me to be patient and just keep going.
I started a scrum score card report, but because I'm so detached from all the teams, I end up having to take the managers word on how the teams are doing, and of course, they're all doing amazing and just humming along every time there's a report lol. Teams don't even actually report their impediments to management, I have to dig and ask the dev teams why things aren't going well, and then they'll spend an hour unloading on me, but I take that to the directors and they tell me the dev's are just whining... /facepalm
We have a board meeting once a month where new work is approved and prioritized coming in to backlogs, they've finally agreed that stacking up stories constantly is just not helping. I've made a little progress, but it's incredibly hard to convince management that they're stand in their own way. I appreciate the feedback though.
I'm going to be totally honest and say it sounds like you are in a no win situation. Agile is only successful at a company if there is full appreciation of the purpose and principles. Agile/Scrum/Kanban/eXtreme Programming/etc won't make delivery faster. They will provide visibility, consistency, focus and, to some extent, predictability. But none of those things sound important to your VP and the rest of management.
One of the basic premises of all the Agile practices is a self-managed, self-organized team. You have none of those from what you have said. In fact, you don't even have real teams in most cases if they are constantly being formed/disbanded. You have a lot of talented individuals that work together from time to time.
Your responses indicate to me that you have a pretty solid grasp of Agile and are doing the best you can to affect change. As everyone has said, transparency is going to be your best weapon. Do everything you can to help them see how their actions are not helping and in fact making matters worse. Ask for evidence that 95 of those 100 stories are warranted or even needed by the stakeholders/users/customers. I would be willing to bet that a lot of those are things that someone thought would be a good idea but have done nothing to justify the value of doing them.
Another option for you is to do some investigation of metrics used by Lean and Kanban practitioners. Start measuring Through Put and Cycle Time on those 100 stories. Measure the age of stories in the backlog. Those things will help them understand that loading up stories in the backlog is not very useful. Lead a session with them to refine the backlog. Start with reviewing the oldest stories in the backlog first. As others pointed out, there is high chance that most of them will be determined to be unneeded or duplicated.
Transparency, transparency, transparency. Then take every chance you get to inspect and adapt. It won't be easy. But based on your responses you are doing the best you can. Take this as a personal opportunity to learn. Take time to do your own inspect, adapt loops in order to learn how you can course correct. This is a very valuable experience for you. It is unpleasant as hell, but is very valuable in the amount of information you will be able to learn.
Thanks, yeah, I actually enjoy having to deal with the challenge, I just wanted to make sure I was being accountable and not dropping the ball. :)
The fact that you are able to identify so many areas where Scrum and Agile in your company are being short-changed in the interest of maintaining the status quo is actually a testament to your Scrum Master ability.
Just about every Scrum Master has been in your situation. One thing that I've used to help my perspective on such dysfunction is referring to Craig Larman's 4 Laws of Organizational Behavior:
A few items stood out to me, that I'd like to highlight here:
"I'm being held accountable for the success of teams"
- As a Scrum Master, your primary responsibility is to ensure that Scrum is being adhered to, and making as visible as possible any and all instances where it is not being practiced. If your management wanted to have someone accountable for the successful delivery of everything that is on their "wish list", they probably need a project manager, not a Scrum Master
"Our VP is obsessed with metrics and believes that anything can be tracked"
- one of my favorite quotes is from Albert Einstein: "Not everything that counts can be counted, and not everything that can be counted counts."
"I am tasked with taking notes on these 2 teams daily scrums, and then emailing that up to the management."
- Stop taking notes. Educate management that the Daily Scrum is for the sole purpose and benefit of the Development Team. As long as you are effectively radiating information regarding sprint progress, and key stakeholders are invited to Daily Scrums with the understanding that they are flies on the wall, they have every capability to stay informed (without you wasting time composing a status report each day)
"So, we've got like 100 projects we have to deliver by the end of the year... We have over 800 stories sitting on backlogs that just keep piling up,"
- What evidence is your management using that tells them they are capable of delivering 100 projects a year? How quickly are your Scrum teams working through backlog items each sprint, and does that rate bode well for closing 800 items anytime soon?
I won't even get into the inherent (and ridiculous) difficulties trying to serve 7 Scrum teams at once, or dealing with consistent team roster shuffles.
What I will say is that I'm actually envious of your situation. This is an incredible opportunity for you to gain experience working as a Scrum Master in adverse conditions. Good luck to you, and keep us informed!
I completely understand your situation and have been in the same type of situation (but not as large).
How are things going? I would be interested in how your work has improved the company.
I agree with Daniel Wilhite, agile is not a magic wand that will make your delivery faster. It will show you all your problems/issues as early as possible so you can fix/improve them as early as possible.
I'm not going to add something new regarding above replies but my only advice is: try to learn as much as possible and help teams to deliver value, then consider if this company fit with your aspirations.