**Sucks. Needs complete rewriting**

They have heard, read and talked about agile, but when it comes to implementation, they are clueless. They are paying for a coach. Not a trainer. Not a friend. Not a facilitator. Not a yes-man. That is, while they aim for self-organization, autonomy, and agile mastery, they are not there yet. Right now, they need guidance.

Therefore

Do what they need you to do in the moment; which, in the early stages of your engagement, often means reducing their options for their own good.

Details

I have often seen agile coaches shy away from leading their teams when in fact, that is what the teams needed.

This is obviously very subtle. If you're not flexible enough and only give definitive answers to every question, you will make more mistakes. You will also appear bossy and/or dogmatic.

But if you pick your spots carefully and are able to explain your choices, it is usually more efficient.

Situation #1: Sprint Length

Let's say you're asked what the length of the sprint should be for a newly formed product development team where everyone is new to Scrum and their roles. Ideally, you wished they would not ask you the question and just self-organize to find the answer on their own! But if they are asking, it most often means they're not ready yet (nb: sometimes they are, they just don't know it... but let's leave that eventually aside). So a poor way to deal with this question as a coach would be:

• "Well, it depends. Some teams have 1 week sprints, some teams have 2, some have 3... I think the most common is 2 weeks because it's in between. But it's really up to every team. Depending on what duration they are comfortable with."

A better way to answer this question in this context would involve:

• acknowledging that this is an important decision and a great question
• reviewing the factors that help make the best decision with regards to sprint length (uncertainty, complexity, how often priorities change, ...)
• clearly formulating what your recommendation would be for that particular team based on what data you collected

Situation #2: 4 teams, whole development process up in the air

Let's take a more extreme example. You are now the coach for 4 development teams expected to work on the same product. This time, they ask you 25 fundamental questions about how they're going to work. Now, you may not even have time to discuss every question in details and explain everything to everyone while making sure nobody's feelings are hurt. Even "clearly formulated recommendations" wouldn't be good enough in this case. So a poor way to deal with this situation as a coach would be:

• "Let's organize workshops. All of us. Let's discuss each of these items and come up with a consensus decision before we start Sprint 1."

This may take weeks. They may take poor decisions. They may fight over unimportant things. And remember, (unless your CoachingContract says otherwise) they paid for a coach - not for a facilitator.

Instead, I may sort some of the questions offline (not completely alone, and after I've done my homework of course) and come up with some packaged answers. I'd announce to the team what I (or a short number of us) came up with, and we'll use our valuable time together to talk about the stuffs where I'd rather have them make the call. My announcement to the teams may sound something like:

• "We will be using 4-team Scrum. All teams will be cross-functional (no "design team"). (...)
  All teams will start and finish their sprints on the same days. (...)
  The 1st part of the Sprint planning will be with all 4 teams together, in order to distribute work items between teams. Then each team will run their Sprint planning part 2 separately. (...)
  In addition to team retrospective meetings, we will hold joint retrospective meetings. I will facilitate those at first. (...)
  Do you have any questions or remarks? (...) [listen, explain, adjust if you discover something really new]

  Alright, let's continue.
  Now, the questions that remain to be answered are:

  1. The sprint length
  2. The teams composition
  3. (...)

  And for those, I need you (...)"

The ReduceTheOptions Scorecard®

In order to sort things out, you can use a simple formula with criteria like in the sample below.

Every decision to be made is assessed against every criteria on a range from 0 to 10. The overall score is the sum of all criteria divided by 40 (the max score).

The lower the score, the less you should get involved. The higher the score, the less options they should be left with. And above a certain threshold, they're better off with virtually none.

Don't hesitate to tweak, add/remove criteria, adjust criteria weights when calculating the overall score, etc.

I am uncomfortable with this approach, what should I do?

Your discomfort might be legitimate. Maybe you are not in a situation where reducing their options is what your mentees need. Maybe they need the opposite: that more options be presented to them. From there, they might be very capable of making decisions with little effort and limited conflicts. But I rarely see this happen in the early stages of an agile coaching agreement. What I see more often, is a failure from the agile coach to acknowledge the confusion, the lack of common understanding, the urgency and the need for guidance.

When in doubt, refer to your sponsor and the team members directly. They should be able to tell you.

Also, in order to be more comfortable with this approach, you have to trust that the process will fix itself. That you will get opportunities later, to reconsider every sub-optimal call you will have made early on. You can then reassure the team and make it clear that you're not trying to close any door forever. You're only helping the team make good enough decisions "on average", with minimum effort, until you all have the time, the knowledge and the mindset needed to make better decisions about what would work best in their very situation.

Related articles: CoachingContract