Discussion is an important element of ensemble working. However, if the ensemble never write any code then that can kill people's enthusiasm for working together.
Longer discussions can be a symptom that people don't understand the problem well enough yet to agree on a good approach to solve it. Instead of yet more discussions, what can often help is just picking one approach and trying to code it together.
If it turns out not to work, then you'll probably have learnt more than you would have by continuing to discuss ideas abstractly.
"Bias to action" means just this - let's write some code, learn something about it, and do it now instead of continuing to try to analyze our way to a solution. We can discuss more later when we've learnt more about the problem!
There might also be strong wills in the team on what approach to take to solve something, have a look at the enabler try both with a timebox for that situation.
The longer discussions could also be caused by the team not knowing each other very well and/or not having a common design vocabulary, so they don't understand one another. If that is the case, then general team development exercises or a workshop on design principles might help.
Scenario: someone in the team really likes coding in isolation, coming up with a solution-design-architecture on their own. And then brings that solution to the team - either as a pull request or as a sketch of a solution - it can become real frustration for an ensemble.
What happens is that the problem-solving part is left out of the team effort. This means the ensemble-team becomes an execute only ensemble; not a learning team.
Bringing a problem instead of a solution has several advantages: we don't miss out on getting more eyes on the design/solution/architecture, which often means a better solution, not only technically but also team-alignment-wise. It also leaves out the frustration of being code monkeys only.
So this enabler suggests that you set your mind free of preconceived ideas and instead focus on trying to formulate more clearly what problem you are trying to solve, and trust the team to do so.
Before starting rotations, have everyone in the ensemble help to configure it. This means more eyes on the problem, errors (who's in the ensemble today? How many minute rotations? Is the audible bell setup?) is fixed quickly instead of interrupting flow later.
These are symptoms the team is not aligned on the goal of the session.
One way to address this is to be more explicit about the goal, not only talk about it but also write it down.
This goal writing could be as simple as someone sharing screen in beginning of session, and writing a GOAL.txt or README.md file, which can then live in the source control for the next session.
If you try this approach, make sure to time-box the goal writing to 20 minutes or something like that, and be cautious of the trap of going into details of implementation when writing the goal(s) down - keep the language as abstract as possible, as close to the domain or user language. E.g "Goal: users can sort on dates not only names in search result page" rather than "update SQL query for sorting on dates".
People work better together when they have a human connection - when they feel they know each other on a personal level as well as professionally. Perhaps someone has had a difficult day, or is stressed about something outside of work? Knowing what mood people in the ensemble are in today, is good to be more kind and sympathetic to each other.
Therefore, at the beginning of the ensemble session, take a few minutes to connect to each other - connect first. E.g ask everyone how they are, and let people share something about their day so far. Or, once you know each other better, perhaps prompt about what people are looking forward to during the year, or share some thoughts and feelings about a book they've read.
As a facilitator, try to use a prompt that is easy and limited enough to keep within a couple of minutes or so, especially if it's a large ensemble. Otherwise the connect first enabler can grow to eat up a lot of the session!
If everyone talks immediately, whenever they feel like it, then the navigator may become frustrated at the constant interruptions. And the typist will have a hard time judging who's ideas to implement. This ensemble enabler will make communication less choppy and interrupted, and leave the navigator feeling more in control.
Therefore, we suggest this simple protocol for communicating when you're not navigating:
It is up to the navigator to notice your raised finger(s), and then choose when to call on you to explain your idea.
Remote note: If you're not in the same room, or your webcams are off, most remote meetings have a ‘raise hand' or similar function you can use instead.
When you work in an ensemble you often have a shared goal list written in a README file in the repo. (You might call it a test list or a todo list.) Whenever the tests are green, or in fact whenever you think you've made progress towards something on the list, you should consider making a commit in VCS. In many cases you can base your commit message on the goal list item you're currently working on. If you can't use this text in your commit message then that could be useful feedback to you that your goal list items are not reflecting what you're actually working on. Take the chance to review your list and update it.
It seems the balance in the team is not there at all - one person 'is' the team, when it comes to solutions, ideas, implementations.
This is a symptom that knowledge sharing is low, and could use a boost. A great way to make that happen is to call out the 'hands off the keyboard!' enabler.
This simply means, that the one with the expert knowledge should not be the typist, instead focusing on navigating others so they get up to speed with the code base and domain. The rotations could be on the typist role only, keeping the same expert-navigator for a whole day or similar.
There is also a challenging twist on this enablers, which says the complete opposite: the expert should only stay at the keyboard, and let others navigate (without making decisions at the keyboard, see separate enabler).
This could, for instance, be employed after a few weeks when the remaining members of the team have acquired a greater level of expertise. Prior to that, it would be exceedingly frustrating for both the expert and the rest of the team, as the team would lack the necessary understanding of what needs to be done, while the typist possesses the requisite knowledge (albeit unable to convey it effectively).
We're interested in the best ideas making it into the code. If someone has mentioned something that could be useful, but perhaps they said it too quietly or at an inopportune moment, take the chance to encourage them to speak again at a better time, in a louder voice.
It should be as simple as asking them to repeat what they said, or to share their thoughts about a particular issue. Give them your support and encouragement, don't just take over their idea and say it yourself.
The communication between the navigator and typist is not working well enough, the navigator is not speaking at the correct level for the driver's current needs.
This enabler will hopefully reduce this frustration for the typist. As a navigator using intention-location-details enabler, you're treating the typist first as an intelligent person who knows a lot about coding, and gradually giving them more as you discover what more details they need right now given the cognitive complexity of the task.
This enabler will likely also help with handover to the next navigator, since the high-level goal - the intention or purpose - is clear and has been spoken to everyone on the team.
When it becomes clear there's a gap in the team's knowledge, and parallell research has been tried some times, you may have to find help from outside the ensemble.
Perhaps this would be a good time to borrow someone from another team who does have that knowledge - can you phone them and have them join you for half an hour? Perhaps they could navigate for a short while. Or be invited the next ensemble session.
In order for everyone to participate with engagement and heart, t needs to feel safe to take part in an ensemble - and in particular to navigate. Normally everyone will be in the rotations - we want the whole team to be contributing, engaged and involved. ª However, sometimes it's better to let people choose when to add themselves into the rotation. Particularly if they have missed a previous session or if they are new to the team. Welcome them and let them observe until they are ready to step into the rotation. That could be the entire session. What usually happens, however, is that the the person joins after only some rotations.
To use this ensemble enabler, simply state to the new/shy person that it is OK to just stay in the background observing what is happening for as long as they want, and join the ensemble when they feel ready - or not at all in this session; either is fine.
This is a basic, fundamental ground rule for this way of working:
We treat everyone with kindness, consideration and respect
Even if you've had a rough day, or you find someone annoying, or there are several other things you'd rather be doing, you have to stick to a basic level of decency towards the people you are working with. If you feel someone is out of order, remind them gently that this is how they agreed to behave in the ensemble. Suggest they could take a break if they need to and come back when they're ready to do that.
For an idea to go from your head into the computer it MUST go through someone else's hands
That's Llewellyn Falco's description of "strong-style" pair programming. For an ensemble, this is even more important. If every idea is open and transparent, expressed in a form so that it can be discussed as it makes its way into the code, we are in a better position to build good stuff together.
The typist has the hardest job here, because they have to break their habit of both thinking and typing themselves. Instead, they need to put more effort into listening - in particular to the navigator, and translating their ideas into code.
Why is this a good idea? The reason for this is that it encourages us to talk about the code together, as a team, instead of 'silently' developing the system in isolation. This helps spreading domain knowledge, tooling proficiency, code practices and so on, and builds a common language for the team to use. To the benefit of everyone, and particularly those new to the team.
If you notice the typist is rushing ahead writing code for an idea that hasn't been discussed, you could intervene straight away and talk about this ensemble enabler. Kindly suggest "more listening, less thinking at the keyboard". Perhaps also bring it up at the retrospective.
This enabler is about a situation which ideally isn't too common: no-one knows what a fruitful next step is to solve a task.
The suggestion is to break up the ensemble for some time, maybe 10 minutes or so, and let everyone gather data-information-google and so on, and share with the ensemble, perhaps paste in a team chat or similar.
When the time is up, show the team's search results on the shared screen and have people explain what they learned. Hopefully someone will gain enough insight to volunteer to continue navigation!
If this happens a lot, you could try the invite-an-expert enabler.
We're interested in the best ideas making it into the code, so if people have ideas that are being ignored, there's a danger we'll miss something important, or hinder the team from growing in collaboration.
It may help the team to listen to all voices if you pause the timer and ask them to discuss the idea or proposal you feel they have not paid attention to, and why it helps to collaborate and work on the problem together.
Remind the team that we want the best ideas to make it into the code, and good ideas can come from anyone in the team.
Read also: This is kind of the opposite to the enabler bias-to-action, which is for the case where the team is stalling on analysis-paralysis which hinders learning. Here, the team is steaming-on without paying attention to the smaller voices of the team, missing opportunities for growth and learning.
To alleviate symptoms like the ones above it could help to make the ensemble more attentive to who is doing what and when.
Therefore, at rotation, this enabler proposes a simple attention bringing trick: the new navigator calls out all the roles. Something like “John is typing, I'm navigating, Sue is next”. It's an awareness trick so that people are reminded of their current roles, and particularly for the person who is ‘next' to sit up and take notice. It gives the new navigator the attention of the group.
As a coach it might be tempting to just tell them which approach is best and to get on with it. That's pretty arrogant and clearly not a long-term solution! Woody Zuill has a general rule that you should "try both" or "try everything", but with the proviso that you set a time limit for each one. Make sure you have a commit you can return to easily, then begin coding one of the suggestions. Stash or revert the code when the time is up, and instead begin coding the next suggestion. When all options have been looked at, the team decides which one to pursue.
When the timer goes off, before the next navigator begins, the typist summarizes what they have been doing for the previous few minutes. They should aim to be concise (take less than 1 minute) and explain at as high a level as they can manage - as near ‘intention' as possible.
This should be a real help to the next navigator, who hopefully will be able to carry on in the same direction as the previous person. If the typist has difficulty explaining what's been happening, it can be a sign the direction and intention has not been spoken in the ensemble, and a short explanation from the previous navigator would be beneficial.
This is a challenging enabler, which really practices each person's ability to express things at an intentional level.
In improvisational theater, they have this rule. Say "yes, and..." to your fellow actors while you perform together. It means you should accept whatever they give you, and build on it. If the actors instead say "No, but..." and start in another direction entirely, it breaks the group flow - the actors know it will be a better performance if they support one another.
This is the kind of spirit we want to cultivate in the ensemble. Do not delete or undo what the previous navigators did before you. Refactor but do not rewrite. Say ‘Yes, and' to whatever your colleagues give you.