FEATURE – In the second article in our series with Theodo, the CTO tells us about an experiment that showed how problem solving is easier when the job is clearly defined.

Words: Benjamin Grandfond, Chief Technology Officer, Theodo

Michael Ballé recently visited us at Theodo. After his gemba walk, he told us bluntly that we weren’t properly applying pull because we didn’t understand its purpose.

Taken aback, we tried to explain to him why we thought we were actually pulling. “We have sprints that only last one week, and our user stories are less than a day,” Benoît, our co-founder, said. (A sprint is a period of time during which we produce features of clients’ software, organized in user stories.) In our industry, sprints typically last between two weeks and one month, and user stories between one and five days. So we thought we were doing pretty good.

“Please! In manufacturing, if an operator takes more than 10 minutes to do something it means he is not mastering the work content,” Michael answered. Right after that, Benoît, our lean coach Régis Medina and I started to think of ways we could break down the work of our developers in tasks less than 10 minutes long.

SPLIT THE WORK, SEE PROBLEMS

I chose to experiment with one of our team tech leaders, Nicolas Boutin. At the moment, Nicolas was leading a team of two developers who had failed five sprints over the previous 10 weeks.

I spent two hours with him, while he built a user story. Before he started to code, I asked him to list and define every step (of 10 minutes maximum) he would have to perform to build the user story. Then, he estimated the time he thought each step should take. Whether he didn’t know how to do something, thought he wouldn’t be able to deliver a step or ran out of time, I told him he could ask me for help whenever he felt he needed me – just like an operator in a Toyota assembly plant would do by pulling the andon cord.

Nicolas was working on a subscription form to open a life insurance policy online, on which the customer is asked to add the minimum amount of money he wants to put on it. Nicolas split the user story in eight steps, for a total of 22 minutes and 10 seconds (instead of the approximately four hours the team initially estimated):

1. Fill the online forms to reach step 4 and see the page where the end result would be visible – 3 minutes;
2. Find a similar piece of code to copy and paste – 30 seconds;
3. Find where to paste the copied code, paste it and adapt it with sample data – 10 seconds;
4. Write an automatic test case – 10 minutes;
5. Replace the sample data with real data fetched from the database according to subscribed contract – 1 minute;
6. Test it in the browser – 30 seconds;
7. Publish the code on validation platform – 2 minutes;
8. Test on validation platform – 5 minutes.

Provided he wouldn’t encounter any problems, Nicolas could deliver the story 10 times faster than previously expected.

I observed him as he started to code, chronometer in hand, and wrote down everything he did. The first problem arose at the second step: Nicolas struggled to find the three lines of code he needed in the file of more than 300 lines. It was obviously far too long, and it took us two minutes to find the right piece of code.

Once he pasted the lines in the right file, the page broke. The design was not at all as expected, with some blocks of content misaligned or missing. We realized that he hadn’t copied all the lines he needed. Two hours later, Nicolas had completed six steps out of the eight he had listed. Three steps were carried out in the estimated time, and two steps were found to be missing from the flow. He pulled the andon four times. In the end, it took him just under four hours to complete the user story, just like the team had estimated (therefore, the lengthy process had no impact on the production plan).

We took the time to analyze the problems Nicolas had encountered at each step. These included: lack of knowledge of the technology and tools he used; difficulty to read the code and lack of adherence to internal coding conventions; and the fact that his IDE (Integrated Development Environment – basically the code editor) was not configured.

Whenever possible, we addressed the root cause of the problem to solve it immediately. For all the issues that couldn’t be fixed right away, Nicolas added a to-do to his list. At the end of the day, he was energized and enthusiastic. “Today is the day I have learned the most since I started working at Theodo,” he told me.

SOLVE SMALL PROBLEMS TO CREATE LEADERS

The experiment was so successful that we decided to extend it to the whole team Nicolas leads. The results were great: for eight weeks in a row, every sprint was delivered on time. Over the past four weeks, they even improved their productivity by 40%. Moreover, as we solved problems, we were able to create a kaizen spirit in the team and found we were presented with more and more opportunities for leadership development.

Today, each developer tackles one of the most important problems he or she encounters every day. Before that, problems were not clearly defined – “We are half a day late” – which meant that finding the root causes was like looking for a needle in the haystack. Now they investigate issues less than 10 minutes from when they occur, so that they can be fixed right away.

Finally, we find that Nicolas' role in the team is much clearer. As a team leader, he helps each developer to grow and succeed in their job. The feedback from the team has been so positive that we have decided to launch this initiative in other teams. Perhaps a great opportunity for another article?

_{THE AUTHOR}