Coaching as Facilitator with Focus and Placement

20 March 2014


In this article I explore the ScrumMaster's role as a facilitator serving the team in Scrum events, meetings, workshops, and informal conversations, using the Choose Your Focus coaching model (Rock 2007) and my "placement" skills. The main message I would like to give is that the ScrumMaster can mix facilitation skills with coaching ones.

The ScrumMaster facilitates by creating a "container" for the team to fill with their ideas and improvements. The container can hold questions, an agenda, or some other flexible structure, giving the team just enough of a frame to stay on purpose. It also promotes an environment for richer interactions, a place where ideas can be heard. And it keeps the "Why are we having this meeting, anyway?" question in mind (Adkins 2010).

Facilitate the Daily Scrum

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision making, and improve the development team's level of knowledge. This is a key inspect-and-adapt meeting (Scrum Guide 2013).

To organize themselves for the day's work ahead, team members answer three direct questions:
  • What did I do yesterday that helped the development team meet the sprint goal?
  • What will I do today to help the development team meet the sprint goal?
  • Do I see any impediment that prevents me or the development team from meeting the sprint goal?
This simple and powerful formula invites each team member to devise a daily work plan, get help clearing barriers, and make a commitment to the team.

As a ScrumMaster's guiding principle, intervene as little as possible during the Daily Scrum unless you are teaching or reaffirming how the Daily Scrum works. You'll intervene more with a new team at the beginning, while they're learning to adhere to the Daily Scrum rules.

Offer observations afterward. Ask the team, "May I offer you some observations about the Daily Scrum?" If they say, "No," then let it drop. If they say, "Yes," then deliver your observations succinctly, without judgment, and with a sense of curiosity that will invite their introspection. If a conversation happens and they figure out how to hold better Daily Scrums next time, that's great. If conversation doesn't happen, that's acceptable, too.

During the sprint, the team's job is to sprint. Therefore, if they don't incorporate a change from having heard your observation, don't force it. Doing so may create additional inspect-and-adapt cycles. These cycles could be beneficial if completed in a few minutes' time, but they could be detrimental if they drag on or raise so much dust that the team can't see their way clear to continue the work of the sprint. So leave minor infractions for the retrospective.

It is common for people moving to Scrum to be unable to recognize an impediment in the first place; this is due to the set of constraints these people have been used to working within. Habits are really hard to change, and here is where the good ScrumMaster, thinking outside the box, can start inspecting and checking on a daily basis about what is slowing down the team.

If you ask the question, "Do you have any new impediment to report?" and the team member answers, "No. . . ," then:
  • Make sure she is on time with the committed task (a delay may hide an impediment).
  • Make sure she has not committed to more than two tasks at the same time (she is probably blocked, waiting for someone else -- maybe someone outside the team -- to complete a task).
  • Make sure she is reporting with detail and specificity what she achieved since the last meeting.
  • Make sure she has trustworthy body language and a trusted position in the team's eyes.
  • Think about whether the way the team has chosen to accomplish the sprint objectives is the fastest and most straightforward way, and eventually stimulate them to think outside the box and inspect and adapt.
What happens if you intervene and the team still doesn't fix the Daily Scrum?

Remember, the accomplishments and bumps are theirs, not yours. Scrum works when they learn how to rely on one another. It has nothing to do with you looking good as a ScrumMaster. So if they do not improve, accept it for now and instead gear up for ways to create the space for them to bring it up in the retrospective.

Remember that one-on-one coaching is always an option available to you, especially when a wrong behavior you observe is not localized and the whole team would not benefit from addressing it.

Facilitate sprint planning

Sprint planning requires a very light touch in facilitation, even in the beginning.

The ScrumMaster has two main jobs when preparing for sprint planning: Prepare a structure (the event "container") together and that ensure the product owner has prepared and refined the product backlog for the sprint planning.

If you offer teams a structure they can use to conduct the mechanics of sprint planning, they can typically do it on their own. A set of agenda questions or the list of things you are trying to achieve with sprint planning works well as a structure. Whatever structure you use to guide the team, ensure that it supports the purpose of sprint planning.

The second job requires the product owner's engagement and hard work. Often, the product owner works with the team to refine the backlog, which includes the team's estimate of effort for every item. This can happen throughout the sprint or in a meeting a few days prior to sprint planning. In his book Agile Product Management with Scrum: Creating Products That Customers Love, Roman Pichler offers direct advice to product owners on how and when to prepare the product backlog and get ready for sprint planning, as well as ways to make the work happen in collaboration with the team. The acronym DEEP acts as a memory jogger so you can be sure that a well-refined product backlog has four qualities: It is detailed appropriately, estimated, emergent, and prioritized, making it DEEP (Pichler 2010).

