The Problems with Player-Coaches

I recently got to chat with a friend, who coaches an American football team and the discussion drifted towards player coaches and QBs calling the plays. One of the reasons I prefer football to other sports is the impact play calling makes on the game. Since each snap is prefaced with a pause and reset, it gives the coach (or assistant coach) the opportunity to decide on what type of play will be made. This needs to take into account field position, down, time on clock, score, as well as the strength and weaknesses of your team and the opponents.

When there is a strong sense of trust between the coach and the team quarterback, the coach may cede this duty to the QB – he’s on the field, he’s the one that needs to execute. In some teams, the coach will also be the player – this is not unlikely for a new formed amateur or semi-amateur team where on person organizes the team, coaches it, but still wants to get in on the action.

So, what are the problems with this approach? First is the ability to see the whole situation. When on the field, vision is limited (on the sidelines, you can move over – look at the offense, the defense, your charts) and time is scarce (focus on the play, no time to talk). The other – more subtle – is that you are inherently biased. Sacked in the QB role? Maybe you’ll want to run the ball, to avoid getting hit. This will affect your decisions and thus the plays – optimizing (locally) for yourself, not for the team (globally).

So how does this feed into Agile? For one, it shows why an external facilitator, coach or Scrum Master is useful to the Team – they’re not in the thick of things, they are more divorced from the emotions. It also shows why a good Product Owner – one that is aware of the greater product vision (time lines, business environment, but also team’s strength and weaknesses) plays a critical role.

Advertisements

Energy in planning

Last Monday we had our next sprint planning (#13 for those keeping count). It was a Monday, not the usual Friday to avoid missing half the team, who took a day off to celebrate the last day of school. But this strays from my topic…

I really enjoy what we call “turnaround day” – we do our Sprint Review and Sprint Planning on the same day (more on that another time). One of the reasons is that the team feels very energized during and right after the meeting.

So much that we moved up the Planning in the day, because the engineers actually want to start working on the storiesĀ that day. We’ve previously thought that planning on a Friday afternoon would allow people to calm down, have time to absorb the work over the weekend (subconsciously!) and start cracking on it on Monday. Well, surprise!

Why do I think they’re so energized:

  • new shiny things to do! – new stories, means new opportunities, challenges, valuable contributions
  • we meet as a team – working in a LeSS framework, this is one of the times members of all the teams come together to collaborate
  • egalitarian meets experts – on one hand, everyone has input into their team’s backlog sprint, including freshly hired interns; on the other – the technical leads and senior engineers get asked about their opinions on key items
  • playfulness – there is an amount of joking and ribbing that occurs at the meetings:
    • we have an informal (and unenforced) rule “you touch the story card last, your team has to take it” – ended with someone using tweezers during planning
    • last time I heard the phrase “I can take these for my team, since I’m going on vacation” (tongue firmly in cheek)
    • wayward story cards make it into initial backlog piles, before someone notices the sabotage

And in the end, we are surprised how much the team is able to pick up for the next sprint and they do deliver!

Well, two more weeks and we get to plan again.

 

Regressions

I heard a really cool thing in our last sprint review. I was surprised to see that a new feature was fully enabled, one I didn’t think would be done in time. How did that happen?

Teamwork

And not that the team split up the story and worked on it in parallel, but a more interesting way of helping occurred. Since the engineer that wanted to focus on the story (having experience implementing it in another product) had just finished a big feature, he was still getting some late regressions from sporadic failures or longer tests. The team bandied together and handled these regressions for him, so he could focus on this new work. (And at the same time, probably got an understanding of the previous feature).