Applying Kanban to IT Processes 4: Software Development

The fourth part of the series is focusing on a software development team, currently working along with a modified sashimi method (Waterfall with overlapping process stages). In this case, the goal is to refine and improve the team's current process, rather than setting up a new one.

The goal

The team is working on building and integrating systems that handle business communication and process transactions. One of the issues they decided to address is handling the reporting in a way, that will enable the product owner see the progress and added value in a clearer way. This has been difficult so far, as the way their systems are built keeps most of the change at the back end of the product, leaving the client with an impression of a rarely changing front end.

The process

At the moment, the team works with accordance to the following system:
- gathering requirements – building the system's architecture skeleton – gathering more detailed requirements – building more detailed modules (defined layers of data access, business logic, transaction and translation processes and a limited user interface). The fact that the requirements and build stages iterate close together makes for easy testing against some real third party organizations, with the benefit of early problem detection.

The approach

Since the current process is iterative and overlapping, the team has decided to begin increasing their transparency with Kanban, rather than Scrum, as this was going to cause less of an upheaval to the client (the systems are similar already). One other goal for the team is to provide convincing metrics, showing that with the help of an additional developer, they'd be able to greatly improve the delivery times.

The board

The process had been defined with inclusion of certain sub-steps and looks as follows:
Remaining work – Definition (Requirements – Design – Ready) – Development (Working – Ready) – Quality Assurance – Customer Acceptance (Ready – Done).
The work assignments are signaled on the board by users pictures, and once a task is completed, it gets a user referral sticker, to enable easy tracking down of a responsible person, in case of issues or questions. The WIP limits have been decided going by the number of people assigned to each step of the process.

The execution and first revision

After an initial accommodation process, the Kanban board is beginning to work and the process runs more-less smoothly. The first revision showed however, that QA was not managing to stay in line with the speed of the development, which often resulted with other team members needing to step in and help to clear the bottleneck. There was also an issue with the architect's role (the definition stage), whose role didn't take enough time and was bringing him to help out with development, which resulted with development quality being lowered and generating time needed for rework.

Process changes

What the team decided to do, in order to improve the workflow and delivery rates, was building some automated tests, to help out the QA stage, which was the one problematic area. Also, this will provide additional tasks for the architect, who hadn't had quite enough to do before. Also, the WIP limit for development was increased and an additional column it appeared – to accommodate tasks that have returned from QA as containing an error, and a policy of treating them as priority is introduced to ensure that the majority of finished tasks is done so with no error.

The result

With automation of tests and prioritizing the “error” lane, the team was able to both speed up the development and almost leave the QA person idle. Also, the number of tasks returned from QA to development dropped from 50 to 5%. The customer reviewing the work has many more tasks delivered each week then ever before.
Overall, what has been achieved is:

• Increase in productivity
• Higher reliability from the client's point of view
• Process transparency
• Reliable estimations
• Ability to measure the performance
• Possibility further development of the process and gain in time, that can be utilized for staff training

Read part 5 of the series: Applying Kanban to IT Processes: Kaizen »