Team Behaviors

In my recent post on Optimum Iteration Length, I finished by saying that iteration size is not the cure for bad team behaviors, but shorter iteration size makes those behaviors more apparent.

This post is about how to counteract ineffective team behaviors, from my own experience:

There are three general diseases that have lots of different causes and lots of symptoms, but at the end of the day, they boil down to these three things:

1) Lack of Focus – team members are multi-tasking, The symptoms are there are too many work-in-progress stories, bugs, tasks, items and the team can’t decide for themselves what is most important.

 Lack of focus is almost always ultimately a leadership problem. Yes, team members get confused and yes, they don’t do what they have committed but ultimately it is a problem of leadership. If the leaders of the team (pm, scrum master, tech lead, architect, hiring manager, product owner) aren’t clear on what to focus on or don’t agree, or don’t collaborate, or don’t hold the team accountable – the team members are not going to focus.

 Seriously. Leadership has to control work in progress. Leadership has to ensure that the resources swarm each story. Leadership has to listen in the daily stand up and detect when a team member is working out of sequence, is multi-tasking, is not engaged.

 My recipe for driving focus into an agile team is simple: start by focusing on the remaining work. Team members often don’t understand how to get to done on their current task. The traditional scrum questions are too “loosey-goosey” for many teams. Replace the “What will I do today?” – with “How much effort is remaining in my current task?” – my prediction is that many team members will struggle at first to answer this question. They don’t inherently think like that. They think about how they are going to finish, but not how much is left. They may not even realize that they are stuck or in the weeds. This refocus on remaining work, reminds the developers that there is an expectation of progressing towards finishing. Lack of focus is often caused by leadership’s rewarding busy-ness rather than accomplishment.  Sometimes when developers are stuck or struggling, they are busy, frantically trying to figure out what to do, but only when we project remaining work, do we realize that busy-ness may not be getting us any closer to complete, burning hours without burning down the work.

 There is another concept that helps teams focus – the notion of tasks and things. Tasks are estimated deliverables with a defined outcome or definition of done. Things are activities that we do that may be optional or required but always take time away from our tasks. You burn down tasks, but things don’t count for delivery. Meetings may be necessary, but they are always things not tasks. Collaboration is necessary but it is not a task. Here is the reason – the task is what comes out of the meeting, not the meeting itself. If the purpose of the meeting was to make a decision, than the decision is the task. Why? How many times to you have a meeting to make a decision, but you don’t make the decision at the end of the meeting – you punt, you need more information, we need to analyze something. We decide that we aren’t prepared to decide. Meeting over, decision postponed. Meetings are just formal collaborations with a calendar and a room request. Collaboration is just people talking about problems and solutions. The WORK is to make decisions and implement the decisions.

 Here is the final focus concepts: drafts and reviews – Often, we struggle to finish a task because we are not sure our solution is good enough. We keep noodling or polishing or adjusting or refining or whatever – but we don’t declare it complete – maybe its because we don’t think our work is good enough, or we see one more thing that can be improved and than another and another. We can’t stop fixing things up. What is worse is that we spend all that time fixing, and our original idea was wrong, so we have to redo it anyway.  Still worse is when our first draft would have been good enough. When you make your plan, you may decide to have several drafts which are not final, and review them to get feedback. This is important, because when we know our work is reviewed in draft, we get the first draft working very fast and get feedback, we collaborate on what the refinements should be we have more confidence so we know when to stop. This is especially important when we are doing “unfamiliar” work, because we start with less confidence. A team that practices drafts and reviews routinely will usually finish much faster than a team that tries to go straight to done.

2) Poor Collaboration – team members are ineffective because they don’t collaborate well. The symptoms are that the team can’t reach consensus on how to execute so they don’t start, or the team can’t transfer understanding between members leading to poor execution and rework or bugs.

Poor collaboration in my experience results from one of two causes:

