Kanban for Support Projects

Kanban is a lean agile methodology developed at Toyota Corporation, Japan to facilitate and optimize production process. Kanban uses visual cards/queues to manage tasks. ( Kan = Visual, Ban = Cards/Board). Primary focus of Kanban is to keep delivering 100% completed features to customer in a steady flow.

Kanban Methodology is based on following Lean Principles

1. Customer Value
2. Pull Method
3. Continuous Flow
4. Waste Elimination
5. Continuous Improvement  

Three key aspects for Kanban are 

1. Visualization
2. Flow and Pull
3. Work in Progress Limit

Visualization: 

Kanban Board has different columns. Each column represents different steps/queues as shown in the sample Kanban Board below. Individual tasks are represented by visual cards in these different steps.

Building a Board is a team activity. Like any Agile projects, Kanban team meet everyday for a Daily Standup and prioritize the items on Kanban board. In a Daily Standup Meeting, team discusses the roadblocks if they have. The difference in Kanban Standup and Scrum Standup is that Scrum team member discuss the work they have done since last meeting and also the work he/she will be doing on that day. But in Kanban Daily Standup, team does not discuss these two items. Primary focus is on impediments. 

Swimlanes (horizontal rows) are important parts of the visualized system. It is recommended to use Swimlanes to classify different services of work like Critical, 24 Hrs SLA, 48 Hrs SLA etc. In this example the name of the Swimlane represent the actual SLA attached to the tasks. 

The structure of Kanban Board is not fixed and team can structure it as per it's own needs. If team feels that particular step is a waste then team can delete that step to improve efficiency. 

Flow and Pull:

Kanban is about steady flow of tasks from one step to next. In Kanban, instead of Team Lead assigning (pushing) tasks to different team members, individual team members assign tasks for themselves (pull). When a task is completed then it is moved to next column and team member pulls tasks from "Ready for Development" column to "In Progress" column. When "Ready for Development" needs more tasks then team pull tasks from "To Do" Column. In Kanban team should start a new tasks only when old task has been completed and moved to next column.

Work in Progress Limit:

In Kanban there is a Work in Progress (WIP) limit for each column. WIP limit on each column ensures that team is not working over capacity and there is no constant switching of tasks. WIP limit also highlights potential bottlenecks if there are any. Team can decide the WIP limit for each column and it should be an ongoing process. One of the guidelines for setting up WIP limits is to set WIP limit to a column which takes more time and based on WIP limit of this column, team can set up WIP limits of other columns. In the sample Kanban Board above there is a WIP limit 5 for column Ready to Deploy. If this column reaches to it's higher WIP limit then new task should not be pulled to this column unless some of the tasks of this column are moved to next column. Another advantage of this WIP limit is that it eliminates the problem of partially done tasks. 

Issues with current Support System:

In current Support System Team Lead assigns tasks to different team members (Push tasks). Team lead needs to monitor backlog of each team members. Also there is no team collaboration in task allocation as everything is driven by a Team Lead. Many times there is a wait time for a team member for assignment of task from a Team Lead. As there is no upper limit on WIP items, team might be burn down with over capacity work. In this system Bottle necks are not clearly visible. 

How Kanban help to address issues with current Support System?

Kanban works on agile principles where there is a shared responsibility on a team instead of just a Team Lead. Kanban works on Pull model where team member pulls the tasks instead of Team Lead Pushes tasks to them. By this way Team Lead don't need to monitor individual team member backlog. Instead of that he can focus on other more important tasks. As it is the responsibility of a team member to pull the tasks there is no wait time for task assignment. Because of upper limit on WIP items there is no burn down of team members and WIP limit supports continuous flow of tasks. WIP limits on columns and Visual nature of Kanban highlights the Bottlenecks if there are any.

Kanban is a great tool with it's own advantages. But it does not replace existing Support process. Team should implement Kanban Principles on existing Support process. Kanban Principles with it's visual board will help team to streamline existing Support process and highlight the bottlenecks in visual manner. 

Kanban board for Scrum Projects

Kanban is a lean agile methodology developed at Toyota Corporation, Japan. Kanban utilizes visual queues to manage tasks. ( Kan = Visual, Ban = Cards)

