Development Team going rogue when work needs to be moving
Need some help to ensure that the project that I'm working on goes to plan, but unfortunately there are a few things that need to be brought back into line.
We're on the second sprint of a project, the first was a huge success and we managed to get a number of high-value things moved to 'done'. A few things couldn't be completed in the time allowed but that didn't stop a release and the things that didn't quite get to 'done' are going to be picked up as part of the next sprint. So, generally, pats on the back all round so far.
So... now we get things in place for the second sprint. There is still a lot left to cover, but the work when it's 'done' will be of huge value to the business. However, there are problems:
- One of the developers keeps trying to involve himself in absolutely everything. Stories that aren't assigned to him to pick up are being discussed with other people who aren't part of the project and changes keep popping up. This is only going to delay things because the work that is assigned to him isn't going to be picked up, and the person who has been assigned the work can't work on his side because he doesn't feel confident in getting started.
- The same developer is moving other stories that aren't in progress to the 'in progress' list which seems a misrepresentation of the project's progress, and I think we're rapidly going to lose sight of things and confuse the Product Owner when we get to the end of this sprint and the deliverables are minimal (yet they shouldn't be).
- The Product Owner has not been able to involve themselves as much as they'd like but before the start of this sprint, they'd been through everything and ranked the work in priority order. The decision has been made by the Development Team to ignore this however and they're focusing on quick-wins which pack the 'done' list by the end of the sprint (hopefully) but won't deliver what's important for the business. They haven't told the business this though however.
- The team seems very split at the moment and although all of the stories have been estimated and there's been an initial assignment of these, there are still meetings going on. The developer who I've referred to above seems to want to boost their own profile and review everything again and again (and again) and wants to act as a middle man between the other developers and the business. It's not needed - and wouldn't be efficient anyway. The more sensible approach would surely be for the developer in need of clarity from the business customer to speak with them directly, rather than this other developer, to avoid having mixed messages and things lost in translation. I was called into a meeting by this developer, who was running through things with his line manager (who isn't part of the project) but they were talking about all of the stories - why did this meeting go ahead when the sprint had already kicked off? why were the rest of the project team excluded? why could I not spend the time instead overcoming an issue with one of the high-value stories than discuss something that doesn't even need to be looked at in this sprint... or possibly the project?
I don't want to take over and direct things, it wouldn't be the best use of my time and wouldn't encourage the team to take responsibility for themselves (and selfishly it would likely see me blamed at the end of the sprint when there were few things actually delivered or, at least, more low-value work delivered than the high-value tasks).
How would you ensure this got back on track?
How would you get the project team back in place, and owning their own work?
How would you resolve the potential issue with the business / Product Owner to thank them for prioritising yet explaining that their priorities were being ignored?
Has the impact to the Sprint Goal due to the Product Owners availability been made transparent to him/her? In the absence of a Product Owner the team will have to do their best to achieve the Sprint Goal.
In relation to the Development Team, are they making their progress towards the Sprint Goal transparent during the Daily Scrum? The Development Team could then come up with a plan to help them get back on track or meet the Goal.
Sometimes, the Scrum Master should let the team fail a sprint and discuss in the retrospectives as to what made them fail? You could have "Scrum Values" as the theme of your Retro.
Somethings which I felt are worth discussing for this team's retro are
1) Is every development team member feeling empowered to do the right thing in collaboration with business if they are running into any issues or is there a "super hero" running the show? Because, remember? there are no roles in scrum.
2) Regarding your comment, "Stories that aren't assigned to him to pick up are being discussed with other people who aren't part of the project and changes keep popping up. "
- "I can do anything, but I can't do everything" - This needs to be explained to the developer
- "Stop starting and start finishing" - One of the qualities of a self-organized team member
- If we don't deliver- we fail as a team
3) Regarding your comment, "The same developer is moving other stories that aren't in progress to the 'in progress' list which seems a misrepresentation of the project's progress"
- I see an opportunity right after the DSU to quickly touchbase with the team to see if the story was put in the right bucket or was it by mistake?
4) About your question, "How would you get the project team back in place, and owning their own work?"
-Whatever is making the scrum team spend time understanding the user stories during the sprint needs to be inspected.
I feel the scrum master must make sure that team is on track during daily stand up calls. If something is not working, scrum master has to take responsibility of fixing it.
if a team member is going out of his way to get the work done, then it’s fine. But if it is impacting other team members work, then that person has to be individually coached on agile values - honesty, openness, focus.
re-iterate sprint goals and make sure tasks are getting completed before picking new ones other wise they need to justify, unless there is a strong reason from business or PO.
Also, we can set some ground rules for the team’s behavior and get them agreed upon.
we cannot inform the product owner about the team, because it’s not his responsibility to see who is doing what.
I feel scrum master has to take complete responsibility to remove impediments for the team.
I feel the scrum master must make sure that team is on track during daily stand up calls. If something is not working, scrum master has to take responsibility of fixing it.
I do not agree, I think the SM should coach the team to inspect if they are on track, and coach them to adapt where needed. it is not the responsibility of the SM to fix anything within the control scope of the team. Only impediments, outside the control of the team should be handled by the SM. If the SM is a "fix-it-all" goto person, teams will never learn to fix things themselves.
we cannot inform the product owner about the team
you can always inform! This adds to the scrum concepts of Transparency and Openness
@ Jim W
In general, having a superhero on the team can disrupt things a lot. In the end, it is for the SM to bring this problem to the surface at team level and not for the SM to fix him/herself.
my advice would be: gather the whole team and address the situation. make sure everyone gets their say.
Start the conversation by stating what you observe (factual) and what the scrum concepts under possible violation are.
"I observe person X changing progress of stories " + "transparency of progress for team and PO means... and can be become a problem if..." + "how do you see this as a team?"
or...
"I observe a lot of reviewing being done. The Definition of Done does not address this, should this reviewing be added to the DoD or is the reviewing overdone, how do you feel about this as a team?"
Make the team aware, and help them speak up