Coaching Self-Organization to Dev Team and Product Owner
Hi everybody,
I've just joined a Team as Scrum Master to help them with their transition to agile.
The Product Owner is also formally the Team Lead, since the company is not agile, he still has that job title. The Dev-Team has the habit of asking permission from him, whenever a technical decision must be made. Especially if there are some different opinions on how things should be executed, they tend to run to him so that he would have the last word. In those cases I have the feeling that there is no consent to the decision, team members just try to sell their opinion to the PO and have the "I told you so" attitude when the PO agrees with them. PO has his standard line: try to solve it between yourself, come to me when it doesn't work out. But the second thing usually happens.
There is still a lot of misconception about Scrum in the Team, like PO should assign the work, PO is responsible to control Dev-Team work, cross functional means no specialist on the team etc. I try to clarify right away when I hear such statements, but I don't think the team got the idea behind the agility yet.
They are also not familiar with the coaching concept. I offered my coaching services as I joined the team, offered some team members to talk more about a misconception they had. But always got the answer like "I have work to be done, I'll approach you later", "Your clarification is enough for now, I'll get to you if I had more question". How do you get the team to proactively approach you for coaching or training? The team had history of developing a product for 5 years, which turn out to be too complex and didn't met customer's need, so they know why they need to change. But I haven't seen their motivation to really do it yet.
Thanks for reading and any advice is appreciated!
Tra
Hello Tra,
Did you create any working agreement with the Dev Team and the Product Owner?
Who mandate you to be the Scrum Master and is your mandate clear to all, especially in term of goals and means?
How effectively is the team refining the Product Backlog in collaboration with the Product Owner? Is work truly being refined to a state that is "ready" for Sprint Planning? If so, why are the team then unable to progress that work by themselves?
As an Agile Coach in the Financial Services industry, I coach teams and junior coaches as well.
What I've found works well is to avoid what I just said (e.g., "What I've found..."). This is consultant-speak and IMHO it doesn't play well as a coach.
Instead, I've focused on growing Trust as the #1 way to get teams to accept me. By that, I give 2 answers to most questions and explain the rationale for each.
For example, teams will semi-often ask why they need to story point.
I tell them it's not a mandate, but here's a good reason to do story pointing: your work items are not fairly uniformly the same in terms of time estimate; however, if you do find your tasks have a very low standard deviation in terms of time, then it's fine to count each as "1" and get your throughput in terms of work items, or your Kanban WIP limit to a number of work items instead of points.
Very experienced Scrum Masters do tend to approach coaches for these types of questions.
Additionally, I usually work with very senior people at these banks. I let them know what, if Scrum is in play, that several "items" need to be in place before teams should be sprinting: team norms, DoD, DoR, Backlog refinement, JIRA tooling, a good DevOps pipeline with automation, Business Value explained down to KPIs that the Product Owner can measure, team rosters without conflict of interest, etc. Some places call this "Sprint 0" but it's basically a starting point.
Did you create any working agreement with the Dev Team and the Product Owner?
Who mandate you to be the Scrum Master and is your mandate clear to all, especially in term of goals and means?
We got a team norm and DoD only. But a more detailed working agreement might be a good idea. Thanks!
As I mentioned the team had a history of developing an irrelevant product for 5 years. So PO wanted to avoid this situation, the team gave consent, so I was hired. The goal is quite clear for the whole team: to be flexible and able to adapt to changing needs. We decided (me and PO) to start with introducing the scrum practices and a basic Scrum training. After that it should be kinda training on the job - whenever the team has some question, they would ask. But I barely get any question.
How effectively is the team refining the Product Backlog in collaboration with the Product Owner? Is work truly being refined to a state that is "ready" for Sprint Planning? If so, why are the team then unable to progress that work by themselves?
My question is than how detailed should Refinement be? In our refinement the Product Owner comes with an story, clarifies what he wants in the story until the Dev Team understands it. But during the Sprint the Dev Team come up with questions like if they should modify an existing process or build a new one... which I think isn't a question for Product Owner to answer, no matter if these questions come up in refinement or during the sprint. I guess the Team still has this feeling of hierarchy and the Product Owner as Team Lead should decide things.
Instead, I've focused on growing Trust as the #1 way to get teams to accept me. By that, I give 2 answers to most questions and explain the rationale for each.
Thanks Marc, Trust is what I'm working hard on. It is quite challenging for me in remote team.
In my opinion, the only way Agile can be successful is if the leadership, preferably C-suite, make it clear that the organization will be transforming. Has this happened? If not, they're going to see you as an "optional." Agile has to be a top-down transformation. People do as their leaders.
Is your organization committed to Scrum, or are they looking into another framework? I introduced Scrum to a team and I didn't waste their time with complexity. I trained them on Scrum and we adapted to Scrum Events and expectations. Emergence. I also resisted story points, t-shirt sizes, or anything of that nature. I had the support of leadership and I kept things simple. I had to wear other hats from time to time but I trained them and mentored them as needed. I did not however coach them, and I don't think that IT organizations should bring in "Agile Coaches." Coaching is a specialized skill and most "Agile Coaches" are just trainers. Coaching should be left to specialists who are brought in by HR, not by IT or a Center of Excellence.
All of these are my opinions based on my experiences. These may not apply to others.
My question is than how detailed should Refinement be?
Refinement never ends. Teams will refine details up to the very end of their work on the item. However, there is a point at which you have to say the item is understood enough to be able to start work. That is the point for which you strive. The following is from the Scrum Guide's section that describes Sprint Planning.
By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.
So your pre-planning refinement activities need to lead to the point where the Development Team feels that they can start work and explain how they intend to do so. Your statement of "do we build new or modify" should be answered by the end of Sprint Planning.