Sivaraam Duraisamy

Kanban and Scrum

Scrum - Small team spending a little time building small thing , but regularly to see the whole

Kanban - Visualize the workflow, Limit the Work in Progress, Measure and Optimize flow

Wastages in Software Industry

Existing Process

Waterfall Model

ISO 9001:2008

CMMI

Scrum

Kanban

Wastages in Software Industry

Reason for Wastages

How to over come

How Kanban is helping us

Existing process: Generally Waterfall Software Life Cycle method is followed by software institutions. Now many of the companies are started following to agile methodology in order to get better results. Recently Kanban which is familiar in the manufacturing Industry is being followed. In other industries the gap in the understanding about the end product by the customer and the producer is very less, but in software industry, as the final product can not be visualized initially, the expectation of the customer is not communicated properly to the producer, some times the customer himself is not clear enough about the requirements. The requirements are understood by the business analysis, then by the architect, then by the developer and tester and finally become a deliverable. Because of the gap created in each stage, finally when the customer see the deliverable, he see a lot of gap between his expectation and what is delivered to him. On the other side as software is the one to automate some of the processes, some changes might have happened during the development period, which the customers wish to have in the application. One more thing in other industries if something goes waste, at least the scrapped material can be used some way and fetch at least some value, where as in software industry, the raw material is the time spent by the team, if some thing goes wrong, noting can be recovered as a scrap also.

In lean we define waste as the one which is not adding value to the customer. As per the definition we have a lot of the waste produced in software industry. Normally the cost of quality in software industry is around 35%.The main wastes produced are documentations, defective source code. The documents are created to record the understandings of one and convey the information to other, as there are frequent changes are happening in the requirements, efforts are being spent updating documents every time.

Kanban helps the software industry to minimise the wastes, All the requirements

In Software –

Wastages are waiting in queue

Wastages are the activities which are hidden in the processes not adding any value to the customers. In case of maintenance phase and support services, normally the tickets are raised by the users of user representatives, the project team do an analyzes on the tickets, and assign it to the appropriate team member. The team member  find out the solution and implement it, then it goes to the testing team, the testing team do the testing and if the requirement then send it to the customer, else again assign it to the development team for rework. This is a simple process and we feel that all the steps are necessary, no step can be eliminated. This is being actually followed in most of the maintenance projects.

                                                                                                                                                Pass – to Customer

Receipt of Ticket – Analysis – Assigning of tasks- fixing – testing -  

                                                                                                                                                Fail – to Developer

Practically what happens is that sometimes, a good amount of tickets were fixed and waiting for the tester, the development  team still continue with other ticket. As the tasks are piling up the tester get stressed thinking of completing the tasks within a short span of time, so there is a chance of missing some test steps unknowingly, or leaving some steps on assumption there will not be defects on that area, resulting delivering product with inferior quality. Here the process defined is correct, but in practice, it tends to give a fewer quality. It is not known visibly when we follow the regular process.

Let us go to the Kanban board, this is nothing but the visual representation of the flow and the tickets status.  If you place the data in the board, everyone comes to know that good number of tasks are waiting for testing. Kanban recommends having a limit of tasks at every stage, let us assume that the tasks waiting for testing is limited to 3, once the limit is reached, the earlier activities can be stopped and the resources can be used to help / work along with the testers to bring down the tasks available in the Waiting for testing column, once done, again the other activities can be restarted. This ensures closing the ticket in a shorter period.

So the Kanban board helps to minimizing the cycle time, and also delivering a better quality.

But if the same thing repeats frequently, the developing team comes and helps the testers’ means, we have to increase the number of resources available to map with the production in other stages, then the total productivity gets improved.  We always need not go for increase the number of testers, can go for tools which will help the testers to do the job in a shorter time without sacrificing quality, else think of strengthening unit testing  using tools at the developers end , so that the area to be tested by the testers is minimized. Here the Kanban helps to improve the process in terms of using tools, which will not only ensures quality, it improves productivity too. 

Once if these changes are done, then the limits can be changed accordingly, so that a smooth flow is ensured.

Kanban doesn’t ends here, if there is smooth sailing, then the metrics Cycle time and the number of times the flow is interrupted because of reaching the maximum limit in each stage. If any repetitions are noted some points and appropriate action may be taken as a continual improvement.

The next study is on the type of tickets are being handled and the skillset of the persons handling the tickets. In Software industry, attrition is an issue which cannot be avoided. So the management should have a plan to train the new resources to scale up to the required skillset well in advance so that at any point of time the productivity is not affected because of the changes in the resources.

Received Tickets	Analysis	Assigned	Fixing In-progress	Fixing Done	Testing In Progress	Testing Done	Released to Customer	Accepted by Customer
Ticket 2, Ticket 3, Ticket 4, Ticket 5, Ticket 6,	Ticket 1,

Moving from Agile – Scrum to Kanban

In Scrum the scopes are defined for each sprint, and the at the end of each spring an working piece of code is delivered to the customer, changes in between the sprints are not encouraged. If any changes are to be done, the requester has to wait till the next iteration. In Kanban, all the requirements are placed and based on the customer’s request any item can be taken for production at any point of time, flexibility of choosing requirements is more. As the work in progress is not limited in Scrum, normally at the end of the sprint the testers have to put more effort to complete the testing and the defects are identified at the last few days, because of availability of limited time the deliverables are made with known defects, sometimes the known defects may spread over all the functions that are delivered, In Kanban, as the concentration is on completing the things in all the aspects, the number of known defects  will be drawn nearing to zero. So the better quality is ensured.

In Scrum the Daily Scrum happens at the same time at the same place and the members are say about their progress made during the last 24 hours and their plan for the next 24 hours and the impediments they have.  Normally the scrum board is updated during the Scrum meeting. In Kanban the meeting can happen at any point of time and the Kanban board is updated continuously.  Scrum boards are reset between each iteration, whereas  Kanban boards can be reset at any time.

The Process tools in Scrum practices are Scrum Master, Product Owner, Team, Sprint Planning Meeting, Daily Scrum, Sprint Review, Product Backlog, Sprint backlog and Burndown chart.  In Kanban we are Visualizing the workflow, Limiting the Work in progress and Measure and optimize lead time. Kanban is more adaptive.

Scrum insists on Cross-functional team, all the team members are expected to know everything.  Kanban recommends having cross functional teams and at the same time allowing having spe******ts also.  Scrum insists on the tasks has to fit into the sprint period, some times it is difficult to fit the tasks within the sprint time, incase of short term sprints, One week , two weeks. Where as Kanban as a continuous has not limit on the duration but insists on limiting the work in progress items. 

In Scrum estimation and velocity is prescribed. Both Scrum and Kanban allow working on multiple products simultaneously.

In Scrum burndown charts are prescribed, No specific types of diagrams prescribed in Kanban. Teams use whatever they need.

Start with retrospectively

Evolve the right process for your context

Don’t worry about getting it right from the start

Expand your tool kit’

Experiment