Skip to content
December 12, 2012 / KaTe

A tale of a support team – when Scrum leads to Kanban – Episode 2 – Mission Impossible

So the first thing we needed to do is to break that horrifying atmosphere. A manager sticking his nose into everything, knowledge transfer, to another company, organizational havoc, it all has taken its toll on the people.


So I did something unexpected – I brought balloons into one of their meetings. Just plain, colorful balloons. And I kept the manager outside the door, he wasn’t allowed to enter. At first everyone looked at those balloons, some even grabbed a couple. Few minutes into the meeting, when the person being abroad finally got connected, some balloons were already in action. Making weird sounds, rocking on a chair, people had a distraction, so only if they heard a keyword they would pay more attention. It was a huge leap forward, from a lethargic state after 5 minutes, they were actually paying attention. The combo breaker happened few minutes later. One balloon popped, the guy trying to blow it fell down with his char. Real laughter bursted out, everyone started explaining what has happened to the girl on the other side of the phone line.

This was the turning point. The team realized that they don’t have to waste time on unproductive stuff, when they can spice it up a little. We introduced tight timeboxes and made adjustments to all our documents.

Changes in the technical elements were greater than ever. Everyone sat down creating a plan on how to save knowledge escaping with all the leaving people. The Competence Matrix came in very handy (I will describe it in the next post). Because of that they were able to identify who should pair with who on writing some useful documentation along with the code.

But most important is that they were setting their own goals. The new PO was starting to embark on this team, and steadily was bringing some stability. Sprint after sprint, new goals were achieved, instead of carrying things over, they were reprioritized in finally existing Product Backlog.

So what made the change possible?

  1. Breaking the lethargic atmosphere. Here simple balloons worked, but that depends on the team
  2. Self-organization and self-control – they understood that there are people waiting for the results of their work, so they didn’t need any other push. They started setting goals an achieving them one by one.
  3. Clear direction – the new PO gave them a purpose. As soon as he arrived, even though he didn’t know everything about the product, he introduced a fresh perspective – “there are people counting on you”.

You may not believe, but 4 months later this team got rid of the bug queue completely. There was nothing there. Due to systematic exploration of the system and step-by-step creating learning materials while doing so, they were able to create a documentation to all elements of the system. Although it wasn’t complete, it was a help in exploring this unimaginably entangled solution.

Introducing new people got easier as well – due to tutorials and warning signs in the code, they at least didn’t mess up things. Pair working became their daily routine. Two new people joined the team and started completing their own tasks just after two weeks.

Their Definition Of Done evolved. Due to system’s complexity it was also very complex, but inspected very often. Tools were adjusted every few weeks to reflect team’s information and technical needs.

Let’s sum up. Four months later:

Technology: as complex as it can be. Every possible platform, every possible language. Still.
Documentation: Some guidelines and warning signs. Still episodes of huge use cases to investigate, but not every element. This bought A LOT of time to do cooler stuff!
Automation: First pieces started. Still needs work.
Tools: single tool for bug reporting, Excel files for Sprint Backlogs and Product Backlog. Easily modifiable and super simple.
Bug Queue: 0 elements. All bugs and problem resolved instantly.
Feature Queue – steady, with a stress on improvements
Time to speed* : 2-4 weeks

jack docking

I still remember one moment when on one of the retrospectives a team member that visited the customer organization the most told us story:

“ You know, few months ago there was a huge red piece of paper in the middle of their main whiteboard saying ‘The Boss is down AGAIN’. It was there all the time. I went there today, and there was a tiny green sticky note in the corner saying “The Boss is OK”

But how does that lead to Kanban? That’s episode three.

Other parts: [part 1]  [part 3]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: