Submitted by MsSunshine on
One of my directs reluctantly volunteered to moderate a meeting I think is going to be contentious. I'm not sure the direct is ready for this. But now that she volunteered I feel I should coach her quickly on doing this and support her. I will be at the meeting. So...if things go badly...do I step in...and how?
My thought is to coach her on running the meeting and not step in unless they get to the point where they are just repeating arguments. Then I would simply ask if we are making progress and what it would take for each person to change their opinion.
We've just started doing Scrum. The scrum master is going to be away on vacation and there is a second try at a planning meeting happening. I volunteered to run the meeting but one team member felt strongly it should be one of the team members. (I'm the manager and was told that technically I am not a team member because I don't do any tasks and am not the scrum master.) I said that was fine. The team member that expressed this said he wouldn't do it. After a few minutes, another team member said she would. I asked if she was sure and she said yes. The rest of the team said they were fine.
Now, the original planning meeting was 2 hours of arguing between one side asking for a date with a set of features and the other saying that was impossible. I was told I was "a chicken" at this meeting and could not speak. After 2 hours, I finally said that they needed to figure out what each needed to get to an answer because restating the same point over and over was a waste of time. (Note that the Scrum Master was there but isn't really good at handling this situation.) They all agreed to do a few things and come back in a few days.
My direct has never moderated anything. I am going to do a quick coaching on that. She's not a really assertive person. But I do believe learning to moderate is a good skill and this could be a good learning situation. I am also going to tell the rest of the team in their 03's that they are all responsible for reaching an agreement - not just the person moderating.
I will still be "a chicken" at this second meeting. So, technically, I'm not supposed to say anything. However, I do not want to just let her swing in the wind either! But I do want to give her the chance to make mistakes, learn from them, earn respect from the team, etc. But there are some very strong personalities and the last meeting had everyone calling me in frustration afterward to do something.
So....at what point do I step in and how do I do it? I keep being told Scrum is "self managing"...but everyone needs to learn how to do that first! I'm told by the team that I can't talk but then told by all parties to do something about the other parties.
Not supposed to say anything...
If you are not to say anything, then don't.
Part of developing the people on your team involves *reinforcing* their roles in meetings. You are taking perfectly valid steps to provide coaching in advance of the meeting, yet, when the time comes let your direct be the moderator. It may not be as smooth as you envisioned but that is part of the experience.
Leadership roles in task oriented discussions often evolve quickly. As manager you can chime in when you see an opportunity to enhance your direct's role as moderator. Ask a question or redirect comments to the moderator as needed if there is a breakdown. Do not take on the moderator role yourself. It is subtle but the group will soon identify your direct's leadership role in the meeting.
Not A Lot You Can Do
I wouldn't call what you were doing is coaching, but that's for another day. I would say it wouldn't hurt to encourage her to meet with some or all of the attendees individually in advance, and get a sense of things, perhaps mend fences in advance.
I don't think I'd step in unless someone violates the norms of the FIRM. They seem to not respect your scrum knowledge, fine, so you can't do much there. But if someone does something unprofessional, I would step in. It's still at your firm, and if you're uncomfortable with what's happening, DO step in.
On the other hand, your direct volunteered, and as long as she can't be forced to DECIDE between the two (facilitators don't decide), then it's time for her to learn by doing.
She might do fine!
Good judgment comes from experience, and experience comes from bad judgment.
"Good judgment..." That's a great line. Can I quote you Mark?
I've been fortunate to have had managers who gave me freedom to fail when I made good faith efforts. Some of my greatest learning experiences have come from some of my greatest failures.
...but you can credit Will Rogers, who said it long before I did. ;-)
Thanks for the suggestions
I agree it's more like a quick tutorial on moderating a meeting - coaching wasn't the right term. I can easily run through the role and do some "what will do do when" scenario playing so she'll be prepared. I think I'll tell her that I'll let her run with it and not step in unless she explicitly asks or I see some unprofessional behavior.
Unfortunately, she also does need to be a participant in the discussion as well as the moderator. Her opinion on what they can do is important. That is why I originally said I would be the moderator. But I'll talk to her about playing the dual role.
The whole team, including myself, has only been doing scrum for 2 months. So, we're all trying to figure out roles and new ways of solving problems. In the old system, the leads would have gotten in a room and worked it out. That probably was a bad thing since it left the team out while they were doing the work. I am optimistic that the direct and team will rise above this ... and be better for it. I'm working with them on assessing risk and learning to be comfortable with some risk for business objectives. In the past (under different VP, Directors, Managers), they had experiences where they took agreed upon risks and were criticized when the risks materialized. So, there is some building of trust that the new management will not do that. I'm trying to encourage them to try it one more time. Building trust is a huge part of my job right now.
My lack of confidence in how to do things probably isn't helping! I to try to be honest with the team when I don't know what we should do in scrum to handle something. Then I promise to get the answer from teams who have done this before and that we can work it out. A few of them are uncomfortable with this - expecting me to have all the answers and solve all the problems! :^) But it's probably good that the see I don't and have to get personally involved in the solution. (The old management system was very hierarchical where things were more regimented and problems solved by upper managers in private meetings. When things didn't work it was ugly and the team felt no responsibility.)
MSSUNSHINE, self management
self management doesn't mean that everyone can do what he wants. In SCRUM, as in any Agile methodology, there is a strong discipline in those which are the key practices: for a certain extent the most you are agile, the most you are disciplined even if it sounds self-contradictory.
In Agile contexts usually people are more 'empowered' by management and are more willing to grow but ... self management doesn't mean that, as a magic, everything just works: (strong) skills are needed! And the level of self management grows with the maturity of the team.
From your story, the relationship between your team and (what I assume it is) the Product Owner is still not well consolidated: I think you need a more experienced (on SCRUM) person to run the Scrum Meeting.
In any case I'd ask the team to make a quick Retrospective and ask them how they feel with the previous iteration ... (this is what probably your SCRUM must would do). If it's just a 1 week iteration, as I get from your post, it's not a big damage anyway.
My 2€ cents,
In case you don't know...
PierG is a friend of Mike and I's, and quite well known in Scrum and Agile circles. Attention must be paid.
I always have heard that quote attributed to Will Rogers. 'Good judgment comes from experience, most of which comes from bad judgment.'
Didn't I just say that?
Thanks nonetheless. :-)
We've got lots of issues...thanks for the retro reminder
The team has lots of trust issues based on previous things between Product Management and Engineering. Scrum obviously doesn't solve them but others as well as mysefl are trying to build back bonds. It's hard to get rid of all the damages years of bad behaviors resulted in. So, I'm taking it one step at a time and working it through.
I hadn't thought about the retrospective We are actually doing 2 week sprints. But the planning meeting fell apart as I said. The scrum master decided to make this a 4 week sprint and have them do 1 week of research at the start. This meeting is to decide what we can actually do in the sprint. I would have thought that we'd just not start the sprint until after this meeting...but as I said I'm not the scrum master and didn't get to comment or vote on that. Maybe this will work as well. If it doesn't, that's another lesson learned. We've only been doing Scrum for 3 sprints now (6 weeks). So, we're all really new to this and feeling our way. So, the scrum way seems to be to let them try this, learn and assess at the retrospective.
Thanks for all the comments on letting them learn from experience. I know I tend towards over-functioning - which is why I originally asked when I should step in. I'm working hard to find the line between letting them learn from their own experiences and my not getting in trouble for not getting product out! We may be doing scrum and I'm not a voting member of the team but I've been given clear goals that have me on the line for meeting deadlines!
Unfortunately, we don't have anyone with a lot of scrum experience. A few groups have been doing it for 6-8 months but any skill takes longer than that to master. I suggested bringing in a scrum master from another team to moderate this and some of the team was adamant against it.
As an aside, if anyone has good references, blogs, etc. on the role of the manager - not the scrum master - in scrum. I'd love to see them. Everyone I ask gives me books or links that are really the scrum master's role.
Well, it's all well and good
Well, it's all well and good that you're letting the team do their own thing. It's good that you are letting them struggle and learn this new way of working together.
AND you're still the one responsible for shipping the product, right?
You can still give feedback after the meeting... about dynamics that you saw that could have been improved, for example.