Dev Team not improving
Hi
We have a context with a former Project Manager, with little agility background but nice mind-set, eager to trust the dev team (no micro-management). She has to deal with a difficult context and I'm looking for your point of view.
We lack some developpers for her new product so we call for contractors and we ask for developpers with some agile background. So the developpers were more or less "selling" scrum in their own way to the new Scrum Master.
The developpers, as often, like coding tasks and hate meeting and testing and everything else.
They quickly ask for a tester in the team. I warn the Scrum Master that they were trying to get rid of the testing tasks, but she wanted to tackle the impediment and she added a tester to the dev team. You can easily guess the sequels...
The developpers perform less and less unit-testing ; the tester is very alone ; they are building more and more technical debt ; they are not respecting their own DOD (some US are rejected during the sprint review because of poor quality) ; they are not taking account for the action they voted themself during the retrospective.
They are not playing the game of continous improvement and transparency.
With other agile-minded people, we try to help the Scrum Master with some possible tactics, but I wonder how you would react in such a bad context.
Hi Olivier,
this situation calls for the Scrum Master. She has to coach the team to get more commitment for improvements they decided and for the DoD. And she has to help them find ways to detect quality problems much earlier than in the Review.
One example could be to add to the DoD a minimum test coverage. When a developer wants to move a story to "Done", she can ask him if the test coverage is reached. If not, he cannot move it to done. Sounds like command and control, but teams in "shu" need this guidance. I have tried it and it worked. My team sticks to the DoD now without my help.
If the Scrum Master is not able to do that, she needs coaching herself. Try to find a Mentor.
Good Luck!
Thanks for you guidance.
Your saying about the "shu-ha-ri" is especially well suited for the situation.
Very often, people in the "shu" level consider themselves to be in the "ha" level ! So true for this situation :-(
You are welcome, glad to be of any help.
Another model to describe your team is the Formin-Storming-Norming-Performing. From the information you provide, I would place your team at Storming. This would support the need for special guidance by the Scrum Master to get into Norming. Clear rules might help here.
There is an excellent book about this subject: The Five Dysfunctions of a Team by Patrick M. Lencioni.
Basically, you need to start with building trust in order to get commitment and finally reach your goals.
I wonder if they are not still at the "forming" stage.
Their goals (for themselves ; for the project ; for their company) don't seem very clear to all and because of this lack of transparency, their goals can't be well align and the team can't gell.
Thanks for the link to Lencioni book's ;-)
Maybe. It is hard to make a diagnose from remote ;-) and the phases are not necessarily disjoint.
But the symptoms you describe such as conflicts between different interpretations of SCRUM or people looking for their roles within the team are typical for Storming.
> ... they are building more and more technical debt ; they are not respecting their own DOD...
Bear in mind that technical debt is incurred by the product and is therefore of concern to the Product Owner. Also, the Definition of Done is the property of the Scrum Team and not just the Development Team, as the PO also has a say in the qualities that define and underpin a potentially shippable increment.
What, then, does the PO have to say about this situation? It sounds as though the Development Team have more or less been given carte blanche about the quality of the deliverables, and that product ownership is correspondingly weak.