In sprint planning, as ScrumMaster you can use teachable moments about the product backlog items that the team has just taken into the sprint. So, teachable moments about user stories will certainly come up: What makes a user story good? How do we create them? Why are they so long-winded? Who is a real user? These questions, and many more like them, are common. Mike Cohn has written two must-have books on the subject: User Stories Applied: For Agile Software Development (2004) and Agile Estimating and Planning (2005).

Facilitate the retrospective

The ScrumMaster plays a starring (facilitator) role in the retrospective, especially for a new team. Since the ScrumMaster focuses on being the guardian of quality and performance for the team, the coach pays keen attention throughout the sprint (Adkins 2010).

There are many skills a ScrumMaster can apply with great effect for retrospectives. I encourage you to do your own research and find the tools that will help you the most. I have specifically steered away from many retrospective techniques in this article, because so much good material already exists on that subject.

As ScrumMaster I do not only facilitate Scrum events; many times I'm requested for facilitating meetings, workshops, or informal conversations, where the structures may be not as well defined as Scrum events.

All of these conversations serve up opportunities to observe and coach. What are you coaching for? You're looking for the quality of the conversation, not the content. The quality of conversations matters.

When the team converses, don't join in and act as a team member. There are already enough team members. Be a coach instead. Help them improve their conversations so that they can come up with higher-quality ideas that translate directly to productive solutions.

I have experimented many times with the Choose Your Focus model, with its five levels, combined with my "placement" skill. It's a useful combination for helping to identify the type of thinking we are doing at any moment, and it provides an opportunity to then choose where to put our focus.

The five levels are:

1. Vision: Vision thinking is all about the "why" or "what." It's about the ultimate big picture. For instance: Why are we having this meeting? What are we trying to achieve? What's our goal?

Having a clear vision is about knowing what your goal or objective is, in any conversation or meeting you are facilitating as ScrumMaster.

2. Planning: Planning thinking is about how you are going to get to your vision. There are no details yet. I have found that most people (including myself) tend to move straight back into the details, problems, and drama.

Effective communication is all about awareness. It's simple, but it takes a lot of practice. Once you are aware of this model, it's actually quite easy to get out of the habit of focusing on the details, problems, and drama.

Putting good planning in place, without worrying about the details, is an excellent way for ensuring the success of any idea.

3. Detail: Detail thinking is simply that -- the detail of doing. Very necessary in any process, but it is a bit like quicksand. You can easily get lost or stuck in it.

So whenever you feel any conversation is going nowhere, or that it's going in circles, ask the following questions: "What's our focus? How can we get back to the planning and vision phase? What did we want to achieve with this conversation/meeting/event?"

As I have mentioned, details are crucial in effective communication. The only challenge is that you will get lost quite easily if you are not aware.

4. Problem: Problem thinking is where things go wrong. Once you get lost in the details, it can easily lead you straight to the problem focus if you are not aware. Unfortunately, problems are a common experience for many people . . . because there are lots of them.

Avoiding a problem-focused attitude doesn't mean that you don't solve problems. To the contrary, you can still solve problems, coming from a vision and planning focus.

Asking questions like, "Who did this?" and "Why did you do it?" takes you straight into the details, problems, and drama. However, questions like, "What do we want to achieve here?" and "What's the best or quickest way to fix this?" look at the problem from a vision and planning point of view . . . the focus is on solutions.

5. Drama: Drama thinking is where everything else is falling apart and the only thing left is the emotional charge. Once you get to this stage in any conversation, you are way past the point of having effective communication.

If you can't get yourselves back to the vision and planning part, it is best to take a break and continue the conversation when the drama and emotions have faded away.

Without lots of placement when facilitating meetings and events, conversations can go all over the place. Through the use of placement, meetings can be substantially more effective and you can complete them in less time than they normally take.

Placement takes care of the "why, when, how, and who" of the conversation. Placement is something you can use to guide a complex conversation and keep it on track.

Conclusion

Whenever you engage with more than one person, I suggest experimenting the Choose Your Focus model, combining with placement skills. Whenever anyone feels that the communication is stuck or going in circles, you can stop the process and ask everyone to refocus their energy.

In the end, effective communication is all about awareness, and the Choose Your Focus model goes a long way in helping you to be more aware.

In this article, the main message I would like to leave as a takeaway is that the ScrumMaster can mix facilitation skills with coaching ones.

References and suggested resources

Adkins L. Coaching Agile Teams. 2010. Boston: Addison-Wesley.

Cohn M. User Stories Applied: For Agile Software Development. 2004. Boston: Addison-Wesley.

Cohn M. Agile Estimating and Planning. 2005. New Jersey: Prentice Hall.

Pichler R. Agile Product Management with Scrum: Creating Products That Customers Love. 2010. Boston: Addison-Wesley.

Rock D. Quiet Leadership. 2007. New York: HarperBusiness.

Schwaber K and Sutherland J. The Scrum guide. 2011. https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf



Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (5 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.