When do you coach you team?
Hi all,
I need some input on the best time to coach the team. What I should address directly and what, if anything, I should wait with and let the team figure our themselves.
For example,
A story that does not meet the DoD is accepted by the PO.
Team decides to demo stuff that is not done in sprint review
During standups it's clear that some tasks drag on for days without much progress, noone in the team asks why
Would you step in right away and coach/train the team or wait until later?
thanks
Fredrik
Good questions, Fredrik.
What is the Scrum Maturity of the team? The org? The coach?
What is the org's tolerance for change? The team's?
Is your only role on the team as Scrum Coach, or do you wear many hats? Is it the only team you're coaching at the moment? How long have you been coaching them?
It's very hard to try and give good advice on your question "over the internet," without the full context to go on. We can try, but I suggest you hook us up with more context!
Hi Charles,
Some context.
One team that has been using Scrum for about a year and I have acted as the SM for all that time. No dedicated scrum coach has ever been brought in. Entire organisation has been to Scrum training. Most team members been working together for many years. Big tolerance for change I would say. I act as both dev. manager and scrum master and occasionally as a team member, which is not ideal.
Scrum master's role is to ensure that team follows the Scrum process and one of the critical attribute of process is transparency. At-least for the first two items (DoD and undone work in sprint review) are candidate for transparency issue. As a scrum master you should ask the team that "Did we meet the DoD, is everyone agree on it Or do you guys want to change the DoD". Re: the 3rd item on dragging off of tasks, you can wait for some more time, there will be some undone work at the end of sprint and then you should coach/ask team on what could have been done better to avoid the undone work.
In both cases your role is to initiate and facilitate the discussion, team has to discuss and come out with the decision.
Also your organization has gone thru the Scrum training about one year back so this may be time to get refresh their Scrum knowledge
Going by scrum first objective - inspect and adapt - I would say SM didn't play appropriately on either of the examples.
DoD defined and PO accepted though it didn't meet all criteria - so either DoD was not proper or PO is biased. So knowledge should be provided more on clear DoD definition(tangible ones) and PO to accept only when all met.
If one use case is done then only team should go for demo during review - otherwise t would bring in more questions from the attendee on the expectations/requirements.
Some task is not being done and getting dragged for days - it should have been reported during daily scrum and SM should have picked that up and would have taken necessary steps to "remove the imp endings".
I would say we should try to follow the rules at the best possible way when we practice scrum, however in real life its very difficult. It goes back to the same - SRUM rule is easy to understand but very hard to practice.
Fredrik,
Thanks for the extra context. I will try to help, but remember, this is like doing surgery over the phone -- a bit dangerous.
Would you step in right away and coach/train the team or wait until later?
A story that does not meet the DoD is accepted by the PO.
Team decides to demo stuff that is not done in sprint review
During standups it's clear that some tasks drag on for days without much progress, noone in the team asks why
The first thing I usually consider is: What should my coaching stance be? See more on that here: http://www.agilecoachinginstitute.com/wp-content/uploads/2011/08/Agile-…
What level is this team at? Shu, Ha, or Ri? (You can google that for more context)
If they are at Shu, then I might act a little stronger(Teaching, Mentoring stance) to ensure Scrum is followed. If they are at Ha or Ri, then I'm going to take a very laid back approach(Coaching/Facilitating stance) towards coaching the team into better decisions -- usually by asking powerful and socratic questions.
The next thing that I like to consider is "What the is the team's/org's sustainable pace in terms of accepting and adapting to change in their scrum implementation?" Then, if there are multiple challenges, I mentally or physically make a list, ordering from highest ROI to lowest ROI (value in terms of advantage to the company, over the political and real investment of effecting the change). Think of it as a "Scrum Master's" (or Coach's) backlog. You will also notice, as SM, that the Scrum Team probably has it's own "list" of things it things to be done. Anytime you can get synnergy between something on the SM list and the Scrum Team list, then that should immediately and dramatically increase the ROI of enacting that change. When in doubt, let the Scrum team try to remove that challenge themselves. You can help and facilitate, but let them try first.
I also consider strongly what will happen if I try ensure that Scrum and principles are followed, and whether team members might try to "go over my head" in order to not have to follow Scrum. I will often share the top 2-3 things on my "coach's" backlog with the person who is likely to be contacted by team members, and try to make sure that this person will back me up. I don't want to get fired for trying to do the right thing!
Keeping all of that in mind, it's time to ensure that Scrum is followed, albeit in a "servant leader" way. There might be a fair amount of resistance because it sounds like you, as the Scrum Master, have not been ensuring that Scrum is being followed for up to a year. As such, it may be wise to take a slow and cautious approach, maybe tackling one item at a time.
As an aside, when a person of authority is playing a Scrum role, or someone is playing more than one role, I always counsel them to make a lot of clarifying statements like "As the Scrum Master, my view is xxx" and/or "If I put my Dev Manager hat on, I think yyy" and/or "Speaking as a Dev Team member, I feel like we should zzz" I encourage those people to play those roles clearly. So, for instance, you might exert authority as a Dev Manager, but you should almost never exert authority as a SM -- because the SM is a servant leader. Hopefully you're also a servant leader Dev Manager, but you may be in an environment where that is not possible.
So, with my extra context, I ask you...
a) What do you think is the Scrum challenge that is happening on the team that has the biggest ROI right now?
b) How do you think you should approach that first challenge?
c) What do you think the Scrum Team would say is the biggest ROI Scrum(or non-Scrum) challenge right now? Have you asked them something like that?
Charles,
Thanks for your reply, I find your tips very valuable.
The questions is really when I as a SM should step in. When to wait for the team to figure things out themselves as a self-organizing, self-managing team and when to step in directly. Often I feel that the "do nothing" approach work the best. When the team can figure things out themselves that usually leads to more long lasting improvements compared to when I step in and direct the team. My examples are fictitious but still relevant I think. For example, during the standup I should not be required to participate (as the SM) but the team should be able to hold these meetings themselves.
Hi Fredrik
As an SM you can't tell a team how to do their job. Your role is to make sure the Scrum process is understood and applied, to facilitate Scrum events, and to remove as many impediments as possible. It isn't the SM's job to direct a team operationally.
However, the examples you give are all impediments to the Scrum process being followed, so if I was you I'd step in. My line of tack would be "this is the problem...so then team, what do you think you should do about it?"
However, the examples you give are all impediments to the Scrum process being followed, so if I was you I'd step in. My line of tack would be "this is the problem...so then team, what do you think you should do about it?"
++1! Agreed!
Also some related answers to these kinds of questions here:
http://www.scrum.org/Forums/aft/326