Self Organisation

I recently coached a team that had a problem. Actually, they thought they had a lot of problems. Their builds were a mess. Their environment was unstable. Their tests were broken. They were finding it very difficult to get any work done. Their once excellent planning was starting to drift away from reality. When we started to look into these problems though, it became clear that all these problems had one single cause – their team lead.

Let’s be perfectly clear here right at the start. Their team lead (let's call him Fred) wasn't deliberately setting out to cause problems. He didn't break the build or cause tests to fail. What Fred was doing was what a lot of team leads do – trying to free up his team. He was doing that by acting as their problem solver. Sounds fair enough? That’s part of the team lead’s job isn't it?

Well… yes. But the problem was in the way Fred (and many other team leads) tried to solve the problems – he tried to solve them himself. No matter what problem I asked about, the answer was “Fred is fixing that”. Poor Fred was running around madly fixing one problem after another. No sooner would he get the build working when the tests would fail. While he was working on the tests, the build would break again. It was too much for any one person to do. The team knew he was overworked but he was doing this for them. Bravely tackling all their problems single handed so they could concentrate on the important work of writing new features.

Fred had also taken over the sprint planning. Why have the whole team involved with planning when he could do it and free them up to do important work? Why have the team do estimating when he could do it and free up all that time for coding?

Over time, Fred had taken on more and more of the things that the team used to do as a team and started doing them himself. All with the best intentions. The job of the team is to deliver features so the more he could free them up from “administrative” tasks the better. Right?

Wrong. What Fred had done was stop the team from self-organising. Before, when the build broke, the team stopped and fixed it. Now, they kept going, writing more and more code that couldn't be built or tested while they waited for Fred to fix the build. Code that is not tested is inventory and we know that inventory causes waste. Worse, the team had no incentive to make the build stable because they knew that Fred would fix it. When the team was responsible for fixing the build they made sure that it didn't break because they didn't want to be distracted by a broken build. Now the build could break as much as it wanted and they would never be distracted. Fred would fix it. The team had lost their culture of stopping the line.

The planning situation was the same. The team was no longer planning work as a team, Fred was making the plans for them. As he wasn’t the one doing the work, the plans were less accurate and they were starting to miss their sprint goals.

The team was writing more code than ever before (because they weren't distracted by “administration”) but were achieving less and less. The team was sub-optimizing. By optimizing for development they had sub-optimized the wider process. They were building up inventory and causing waste. They were working full speed but going nowhere.

The way to fix it was obvious (with hindsight) – have the team start doing those “administrative” tasks again. Fred’s job was still problem solver but rather than solve all the problems himself, his job was to help the team solve its own problems. His job became guiding and leading them through the problem solving process rather than solving the problem directly. If they needed assistance from outside the team, it was his job to make sure they got it.

He needed to become a leader rather than a manager and we will look at that further in our next post.

Cheers

Dave