In Software Development, Kanban board has visual cards of product backlog in different queues/steps. Cards move from one step to next, once current step is completed. One of the important aspect of Kanban queue is that there is a limit on WIP items for each queue. In the sample board below there is a limit of 1 items in Test queue. Unless this item moves to Done queue, new item cannot be moved to In Test queue from peer review queue. Same applies to Peer review and In Progress Queue. This upper limit helps steady flow of tasks and if there is an issue at any queue, it gets highlighted

Primary focus of Kanban is to keep delivering 100% completed features to customer in a steady flow.

While scrum focuses on short delivery cycle, early feedback, and continues improvement there are some challenges in Scrum. Some of these challenges are

1. Unclear Development Steps
2. Switching of multiple tasks
3. Partially done work.

If we incorporate Kanban principles along with Scrum then above mentioned challenges can be addressed.

• Unclear Development Steps: In Scrum there is a step "In Progress" but it done not give correct status of In Progress task. Instead of that if there are visually mentioned steps like Execution, Review, Testing then it will help team to get correct status of each task. By visualizing the workflow of tasks, team will be able to address issues at particular step if there are any. Also team can analyze the different steps on board and keep only those steps which add value to customer.

• Task Switching: Constant task switching by a Scrum Team will have hard time for a team to focus on tasks. It is an overload and it impacts the velocity of team. Kanban places limit on WIP items for each Step. If a step has reached WIP level then team has to move at least one task from that step to next step before new task is added to that step. By this way Kanvan prevents having too many tasks in a step and team don't need to switch on multiple tasks.

• Partially Done Work: Scrum values the batch of tasks done where as Kanban values continuous flow of individual task done. Scrum delivers bucket of features at a time whereas Kanban delivers features in steady stream. Because of this  nature of Scrum Delivery, Scrum may have multiple partially completed tasks at any time on scrum board. But Kanban focuses on getting the task done 100%. In Kanban there is a WIP limit for tasks in progress. This enforces Kanban team to complete in progress tasks before they can start working on new tasks.

Implementing Kanban principles on Scrum project will help Scrum team to identify the bottlenecks in visual queues and allow them to focus on those bottlenecks before it becomes a big problem.

 

 

Guidelines for Review Meeting

1. Sprint Review session should be well planned.
2. Before the Sprint Review meeting the Scrum Master should prepare the list of Features/User Stories which will be reviewed / will be demoed in the review meeting.
3. Scrum Master should send an email to all the stakeholders with the Goal of the Sprint and the features which will be reviewed in the Review meeting.
4. Scrum Master should go through the Sprint Backlog to make sure all the User Stories will be covered in Sprint Review Meeting.

Managing Unfinished Work in Scrum

In ideal situation all the User Stories should be completed by the end of the Sprint. But in reality because of multiple reasons we have some unfinished User Stories at the end of Sprint. Some teams move those unfinished User Stories to next Sprint. But the problem of this method is that we are actually changing the Scope of current Sprint while executing the Sprint and it is against the principle of Sprint. Sprint recommends that once you start the Sprint, the Scope of the Sprint should never change. 

The other effect of moving the unfinished User Stories to next Sprint is on Burn Down Chart. As you move unfinished User Stories to next Sprint, Burn Down Chart will dramatically come down to zero. This Burn Down Chart will give false impression that the Team has Burned Down all the User Stories of current Sprint. 

Please refer the Burn Down Chart below. It gives an impression that all the User Stories for a given Sprint were Burned Down. 

If you see the Burn Up Chart of the same Sprint then you will see that the Scope of the Sprint is changed almost every day and at the end of the Sprint the Scope has reduced steeply. Ideally the Scope line of Burn Up chart should be straight line. 

It is expected that in a Retrospective session, Team will discuss the reasons behind Unfinished User Stories and take corrective actions to avoid it in future. But if a Team refers above Burn Down Chart then there won't be any unfinished work and Team will miss an opportunity to learn and improve for next Sprint. 

Instead of moving unfinished User Story to next Sprint, Team should Split unfinished User Story. By Splitting the User Story, we will keep the original User Story into current Sprint and move the unfinished part of User Story to next Sprint.By this method your Burn Down will have still some ToDo tasks at the end of Sprint for unfinished User Stories. But this is okay. Team can use that data for the Retrospective session. 

