There’s some key challenges when coaching remotely.

– communication theory (Barnlund model) suggests that the “sender” is also getting dynamic feedback from the “receiver” as they speak, which helps to improve comprehension and clarity. Much of this is non-verbal, including seeing when people are busy, or not. That’s part of the reason why face-to-face is more efficient and effective.

– there’s greater opportunity for ad-hoc coaching, conversations, and responding to coaching hooks in a face-to-face setting; we can build relationships more effectively, go for a coffee or a walk-and-talk. The idea of “Gemba” – the place where the work is done – matters.

– there’s greater opportunity for individuals to retreat from challenging conversations or situations online, avoiding conflicts and so leading to a dysfunctional team; it’s much harder to tell if an individual is stressed or under pressure.

– a recent Nature paper showed that the most creative combination is pairs working face to face; pairs remote and groups face-to-face were less productive

– teams working remotely tend to become silos faster, without the ad-hoc interaction with others outside of the immediate work colleagues

It is possible to work remotely, however you’ll end up with more, less effective online meetings. That’s not especially great for anyone.

That’s not saying there aren’t plenty of benefits to remote working, or that people are less productive, just that empathic communication suffers, and ad-hoc coaching hooks are a challenge.

– do you have teams that use your APIs?
– do they use them to create value?
– is their market for the value they create static and unchanging?

If the answer to those questions is “Yes” then you have identified your customers, and the value you will get from a Sprint Review where you collaborate on the direction those APIs will take.

If the answer to those questions is “No” then perhaps the team should be working on something that does create value?

It’s okay to be part of a supporting value stream that helps the rest of the business to deliver value; this is covered in Team Topologies (complicated subsystem team) …

I probably wouldn’t. Or rather, it’s the team’s retrospective, not yours – they should be the ones surfacing stuff to work on. A simple “what went well, what could go better? format will get you there.

Teams have bad Sprints. Sometimes a few bad Sprints. It’s okay.

It might be a better topic to unpack with individuals on a 1-on-1 basis first, to find out how they are doing and whether as individuals they are okay or struggling a bit.

I guess the other thing is how you collect data to help the team to understand what they can commit to, and why this Sprint was a struggle. Without that, it’s kind of hard for them to be objective or unpack things.

My counsel would be to wait to see if this is a pattern, or a one off, and whether they raise it or not. Don’t rush to the panic button….

Well, the main thing in an agile context is that the people who do the work are the only people who should be involved in estimating it. What I’d add to that is that
– guesses are not estimates
– estimates are not forecasts
– forecasts are not promises
The second key thing is just how you go about creating the work for the product backlog. My counsel would be to use the User Story Mapping approach that Jeff Patton describes in his book, on his website, and so on. In this
– you co-create with the customer what they want
– you split it into a “spine” (look up “walking skeleton”) and subsequent releases
– you size the work as a group, with the customer involved
The key thing about that sizing is that you uncover different perspectives and unknowns; these drive “research spikes” that help you refine the work, while negotiating with the customer. In that way the process is co-creation, rather than a transactional approach.
The second key thing is to avoid adding too much detail too soon. You need to do that for the most important thing (the “spine”) but not things that are further off. By the time you get to those, you and the customer will know more. Maybe they will change?
I tend to get the team to estimate those things in Sprints, using Fibonacci and asking them for a range they are 85% confident in. We’ll also surface a lot of unknowns there, and identify potential research spikes or things the customer needs to think about before we get there.
So now you have :
– micro-scale estimates in points for the first thing you need
– meso-scale estimates in a range of sprints for the next priority items
You can turn that into a forecast in a few ways; summing the midpoints of the ranges is the worst. Including the range as a variable is better(*). Monte Carlo modelling is better still.
if you ignore the worst way (just summing the midpoints) that gets you to a range of dates, in a cone of uncertainty. But remember those assumptions? They go along with the forecast.
Then I reforecast often; as we complete a big item we’ll user story map in detail the next one.
As we uncover new information, we’ll revisit the meso-scale forecasts.
As we discover more about the team throughput, we’ll adapt again.
Mostly that gets us to a point where we can collaborate on decision making with customer in a useful way.
(* this requires a bit of stats knowledge, but what I do is
– make a table of the items in excel
– put in the low and high estimate ranges in columns
– calculate the midpoint in a new column
– calculate the error bar (midpoint – low estimate)
– assume the error bar approximates the standard deviation
(remember that 85% confidence limit)
– create a column with the standard error (standard deviation squared)
– create a column that is the cumulative sum of the midpoints (M)
– create a column that is the cumulative sum of the standard errors
– create a column that is the square root of that cumulative sum of standard errors (S)
– create a column that is M-S; call this 16% chance of delivering, the early forecast in Sprints
– create a column that is M+S; call this 84% chance of delivering, the late forecast in Sprints
– convert Sprints to Dates with a look-up table.
If you want 5% – 95% confidence, then use M-2S and M+2S instead
Now that’s a pretty crude model, but it is capturing the team’s uncertainty in a realistic way.
As you uncover more, so you can refine the model.
Where there’s too much uncertainty, you know where to do research spikes to clarify.