How segmenting work helped a developer see problems
Michael Ballé recently visited us at Theodo. After his walk through the gemba, he told us bluntly that we were not applying pull properly, because we did not understand its purpose.
In our industry, sprints usually last between two weeks and a month, and user stories between one and five days. So we thought we were doing very well
Seeing him surprised, we tried to explain why we thought we were really pulling. "We have sprints that only last one week, and our user stories take less than a day," said Benoît, our co-founder (a sprint is a period of time during which we produce features for clients' software, organized into user stories). In our industry, sprints usually last between two weeks and a month, and user stories between one and five days. So we thought we were doing very well.
"Come on! In manufacturing, if an operator takes more than 10 minutes to do something, it means he has not mastered the content of the work," Michael replied. Soon after that, Benoît, our lean coach Régis Medina and I began thinking about ways to break our developers' work down into smaller tasks of 10 minutes each.
BREAK DOWN THE WORK, SEE THE PROBLEMS
I chose to experiment with one of the team's tech leads, Nicolas Boutin. At the time, Nicolas was leading a team of two developers who had failed five sprints in the previous 10 weeks.
I spent two hours with him while he built a user story. Before he started coding, I asked him to list and define each step (of 10 minutes at most) he would have to carry out to build the story. Then he estimated the time for each step. Even if he did not know how to do something, thought he would not be able to finish the step or ran out of time, I told him he could ask me for help whenever he needed - just as an operator in a Toyota assembly plant would do by pulling the andon cord.
Nicolas was working on a sign-up form to open a life insurance policy online, in which the customer enters the minimum amount of money he wishes to add. Nicolas split the user story into eight steps, totaling 22 minutes and 10 seconds (instead of the roughly four hours the team had initially estimated):
- Fill in the online forms to get to step 4 and see the page where the final result would be visible - 3 minutes.
- Find similar code to copy and paste - 30 seconds.
- Find the place to paste the copied code, paste it and adapt it with sample data - 10 seconds.
- Write an automated test case - 10 minutes.
- Replace the sample data with real data obtained from the database according to the policy taken out - 1 minute.
- Test in the browser - 30 seconds.
- Publish the code to the validation platform - 2 minutes.
- Test on the validation platform - 5 minutes.
If he did not run into any problems, Nicolas could deliver the story 10 times faster than previously expected.
I watched, stopwatch in hand, as he started coding, and wrote down everything he did. The first problem came up in the second step: Nicolas struggled to find the three lines of code he needed in a file of more than 300 lines. The file was obviously far too long, and it took two minutes to find the right code.
After he pasted the lines into the right file, the page broke. The design was not as expected, with some content blocks misaligned or missing. We realized he had not copied all the lines he needed. Two hours later, Nicolas had completed six of the eight steps he had listed. Three steps were done in the estimated time, and two were missing from the flow. He pulled the andon four times. In the end, it took just under four hours to complete the user story, just as the team had estimated (so the long process had no impact on the production plan).
We took some time to analyze the problems Nicolas encountered at each step. They included: lack of knowledge of the technology and tools he used; difficulty reading the code and lack of adherence to internal coding conventions; and the fact that his IDE (Integrated Development Environment - basically the code editor) had not been configured.
Whenever possible, we addressed the root cause of the problem to solve it immediately.
Whenever possible, we addressed the root cause of the problem to solve it immediately. For all the problems that could not be solved right away, Nicolas added a task to his list. At the end of the day, he was thrilled. "Today is the day I've learned the most since I started working at Theodo," he told me.
SOLVE SMALL PROBLEMS TO BUILD 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 last four weeks, they even improved their productivity by 40%. In addition, as we solved problems, we were able to create a spirit of kaizen in the team and found that we were getting more and more leadership development opportunities.
Today, each developer tackles one of the most important problems he encounters every day
Today, each developer tackles one of the most important problems he encounters every day. Before, problems were not clearly defined - "We are half a day behind" - which meant that finding the root causes was like looking for a needle in a haystack. Now they investigate problems less than 10 minutes after they occur, so they can be fixed immediately.
As team leader, he helps each developer grow and succeed in their work
Finally, we feel Nicolas's role in the team is much clearer. As team leader, he helps each developer grow and succeed in their work. The team's feedback was so positive that we decided to roll this initiative out to other teams. Perhaps a great opportunity for another article?
