Agile methodologies favor effective team work. Team work is fun to do, hard to grow, and at times unpredictable to nurture. I might be biased here, but I have seen way too few good teams working effectively together. Let’s see what can happen with bad and with good team work in place.

The Bad

A few years back I found myself part of a team at a client. Overall we were six people on that team. There was a second team working on the same product, but in a different area. We had pretty good engineering practices in place, including pair programming, continuous integration, we started with unit tests and TDD on the 2 million lines of code legacy code base, and we were constantly balancing between time pressure from the customer and good design and architecture.

Around the second month into that client gig, we faced a difficult issue. We didn’t deliver anything in one Sprint. Back then we were applying Scrum, and we had a terrible time to tell the ProductOwner that we didn’t manage to deliver anything in the past two weeks. What puzzled us even more was that fact that we didn’t had a good theory why that happened. You might call it bad luck, maybe there was a story causing us so much trouble that kept us from the other stories – we didn’t know, and we didn’t have a clue.

So, in the retrospective at the end of this disaster we sat together in order to find out how we could solve that problem. But where do you start to improve stuff if whatever you did thus far didn’t work at all? Well, you can start improving anything since whatever you did probably contributed to your mess. Eventually we introduced to focus on finishing one story first, before going on to the next story. Thereby we tried to establish a single-piece flow, and hopefully we could make at least the most valuable story work first rather than starting all stories right from the start.

So, no matter how bad you are doing, make sure to find something you want to experiment in order to make your life better – a tiny piece at a time.

The Worse

So, we started with the next Sprint. We were energetic about our tiny improvement. It just felt right. Skip forward two weeks, and we still hadn’t delivered the most valuable story for our ProductOwner. If my brain remembers back correctly, I think we eventually finished one or two items that we planned, but certainly not the one that was sort of overdue, since we had worked on it for two Sprints straight now.

I still remember the ProductOwner from the retrospective that day. It seemed that his heartbeat was pulsating, and if you turned out the light, you could see his head glow red in the dark. He was pretty upset with us. The other team continued to deliver in the end. How could it be we were not delivering at all? There was something wrong. He made us feel his problem by telling us that he had a problem with the situation. It was unpleasant to be part of that team at that point in time. To say the least, I would have preferred to run away from that meeting. The ProductOwner was calm enough not to blame anyone on the team, though he was courageous enough to make us aware that we had a problem somewhere in our team that kept us from delivering.

Notice that things usually go worse before they can start to improve.

 

It turned out that this situation helped us become aware there was something wrong that we couldn’t solve by any programming practice, any strategy, or any framework. When the ProductOwner raised his unhappiness we were eventually able to surface the underlying problem that was – at least to me – hidden under the surface.

There were two team members that couldn’t work together on the same computer. It somehow did not only affect the two of us, but also dragged down our team’s productivity to a degree that kept us from delivering anything at all. When we constructively realized that underlying problem, we were able to deal with it.

Of course, during that retrospective there were tears shed, people felt uncomfortable, and we sort of had to deal with the situation. We were able to derive two experiments for the next Sprint: the two with the problem started to consult and mediate with a facilitator and mentor in order to solve there problem, and we agreed that it will be ok if the two will not work on the same computer any more.

Whenever something goes wrong, communicate congruently, openly, and leave out the blame. Make sure that everyone can see there is a problem, and feels safe to contribute solving it.

The Gordian Knot

When we fixed that underlying problem, we were able to deliver twice the amount of stories that we planned on the next day during Sprint Planning. We were even able to work as a team by engaging in high-level design and architecture discussions in our Sprint Plannings. Last, but not least we were able to convince the ProductOwner of the benefits of test-driven development in the following month because we were able to create enough slack so that we could cross-teach other team members in it.

After we fixed the problem that silently held the whole team back from performing, we were able to leverage the full power of our team. I have seen few teams since then that were able to out-perform themselves from Sprint to Sprint. Yet, this experience shaped.

Whenever someone asks me about team and team performance, and how this whole Scrum thingie can work, I think back about that story of that team. It took us roughly two months to go from Forming to Storming to Performing in the third month. Based on my experiences with other companies, and other teams, I think we were quite fast in that.

Last year I was interviewed by a client that was transitioning to Scrum in a new project. They asked me how long it would take to create a performing team. I told them that it takes roughly two to three months to get familiar with the Scrum mechanics (how I would like to call them), another two to twelve months to create an awareness for better coding practices, and eventually implement them, and maybe another twelve to twenty-four months to face the next organizational boundaries.

My message didn’t appear to be the message my interviewers were looking for. I haven’t heard from that company for six to nine months – until about a month ago. Maybe I was lucky, maybe the team had bad luck – I don’t know.

All I know is that the team in my initial story went from good to great in three months – thinking back I consider the surrounding environment being supportive for team building. I have never seen team building dynamics go that fast again.