Skip to main content

Author: Gil Broza

What To Do If a Member Doesn’t Fit With the Team?

Agile development is not right for all software professionals. If you are bringing Agile into a siloed company accustomed to plan-driven methods, expect that 10% to 15% of the people will not fit.

In my experience, individuals might not fit with their newly Agile team for one or more of these reasons:

  • They strongly prefer to work alone, not as team members.
  • They would rather develop their specialties than shoulder miscellaneous team activities.
  • They prefer to implement other people’s plans and designs and don’t want to make any high-impact decisions.
  • They feel that the Agile methodology sets them up for failure because it doesn’t mandate the detailed planning and up-front design they associate with responsible development practice.
  • They are willing to go along with the Agile methodology but feel that their particular team is not up to the job, which will reflect badly on them.

Some of these folks express their displeasure quietly, doing their best to mitigate the risks they perceive. They work hard, intent on demonstrating their own performance according to pre-Agile criteria. Others resist openly, advocating a return to the trusted old ways. (Some might even act up, like the senior developer in section ‎7.4 who exclaimed that his team was stupid.) Some attempt to influence their managers to modify the team’s process. A small percentage — sensing the company’s new direction — may even quit.
If someone doesn’t fit in a siloed team, you could assign special work to her, have her sit separately, or have her communicate mostly with you. However, in an empowered, collaborative team environment, the fit problems affect her and the team a lot more. The team struggles to self-organize, to make commitments, and to hold each other accountable. As the Agile team leader, you have to be involved a lot more. It doesn’t take much for team members to become rancorous about the “problem child” getting special treatment while they are expected to do whatever it takes to succeed.

You might have some success educating, encouraging, or cajoling these folks to make the effort and play on their team. If they are good performers and have integrity, and if you do not want to lose them, you should give them a chance. Their resistance might be temporary, an artifact of the chaos period of the change curve. Still, be watchful, and don’t let it drag out.

“Let’s say that we have somebody who has a performance issue and is unable to carry his own weight. The team carries his weight; everybody assumes that they have to carry his weight because they work as a team. That can go on for months before anything is done about it. Maybe Agile does not work for everybody, yet those for whom it doesn’t work still remain on the team, and the team is supposed to still self-organize. Then we have morale issues. What ends up happening is that team members stay around eight to nine months longer than they ever should have. All the input others and I have for management appears to fall on deaf ears, because people strongly believe that since they are in an Agile team, they should stay in that team.”

— Brenda, a project manager

As Brenda’s story shows, toughing it out may not only fail to work, it can even hurt a lot of people. Apart from reducing the team’s performance, unresolved fit problems demoralize them. Sometimes, redeploying people can be a win for all involved, which means management must be part of any response.

All too often the person in question has highly valued skills, domain knowledge, or technical expertise. You and the team may feel that removing the person would hurt the team’s ability to produce required deliverables. In the short term, that might actually be the case. However, when the teams that I’ve known had such a member depart, they quickly regrouped and made up for the loss. The combination of relief, improved interactions, and rapid cross-training helped them improve performance beyond expectations.

You may be tempted to give people a second chance, and a third chance, and even a fourth. If you are like most of the managers I’ve met, you don’t want to hurt the person or lose their contribution. You must clearly realize the detrimental effect on the team of having that person there, or that the status quo may not be good for the unhappy person, either. For your own peace of mind and a level-headed decision, seek someone to coach you or discuss possible courses of action with you.

About the book and the author

The book The Human Side of Agile: How to Help Your Team Deliver, from which this article is excerpted, was released today and is available online at www.TheHumanSideOfAgile.com.  With this book, Gil Broza has created a practical, universal guide to navigating the least manageable, understood, and appreciated asset in an Agile environment: its human side. Even if your customers are reasonably happy and your developers seem to be doing okay, you know your team is capable of more: delivering great products and staying ahead of ever-changing demands. You want to feel good about using Agile and to create the conditions for great results, but the skills you honed in traditional environments don’t always apply to the role of Agile team leader. The Human Side of Agile fills this gap, guiding you to:

  • Establish yourself as a confident and capable leader who adds value
  • Build and lead an engaged team that can handle almost any challenge
  • Cultivate collaboration and a continuous improvement mind-set
  • Reap the full benefits of Agile in the real world with real people

