Typically, a lot of detailed knowledge is found low in the organizational hierarchy, in the minds of Developers, Testers, Operations etc. Yes, upper management better understands strategic direction, and product management better understands customers. But software developers can have detailed domain knowledge that gives them a valuable perspective on products. It’s widely accepted in Agile circles that having empowered teams will benefit the organization and its products. Empowered teams will use their knowledge to create more innovative designs with higher quality and productivity.
Directed (i.e. not empowered) teams will do as they’re told, though they may know better. Directed team members feel their potential and actual contributions are not understood or appreciated. They have lower morale.
There is often a correlation between empowered teams and jelled teams. Empowered teams think and work together more. Empowered team members know each other’s strengths and weaknesses. Shared responsibility, and working closely together leads directly to a team jelling. Jelled team members feel like they’re part of a group.
Teams that are not jelled, do not work together. Non jelled teams are collections of individuals with separate distinct work. Team members are individually responsible for their piece, and don’t help others unless asked. On not jelled teams, individuals assume it’s someone else’s job to figure out requirements, designs, value etc. so they need not provide input.
Non jelled team members will let projects fail if they see something is wrong. Members will say after: “I thought that was wrong, but it’s not my decision, so I didn’t say anything.”
So jelled teams work together. They help each other. Every individual feels responsible for the whole project. Whenever a team member wonders if something is wrong, or if a different perspective might help, they speak up and their input is welcome. Jelled teams are noisy. They sometimes all speak at once. In meetings they are all engaged.
It’s very likely that a properly empowered team will also jell.
Why is my team not acting empowered?
After all, I told them they’re empowered. Management gave an all hands meeting explaining the importance of empowerment. But the team is still not pulling together, not speaking up. Individuals are not stepping up to lead when they have the specialized knowledge to solve the current problem. So, what’s wrong?
Scrum Masters are not leaders
When a group of peers discuss issues, better ideas should win out. Peers try to uncover important facts, then use logic to get to a better decisions.
When a leader is present, the team will too often accept the thoughts/opinions of the leader rather than question their assumptions and reach their own conclusions.
Yes, the team may need someone to clarify goals, keep them on track, ensure ideas are recorded etc. And that person can be the Scrum Master (or not). But I’d call that role the meeting facilitator (or servant leader).
The Scrum Master/meeting facilitator encourages anyone on the team with an idea to speak up. People are less inclined to disagree with assertions coming from a leader. They’re more likely to take issue with assertions from peers, and those challenges lead to better decisions.
But just saying “I’m not the leader” is not enough, when your body language says you are the leader. And that body language often holds teams back from truly achieving empowerment.
What do I mean by body language?
When everyone else is sitting at a meeting, it’s natural for everyone to look at someone standing. The standing person becomes the de facto leader. In figure 1, Green Girl is obviously the leader of this meeting. If you ever need to get everyone’s attention when you’re in a seated discussion, just stand up.
When you are standing at the front of the room and others are sitting, that’s an even more powerful message that you’re the leader. In figure 2, Green Girl is again the leader of the meeting.
When you are the one asking questions, then answers will be directed to you. Side discussion is discouraged by this arrangement. When everyone is talking to you, you’re obviously the leader. This is like so many status meetings we’ve been in.
In figure 3, we see everyone sitting. But if Green Girl is asking the questions, or otherwise directing the meeting, then everyone will speak to her, feel less responsible, and contribute less.
So if you really, really want to discourage empowerment, then stand at the front of meetings asking questions and controlling the discussion.
Scrum Masters: Do any of these arrangements look familiar?
Projectors and Big Screens
What about using a projector? Well, whomever is running the projector is running the meeting. She controls what everyone can view. Meeting attendees talk to her by default, not to each other. So projector meetings also discourage empowerment.
In figure 4 you see that Green Girl controls what is being projected. But only part of the information (highlighted in red) is available to others in the meeting. The projector is a narrow window, and Green Girl controls what we see through that window. Others need to ask Green Girl if they want a different view to be shown. Green Girl is leading this meeting by default.
If you want your team to jell, it’s paramount that they talk to one another and interact at meetings. Interaction leads to trust. Greater trust will allow different team members to lead at different times and for the team to jell.
Visual Models and Information Radiators
Information radiators are discussed frequently in Agile, but I don’t see nearly enough teams using them. I also talk about the importance of visual models for communication in other blog posts. Having visual models/information radiators greatly facilitates empowered team discussions.
In figure 5, we see an empowered team in action. The team is gathered around several information radiators. The team may be doing standup. They might be working on design decisions, a user interface prototype, or a data model. But all are looking at the same information, trying to get work done as a team.
The visual model is available to the entire team at the same time. Everyone can explore every aspect independently. So everyone can follow their own train of thought independently in parallel.
The visual model cannot be communicated via a projector that gives a limited view driven by a meeting leader. In projector mode, everyone is forced to follow the train of thought of whomever controls the projector. They cannot pursue their own threads of thought. They become disengaged and bored. Their brains are turned off.
With a visual model (e.g. a drawing on a white board, or sticky note model), everyone can gather around and remain engaged.
You want the model to be available for update by anyone at any time.
In figure 6, we see how empowered teams tend to work. As we see in the figure, the whole team is examining one model, when Blue Guy gets a thought. He explains his concern to purple guy, using the other model to help with the explanation. After getting affirmation from one member, Blue Guy explains his thinking to the rest of the team. They’re convinced, the models are updated, and the team continues the meeting.
Jelled/empowered teams may have 20 of these interactions during a one hour meeting. So jelled/empowered teams are noisy. They interrupt. They all talk at once. But I wouldn’t want it any other way. Because I know they’re engaged and contributing, feel responsible, and are having more fun.
Giving the team a visual representation of their decisions greatly facilitates these noisy discussions which yield better decisions.
Working in parallel
Visual models will encourage team members to work together in parallel. Story maps are like that. On story maps, there’s one story per sticky, depicted in few words. A team can create a great story map by having all team members write stories on stickies in silence at the same time. Stories are read aloud after being written, avoiding duplication, and suggesting more ideas to meeting attendees.
Visual models encourage anyone, at any time to add, modify or delete parts of the model. For story maps, anyone can add another story by writing up a sticky and placing it appropriately on the diagram. Prioritization, planning, risks, retrospectives and more can be done the same way.
When visual models are created by team members in parallel, every team member knows that she is providing input, that she is expected to ensure the correctness of the Design/Plan/Requirements/â€¦ so she is engaged, and feels responsible.
Initially, you may need to step back
When a team is accustomed to being led, it can be difficult to transition to self directing.
As shown in figure 7, it may be necessary to move
yourself to the back of the room, and try not to say anything, nothing at all. Starting with stand up meetings is easiest. Team members know the questions, and should be capable of running them without you. As Scrum Master, try to just show up and say very little. Give a team member a ball to pass around to designate who talks next.
Standups often rotate through team members. Since we now know that
standing up at the front of the room will make them (temporarily) the meeting leader, insist that team members stand up by the visual model (task board) when they talk. Now other team members will talk to whomever is presenting rather than the Scrum Master. The Scrum Master can help this along by standing at the furthest point from the visual model (see figure 7). Better still, have the team standing while you sit at the back as in figure 8.
If a manager should attend your meeting, the team dynamics are often dramatically affected. To minimize the disruption to your empowered team, I suggest you encourage managers to sit at the back with you as shown in figure 9.
Ask rather than direct
When anyone perceived as a leader speaks, he runs the risk of shutting down team members. When you see the team getting off track, you’ll be tempted to lead them back on. I suggest instead that you take a more passive approach, at least initially. Try framing your suggestion as a question. Rather than saying we should do standup in story order rather than person order, you can ask the team if perhaps we should go through the tasks by story. The team should discuss and decide.
Regarding the technique of asking questions, the team will eventually see what you’re doing, but they won’t mind. By not directing the team, they will feel more empowered.
Similarly, when the team looks to you for a decision, I suggest you turn it around and ask them what they think. Not all the time, but often enough. When they look at each other, and reach agreement on how to proceed, your team has taken another big step forward.
When the team is brainstorming, scrum masters and managers should offer their opinions last (perhaps using the question format). Any suggestion by an apparent leader can shut down discussion, whether or not they agree, so be careful.
If you’re a Scrum Master/team leader, and want your team to be empowered and jell:
- Don’t funnel information or decisions through yourself.
- Use body language to remove yourself from the leader role. Team members need to feel full
- Encourage your team members to make decisions. Turn questions back to them to decide.
- Ensure everyone participates.
- Use visual models as focal points that invite update from all team members.
- Use computer tools and projectors reluctantly.
- Get noisy. Let the team joke. Have fun.
I look forward to reading your feedback!