Rally software provides nice feature of Splitting User Story. You can refer a URL below for the video of Splitting User Story in Rally.

https://help.rallydev.com/manage-unfinished-work

Guidelines for Effective Backlog Grooming Session

1. Schedule Backlog Grooming session at the middle or second half of the Sprint
2. Product Owner will present the User Story to the team.
3. If team has queries about the User Stories then they can ask clarifications to the Product Owner
4. Team will review the estimates and if needed re-estimate the User Stories
5. Team will confirm that each User Story has an Acceptance Criteria
6. Team will review that User Story don't have dependency on other User Stories
7. User Stories enough for next 2 Sprints will be groomed in this session
8. It is recommended that Development Team review the Product Backlog Items 24 hours prior to Backlog Grooming meeting.

ScrumBut

Many organizations try to implement Scrum but unless they adopt Scrum completely they don't achieve the success what they are expecting by implementing Scrum. Many times ScrumButs are the reasons why teams can't take the full advantage of Scrum to solve their problems and realize the full benefits of product development using Scrum.  

In Scrum every Role, Event or a Timebox is designed to provide the desired benefits and address predictable problems. Sometimes organization implement Scrum but with certain modifications to Scrum Roles, Events or Timeboxes; because of some organizational challenges. In this scenario, organizations are implementing Scrum but with modifications to some of the aspects of Scrum and it is called ScrumBut. 

ScrumBut has a syntax (ScrumBut)(Reason)(Workaround)

Examples

1.  (We are following Scrum but )(sometimes we get ad-hoc requirements,)( so we update the Sprint Backlog in the middle of Sprint and don't achieve the goal of the Sprint)
2. (We are following Scrum but)( some team members are at different location, )(so they don't attend the Daily Scrum Meeting)
3. (We are following Scrum but)( we think Backlog Grooming Session is a waste of time, )(so we don't do Backlog Grooming Sessions)
4. (We are following Scrum but )( team members are very busy in doing assigned tasks, )( so they don't update hours remaining on daily basis)

As mentioned above, each of the Scrum Roles or Events has certain purpose and if you tweak it for your project situation then you won't get full benefits of Scrum. So it is recommended to implement Scrum by avoiding any of the ScrumButs.

Definition of Done Vs an Acceptance Criteria

Since long there was a confusion in my mind regarding Definition of Done and the Acceptance Criteria. I was thinking that Definition of Done is same as an Acceptance Criteria. But recently I was going through some videos on Scrum and in one of the videos this difference is explained beautifully.

Last week I started working with a project practicing Scrum since couple of years and I asked the team if they know the difference between these two terms. I found out that they were also thinking that both these terms have same meaning.

So what is DoD and how it is different from an Acceptance Criteria? Definition of Done is a list of requirements that a user story must adhere to for the team to call it complete. While the Acceptance Criteria of a User Story consist of set of Test Scenarios that are to be met to confirm that the software is working as expected. The difference between these two is that the DoD is common for all the User Stories whereas the Acceptance Criteria is applicable to specific User Story. Acceptance Criteria of each User Story will be different based on the requirements of that User Story. In order to complete the User Story; both DoD and Acceptance Criteria must be met. Unless both these two lists are done the Product Increment is not complete.

Before the start of the Sprint the Product Owner and the Team should agree on Definition of Done. DoD should not be changed during the Sprint. If changes need to be done then it should be done between Sprints.

To understand these terms better let's see the examples of Definition of Done and the Acceptance Criteria

Definition of Done

• Code Builds without error warning 
• Code is Unit Tested
• Code is Deployed to system test environment and passed system tests
• Build pushed to demo server 
• Remaining hours of the User Story are marked zero

Acceptance Criteria

•  A user cannot submit a form without completing all the mandatory fields
• Information from the form is stored in the registrations database
• Payment can be made via credit card
• An acknowledgment email is sent to the user after submitting the form

I would suggest that each user story should have both the DoD and AC as a check box list and the developer should check all the check boxes for both the lists before that user story is marked as complete.