Debugging Agile Teams

Debugging Agile Teams is a black art. I know because I and many other Agile “experts” flail around with it. You can always tell when an Agile expert is lost. They wave their hands around a bit and mutter something like “it’s all emergent” or “it’s part of a self-directed work team,” or even “that’s just a conversation.” If they’re really flustered, they’ll quote some famous Agile guy — as if by quoting somebody smarter than they are, this should end all discussion.

But what conversation? About what, exactly? And how exactly is the team supposed to have these conversations and come up with these emergent behaviors? Nobody seems to explain that much. There’s a huge hunk of what goes on inside of a sprint — which should be dynamic and mostly unstructured, of course — that exists in some kind of black hole. What happens if something goes wrong?

Let’s fix that.

Start with basics: how well a team works together. Here’s a quick tool I use for this, the five dysfunctions of a team. We’ll get into remedies later. For now, let’s look at naming the bugs.

A picture of a pyramid with five levels, each signifying a dysfunction, used for debugging agile teams.

A great diagram to stick on your Agile team room wall somewhere,
it provides useful categories for debugging Agile team internal interactions

Debugging Agile Teams Using a Naming Template

Books, standards, guidelines, models, and management fads make great tools for creating vocabularies for your Agile team. They’re not so great at fixing these things — many times people come up with a couple of good ideas and then write 17 books, creating some kind of magic world around their view of the universe — but they often make for great sources of terms. In that spirit, I’d like to suggest “The Five Dysfunctions of a Team” to put in your reading stack. (It’s a quick read.)

Does your Agile team display these behaviors?

  • Name: Absence of Trust

    Description: This isn’t “trust” in the sense of falling backwards and having people catch you, or forming a commune with your team. This is trust in the sense that we believe that others in our team, when they ask us painful questions, are not personally attacking us but genuinely want to help the team reach its goals. This means I can say “Bob, your playing online games on Facebook is really hurting the rest of us. You’ve got to cut back.” without Bob feeling like he’s being personally attacked. It’s the hardest thing to gain and keep, but it’s also a critical part of a hyper-performing team.

    Evidence it’s a problem: People take on an air of invulnerability. Whatever happens or is a problem, it’s not them. They slowly and cleverly position themselves to be without fault or flaws. They have no weaknesses.

    Evidence you’ve fixed it: Everybody realizes they have problems they are working through, nobody is perfect, and they count on the rest of the team to help them manage those problems. Everybody is broken in some way and the team knows it. Everybody is vulnerable. There are no plastic or Teflon people.

  • Name: Fear of Conflict

    Description: This is being passionate and unguarded in your discussion of issues. People have “strong opinions, loosely held”. The team is always finding the most important, and sometimes very painful, things to talk about and putting it out there.

    Evidence it’s a problem: There’s no conflict, just meetings that seem to go on forever and never solve much. From the outside, if you look at it just right, there’s an atmosphere of artificial harmony. Nothing important ever gets talked about and fixed, so there’s nothing for anybody to be upset about. Problems are approached at an angle, the same old thing happens, and nothing much changes. The corporation has a culture of “everybody just getting along”. People who push for change or fiercely advocate their positions, while they may be praised, are avoided by most because they can be “dangerous”.

    Evidence you’ve fixed it: For an existing team making the change, there is initially a lot of conversations about very painful things that people have been putting off. New projects begin painfully and end wonderfully, because as time goes on all the conflicts have worked their way out. You don’t know what’s going to happen in a meeting and you look forward to seeing how it turns out. You enjoy being part of a dedicated, passionate, vocal team committed to getting something important done.

  • Name: Lack of Commitment

    Description: This is the team making commitments and working on problems as a team. It’s not just a bunch of individuals all working on things by themselves. Any kind of focus on rigidly, including Agile team roles and responsibilities (ouch!), is a problem. We don’t pick up Agile and try to use it in a way that simply assigns people new job titles.

    Evidence it’s a problem: A lot of ambiguity. People talk and say the right things, but the level of detail necessary for things to actually get done is never reached. There’s a lot of generalities and fuzziness. People do not move across functional roles to understand and help others. They don’t share the details of what they are working on with the team, instead just “handling it” on their own. They feel they have individual jobs they are responsible for, not a group goal that everybody is part of. People attend stand-ups and meetings, but thery’re always careful not to have solid things they commit to do. A lot of cargo-cult Agile teams live here.

    Evidence you’ve fixed it: The team is taking time to get everybody working together. If you insist on having testers, programmers learn from testers how to do their job. In turn, programmers take the time to teach testers how to begin coding. The teams is constantly, on it’s own, trying to become more cross-functional. People are not happy leaving a stand-up unless they have something solid to talk about tomorrow.

  • Name: Avoidance of Accountability

    Description: This is the active challenging of each team member by his peers of what he’s doing and saying. They hold each other accountable. They do their best to debug each other’s behavior and plans and expect the same from others.

    Evidence it’s a problem: Low standards. We just don’t expect much out of each other. Joe shows up at the sprint planning session, says he’ll handle module X, and somehow he makes it in time. But it’s always buggy. Nobody calls Joe out on it. It’s just not worth it. Or how about this example? The ScrumMaster is micro-managing the team, working like a dictator, always using “but that’s not Agile” whenever they are challenged. In the retrospective, anonymous comments tell them to chill out, that they are hurting things, but they toss them aside as “something I will try to work on.” Nobody comes out into the open and gently challenges them, they don’t feel that the comments are important, and the team stumbles on into the next sprint with no changes taking place.

    Evidence you’ve fixed it: You feel as if there is a high set of standards that you are trying to live up to in order to be part of the team. Each person is deeply concerned about the prospect of letting down their peers. They don’t just accept criticism and being called out by the group, they depend on it in order for them to know they’re really helping out. There are no magic job titles or tasks that the team can’t openly, directly, and emotionally talk about.

  • Name: Inattention to Results

    Description: What the team commits to matters. A lot. More than any other part of their job.

    Evidence it’s a problem: Status and ego are clearly evident among the team. People are quick to take credit for their work and ignore when others do well. There’s some expectation because Sue is a programmer she’s too good for testing, or that because Oscar is the ScrumMaster he can’t have a deliverable.

    Evidence you’ve fixed it: The team room, when it comes to the work being done, is truly an ego-free zone. You can’t tell from looking at them who does what. People are very slow to take credit when something goes right, but they’re happy to showcase somebody else’s contribution. They’ll sit down and talk about pet issues with the rest of the team — things like working times, code quality, music in the team room. In a team of managers, they’ll have open conversations about decreasing their staffs or moving things around. Their stuff, no matter how sacred to them, is subordinate to the team’s stuff.