Click on www.TheHumanSideOfAgile.com to discover the “virtual loot bag” you’ll receive from Gil’s network of collaborators and experts for ordering your copy today.

Don’t forget to leave your comments below.

Why Should I Insist That Team Members Be Full-Time?

Most Agile experts recommend dedicating people full-time to their Agile team. Developers, testers, and other professionals should only deal with items in their team’s work stream — the backlog. This minimizes the cost of switching between unrelated activities and enables the team members to concentrate on their work.

Management usually frowns on this advice, for two reasons:

  1. They want to maximize people’s output. If someone is only needed 80% of the time on one project, what happens with the rest of his time?
  2. The workload usually includes more than net new development. It also includes production support, some training, fixing older versions, roadmap planning, or merely smaller one-off projects. These activities are often managed separately and, to staff them, individuals are “sliced and diced.”

Many individual contributors also embrace this thinking. They consider it reasonable that they be 60% on project A, 25% on project B, and 15% on project C.
Both management and line workers are well aware that, in most software development efforts, the largest cost item is the team’s pay. So, naturally, they follow the factory logic of maximizing utilization, which goes hand in hand with referring to people as “resources.” Many of them don’t realize the cost of context switching and don’t know that utilization is not the right measure to look at. The useful indicator isn’t that people are kept busy; it’s their contribution to the company’s overall productivity and business.

At one standup, I heard a developer report to the ScrumMaster, “I just finished that task I’m working on, so I’m a free resource now.”

Consider Alex, a highly skilled database analyst. He is only needed half the time on the Blue Team, so he spends the other half helping the Green Team and the Red Team.

This approach implicitly assumes that the return on Alex’s time — his usefulness or productivity — is proportional to the time he spends on projects. After all, he’s competent, he’s motivated, and he wouldn’t waste company time. So, every minute he’s on a task, he’s being useful. Makes sense, right?

Sure, if Alex were a computer.

Because Alex is human, though, he will not be all that productive, and neither will his teammates. Here are just four reasons:

  1. When Alex switches from the Green Team’s project to the Red Team’s, he needs time to catch up on Red’s developments. This isn’t like synchronizing a smartphone; it takes time and often involves asking people questions, thus lowering their output.
  2. Inevitably, his bonds with the Blue Team members (and the Red ones, and the Green ones) are weaker. He’s simply not around enough, and when he is, he’s this “expert” they should all listen to. This often translates into reduced collaboration, trust, and knowledge sharing.
  3. Alex has no slack time in which to come up with new ideas or simplifications. He lacks the bandwidth to consider that perhaps they should be building other product features.
  4. The Blue Team needs him for 50% on average. What happens the week he’s needed for 80%? Either he becomes the bottleneck and Blue suffers, or he spends that time with Blue and then Red and Green both suffer. A flurry of management activity ensues to coordinate his time, none of which gets deducted from anyone’s “productivity.”

What about the costs you see only much later? A few months of this, and Alex burns out, or asks to be reassigned, or even leaves the company.

What can you do? Stop the “maximizing utilization” madness. Even your computer’s operating system avoids 100% CPU utilization (and that’s a machine!). Serve your team by fighting to have full-time members on it. Keep pointing out that what matters is overall team throughput — a steady stream of value — not the productivity of individual Alexes. If you absolutely must share certain people, then fight to share them with only one other team and make sure they are being useful and effective when they are on your project. You can rotate your specialists among the teams every few months for increased knowledge sharing, solution consistency, and personal satisfaction.

About the book and the author

The excerpt above is from the book The Human Side of Agile: How to Help Your Team Deliver which will be available September the 12th. With this book, Gil Broza has created a practical, universal guide to navigating the least manageable, understood, and appreciated asset in an Agile environment: its human side. Even if your customers are reasonably happy and your developers seem to be doing okay, you know your team is capable of more: delivering great products and staying ahead of ever-changing demands. You want to feel good about using Agile and to create the conditions for great results, but the skills you honed in traditional environments don’t always apply to the role of Agile team leader. The Human Side of Agile fills this gap, guiding you to:

  • Establish yourself as a confident and capable leader who adds value
  • Build and lead an engaged team that can handle almost any challenge
  • Cultivate collaboration and a continuous improvement mind-set
  • Reap the full benefits of Agile in the real world with real people

