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? Saving Changes...
Does the team hold sprint reviews? Surely the PO can use that opportunity to feedback about the fact that the priorities were ignored. The PO should attend future sprint planning meetings to re-prioritise where necessary and to make sure the team is picking up the right backlog items.
What about sprint retrospectives? That ought to be the occasion to discuss the behaviour and interactions of team members.
You said some other things that may be relevant. When you speak about stories being "assigned" to team members, who is doing the assigning and why? Some teams operate a system where team members can pick any item off the sprint backlog if they have bandwidth. Other teams will perhaps tag items for particular people during sprint planning. No one but the team themselves ought to be assigning work to anyone and the team should agree their own protocol for doing so.
When you say all the stories are assigned and estimated, do you mean just for this sprint or for the entire product backlog? Assigning an entire backlog sounds like a cause for concern if it implies that the PO isn't expected to change priorities or add new stories.
If the PO values the work being done then the PO needs to take control, attend the ceremonies and set direction. Maybe a quiet word with them could make that happen. Alternatively, if the PO isn't interested enough in the backlog then perhaps it really is the wrong set of priorities to start with. Saving Changes...
Lots and lots of "danger" signs in your story including assignment of work items (vs. pulling of those), lack of involvement of a PO, lack of team-behavior (developer working solo).
Would suggest this looks like "Dark Scrum" or "doing" agile rather than "being" agile.
Has everyone involved in the project gone through some agile fundamentals training focusing on the mindset/behavior required (more than the ceremonies/practices/tools/frameworks)?
This is where an experienced agile coach (external) can usually help...
Kiron Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
As I was reading, noticed many anti-patterns, such as the assignment of stories and lack of some fundamentals, as Kiron and David mentioned.
Is there an Agile Coach involved to help solidify and advocate some of the types of behaviors and patterns expected?
Also, a change in approach will take time. The behaviors witnessed early on won't (hopefully) for long. There is mindset shift and adjustment period needed. During this time different needs and coaching opportunities are realized, then through 1:1's or team activities, touched on and worked through to help get to the next steps of the journey. Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
The one thing we have all come across and been part of is some attempt to fix a project. It is sort of the norm. The really scary part though is that there is this fallacy that we can rescue an ailing/failing project on the go. Things are horribly wrong, deadlines are being missed, we are weeks behind schedule and delivering crap. Then we have this Ephiny that we can resolve all of this while we keep going, or some times going faster to recoup lost time.
Rescuing a project comes with pain but the pain is less than you experience when the project fails completely.
Most project managers response, or Scrum Masters, would be to call this person into a meeting and put them in their place by clearly defining were they sit on the project team and what is and is not expected of them from this sprint/project.
I would be against this approach and see enthusiasm, even if it is misdirected, as something that should be encouraged and managed properly as these kind of individuals turn out to be the best workers in a project.
It sounds like this person could be on the Autism Spectrum as they are displaying characteristics that would be typical amongsts people who have autisim. Autism is a what some would call a disorder and it covers a multitude of inter social issues that effects people of every age.
If this is the case, and the person in question may not even beware of it themselves I would approach the situation in a more empathic and understanding manner.
A little work with such individuals can produce great rewards so thought and insight is your best approach in this manner.