Debugging Agile Teams is Going to be both Touchy-Feely and Painful

I think it’s a fair comment to say something like “But this is just all touchy-feely stuff. How are we supposed to actually use this? Have a sing-a-long?”

For those of us who are analytic and skeptical, the empirical reality that we technical folks live in is that developing technology, making technical stuff people want, is at least 50% people and people interactions. Probably more like 99%. But whatever it is, understanding the “wetware” involved is not optional anymore. More to the point, the industry is picking up on how important these people qualities are. It works. If we don’t want to start swimming in games and playing pin-the-tail-on-the-storyboard every day, we’re going to have to master enough of this to make our teams high-performing. That means doing some subjective measurement of Agile team dysfunction and taking exercises seriously that help fix problems identified. Note that there are hard implied constraints here that the Agile folks don’t necessarily like to talk about. This material isn’t applicable to just any team. High-performing distributed Agile teams are problematic if not impossible. Agile team size also plays a big role: many of these dysfunctions can never be fixed with too large of a team or a team that wouldn’t even recognize each other on the street.

For my more fun-minded friends and Agile wonks, there’s another lesson in this book that needs underlying: moving from a non-Agile team to an Agile team is not a painless thing. These are difficult behaviors to master for a brand-new team. They can be impossible for an existing dysfunctional team. As the book explains, it’s as if you have broken a leg, but never let it heal, instead just learning to walk with the problem. If you want your leg fixed, the doctor is going to have to rebreak it, and rebreaking a bone is much more painful than the original wound.

I think many of us who love the games and fun exercises that are part of Agile team building and development drift into a world where we believe with just enough “fun”, we can develop momentum that will somehow transform an Agile team’s attitudes. That’s just not true. Over months and years, people build up learned behaviors, muscle memory. They learn these dysfunctions as necessary protection strategies. Not everybody is going to be able to make the change to a high-performing team, and looking for people to drop out is probably a key indicator that you’re actually doing something useful. Tough medicine, especially for my contract friends. We all want Agile to be puppies and bunnies. That’s usually the way it’s sold! But moving to a true high-performing team is going to involve some difficult changes by all kinds of people in the organization, some critical conversations, some painful enforcement of new behaviors, some uncomfortable ways of working, and some casualties — at least initially. We don’t like to talk about that. But we must.

The core concepts of Agile I’ve always found fairly simple. It’s the damn execution that gets you every time. That’s the main reason I started Tiny Giant Books, to make books helping with the more practical aspects of putting it all together. Debugging Agile teams has to be at the top of the list at the highest levels in your organization if you want a chance to make it.


Follow the author on Twitter

February 15, 2012

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy this password:

* Type or paste password here:

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>