Don’t forget to leave your comments below.

What Encourages Team Members to Pull Together?

One defining characteristic of any team is their shared purpose. I always ask about it when I meet a new team. The answer is usually beige, something like, “We do the social media component.” Stronger teams have an identity, a vivid purpose, or an inspiring vision. Such teams ask themselves, “What must we do together that is larger than any of us, requires all of us, and for which none of us can claim individual victory until it is done?” [i] In some cases, a team will reflect their identity in a name. [ii]

Basic affinity between the members is necessary for them to want to be with each other. Some common background and shared interests are helpful, although shared values are much more powerful. Imagine you and I are on a team writing medical software. You were attracted to your job because it improves people’s lives, whereas I joined for the outstanding pay, which allows me new luxuries. We are both motivated and willing to work together, but would you care to work with me? Would you go the extra mile on my behalf, or have my back, when you know I’m really just in it for the money?
Another powerful catalyst to team growth is success. If a team follows through on a valuable commitment, they will grow stronger. As each member considers that, together, they have hit a significant target, their success becomes a reinforcing feedback loop. Agile coaches rely on this loop to get teams started on the right foot by helping them secure “quick wins.”

You don’t have to wait for big team commitments, since those can take several weeks to materialize. The same principle operates on a smaller scale. Every time a person makes and keeps a small promise to a coworker, the mutual trust level goes up.

If you and I are on a team, we are not joined at the hip. There will be situations in which I will have to make decisions and promises on our behalf. You cannot control what I say, but you will have to live with the consequences. How do you like that? This worry is the highest hurdle to teamwork — and to lower the hurdle, you need trust. Trust is the foundation of teamwork, and if I am a member of your team, it is my responsibility to demonstrate my trustworthiness to you. Here is what I would do:

Share relevant information promptly. I would share meaningful updates and new developments in a timely manner. In particular, if I no longer thought I could keep a promise, I would tell you as soon as possible.

Be authentic. Speaking the truth is only the beginning. I would not pretend to know what I don’t know, or say “yes” (or “maybe”) when I mean “no.” I would work with you, but I would not pretend to be your friend unless I meant it. I would treat you as I would want to be treated.

Pull you into conversations that affect you. If I am about to make a decision that determines your work or limits your choices, I would delay it to the last responsible moment to allow you to join the decision-making process. (Examples include iteration planning and defining our meaning of “done.”)

Strive to be a dependable colleague. If my job pulls me in different directions, one of which is our team, I would arrange my other obligations as best I can so you know when and to what extent you can depend on me. If my schedule causes me to disappear on you unpredictably, and that hurts you, I would rather leave the team.

Caution: extremely challenging advice ahead. Address issues directly. When something about our work together upsets me and impedes our progress, I would hope for the nerve to have the uncomfortable conversation with you. It would demonstrate how important our relationship is to me, and I hope you would take it in that spirit.

About the book and the author

The excerpt above is from the book The Human Side of Agile: How to Help Your Team Deliver which will be available September the 12th. With this book, Gil Broza has created a practical, universal guide to navigating the least manageable, understood, and appreciated asset in an Agile environment: its human side. Even if your customers are reasonably happy and your developers seem to be doing okay, you know your team is capable of more: delivering great products and staying ahead of ever-changing demands. You want to feel good about using Agile and to create the conditions for great results, but the skills you honed in traditional environments don’t always apply to the role of Agile team leader. The Human Side of Agile fills this gap, guiding you to:

  • Establish yourself as a confident and capable leader who adds value

  • Build and lead an engaged team that can handle almost any challenge

  • Cultivate collaboration and a continuous improvement mind-set

  • Reap the full benefits of Agile in the real world with real people

Don’t forget to leave your comments below.


[i] I learned this powerful question from Christopher Avery.

[ii] A famous early example from the software industry is the Black Team, a testing team at IBM. The story is recounted in Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams, 2nd ed. (New York: Dorset House, 1999).