* This story is taking place in Beijing November 2008.
* I was responsible for building up UI development and maintenance on Nokia’s S30 platform (low cost phones).
* We were struggling with the lack of skilled SW developers and big maintenance load from various projects.
* The developers were working overtime when they were getting close to a project deadline, to keep up with the number of issues.
* The issues was assigned to the developers, typically the developers had 10-30 issues assigned and was working on 4-6 at the same time, to be more effective.
* This had been the way of working for many years and the experience was that the developers were getting burned out.
* The department was able to handle the maintenance, but most of the time we did not have the extra resources to do any new development.
* We had started to use Scrum for new development in October 2008 with fantastic results, so we wanted to try the same concept with our maintenance, we was measuring the average number of issues that we fixed per week, so we was able to see if our new way of working was making a difference or not.
* We quickly realized that Maintenance and Scrum did not work well, however after adjusting the model a couple of times, we ended up with a model that was looking very much like Kanban (another Agile discipline) – described in details in the coming slides – the main idea was the each developer was only allowed to work on one issue at a time.
* The developers was no longer working over time and actually had a little extra time during their working hour (i.e. waiting for compilers etc.), we were however able to handle the maintenance load and even had extra time to start new development projects.
* Our first thought was that the number of issues had decreased and this would be the reason why we had the extra time, however when we looked at the number of issues that we fixed per week, we realized that we had increased the productivity with 70%!
* The reaction from the higher level management in Beijing was mistrust, they believed that we was delivering poor quality and that was the reason for the big increase – so we started to investigate if we had lower quality in the new way of working, we looked at the code and at the amount of “bounce back errors”, however the quality was still very high and at least not decreased.
* The consequence was that the section could start new development even in the phase when projects was about to close, we even had resources to help other sections when they had extra workload (they did not use Agile principles and was still working OT).
* We continued to work with this model, and 2 years after I left, I talked with the manager for the section about how things was going, and he told me that they was still measuring the average number of issues fixed per week, and from time to time, he saw that the number was dropping, he could then walk around among the developers and found that they had picked 3-4 issues to be more effective. After getting everyone to return the issues and only working on one, the productivity went up to the normal level.
* Imagine that we start to use this way of working, i.e. get management and development resources to understand the importance of not doing task switching in the daily work, imagine where we could use the extra time that we would gain…
The Kanban flow
* Issue arrive to “Kanban chief’s” inbox
◦ Kanban chief investigate that the issue has a good description, enough log-files etc. – i.e. that the issue is ready for the developer
◦ “Kanban chief” will prioritize the issue and put it on the teams wall.
◦ The “Kanban chief” will be responsible for the issue until a developer have selected it.
◦ We call the “Kanban chief” for the QA-function at Sony.
* The developer will select “one” issue from the wall of issues, if any issue is marked as a SS, then that issue have to be selected no matter the developers competence, but those who have the competence will have to help this person if needed, this also ensure that there is a knowledge sharing in the section – the developer will put himself as responsible for the issue.
* If a developer need additional information, the developer will request the additional information, write all known information about the issue in the error report, so others (or himself) could get faster up-to speed, put the issue back as “impediment” and assign the “Kanban chief” as responsible – the developer then select a new issue from the wall, like normal.
* When the “Kanban chief” receive the requested information for issues marked as impediment, he will move the issue back to the “Backlog” and it will be possible for a new developer to select it.
* When the developer have fixed the issue, he will test it and call for a review – when this is done, the issue will be send to pool for testing, in Beijing we had a special team sitting next to us who did the testing.
* When the issue has been delivered for test, the developer will select a new issue.
* We removed an unidentified time consumer – task switching, people (developers, project managers and people managers) did not see that this was causing delays in deliveries, actually most people felt that they were less effective after the new wow, because they had idle time – however statistic showed that we were 70% more effective due to the focused way of working.
* We used the extra capacity to do new development, this was causing people to be more engaged than when they only did maintenance.
* We started to rotate people – the rotation secured that everyone did maintenance from time to time and new development from time to time