1. No Common Language – The team hasn’t developed a common representation or language that they all understand that explains the problem domains and the technical domains so that communication is efficient and effective. One clear symptom of this is that the team hasn’t prioritized any shared documentation practices. Agile teams often use a team wiki to capture understanding that they have already gained as a team, and decisions that they have already successfully collaborated through. If your team is larger than 3 people, and they are struggling with collaboration and they don’t have a shared doc repository – that is a good place to start. The evidence of prior collaboration and the benefit from that collaboration is more effective collaboration in the future. If it feels like your team is making the same decisions over and over, or not remembering what they already decided or how to execute on what they decided – lightweight documentation is a good way to start. Leadership can simply assign tasks to individuals to “commemorate” collaborative decisions in the wiki as a way of driving a stake in the ground to ensure more effective collaboration in the future.
2.  Divide and Conquer Approach – Leadership is approaching things from a divide an conquer mentality rather than a maximized focus mentality. When your strategy for task assignment is to minimize the need for collaboration, rather than to ensure collaboration by making sure that at least two people are working together at all times you are teaching the team that collaboration is at best unnecessary and at worst wasteful. Leadership is, in effect, saying “Collaboration is hard, so lets not do it anymore than we have to.” The thing is with that approach, it never gets better. The more we practice something, the better we get at it, and collaboration is the essence of working together as a team. Soooo, by avoiding collaboration, we are NOT GETTING BETTER at WORKING LIKE A TEAM! It is the same thing we see when “the build takes to long”. OK so it takes a long time, so we do it less often and we fail at getting it to work better, and we only integrate our change infrequently, ending up with way more defects, rework, and drama. If we want to be agile, we have to tackle collaboration first.

3) Inadequate Understanding – The team (collectively) do not have sufficient understanding of something (the problem, the technology, the patterns, the user, the plan). Symptoms include inadequate design leading to rework, poor execution leading to rework or technical debt, work is performed out of sequence, estimates are off by orders of magnitude rather than standard deviations.

 Inadequate understanding is an individual problem and it is a collective problem. At the beginning of a new project or when the team is reorganized or reconstituted, we always start with inadequate understanding. I believe that one of the strengths of agile teams is that they don’t routinely reorganize or re-form. Team formation is difficult and expensive. We also almost always slow down when our collective understanding is inadequate. So what can the team do to increase understanding? Explain things to each other. This is part of why collaboration is so important. The collaboration should always be about explaining and not “telling”. The purest form of collaboration is leading with questions, but to do this, you need to have adequate understanding – to ask questions that allow the other to find their own path to the answer or the understanding.

 My recommendation, is that you have the team practice explaining both technical and problem domain concepts to each other in lunch meetings every day. But don’t always have the experts do the explaining, start with the experts, and work your way to the newest or least expert team members. Explaining things to others is a way of helping the team become better at explaining and collaborating. It is hard, and harder still for those whose communication skills or language skills will get in the way, but it will help each team member grow and develop.

 When really struggling with problem domain concepts, have the team explain the concept as they understand it to subject matter experts. Rather than having them listen, have them explain and let the subject matter experts ask questions and probe and correct.

 One often hears “I didn’t really understand “it” until I had to explain it to someone else. The way our brains are wired is for communication (yes, even you introverts). We learn by speaking. We learn by writing. We learn by doing. We don’t really learn by listening.  That is one reason we are taught to take notes in school – because we learn more through the process of output than through the process of input. My own analogy is this. Hearing a concept is like going to the hardware store and purchasing a tool. Its in your toolbox, but until you actually use it yourself, it isn’t valuable. Once you use a tool, you practice using it, and you become faster and more effective at using that tool. Having lots of tools in the box is nice, but if you only know how to use a hammer and a screwdriver, you won’t accomplish much. One of the best ways we have to practice using the concepts we have “learned” is to explain them to others. Then, when it counts, when we have real work that will benefit from using that concept, we are ready to go.