Kanban vs.JIRA

Some time again I wrote a post, SCRUM vs. JIRA, where I tried to reflect on the difference between the SCRUM and the JIRA project model. Here I argued that SCRUM was based on a number of somewhat fragile preconditions, which made it very difficult to complete sprints successfully. The JIRA model on the other hand is a more 'fundamental', methology neutral breakdown of a projects dynamic aspects, and therefore much more robust basis for a project, where higher order project management frameworks like SCRUM, XP, Unified process, etc can be added.

Now let's take a look at Kanban, which has been recently appeared as a software development framework, to address some of the challenges Scrum is facing. Many of the Scrum related concerns mentioned in the motivation for introducing Kanban corresponds to the list of fragile preconditions I have listed in the SCRUM vs. JIRA posting. Just as I tried to argue in my case for using JIRA as the project model fundation, the Kanban approach to task handling is concerned with focusing on the fundamentals of the development proces, where more ambitious proces frameworks might be constructed (See f.ex Scrum-ban). Let's try to run through the list of Kanban focus areas, and compare these to the task aspects found in JIRA.

• Task processing: In Kanban the central concern is the efficient processing of tasks, that is the pipeline Open -> In progress -> Resolved. JIRA users will recognize this process as the default JIRA workflow, and this is exactly what JIRA basically is, a application for registering and listing issues/tasks as they move though this lifecycle. A lot of higher order concerns may of course also be modelled in JIRA, but this is optional and can grow together with the project methology as the development process matures. In fact in many cases JIRA is introduced just for this purpose, someone in a project/organisation feels a need for a simple tool for registering and listing the things that needs to be handled in a more robust and shareable manor than by using post-its, simple todo tools, mails, etc.
  
• Task exposure: Just as in Scrum, the main visible artifact is the whiteboard (which is the original meaning of Kanban by the way) containing the tasks which are currently being processed. This functions as the task model 'altar' we gather around, synchronize our views of the projects and maintain the models together. This corresponds to JIRA collaborative approach to task management, where the project issues are access through a user-friendly website where all project team members can view and contribute to the model. Note: this is in opposition to many of the more conventional task management tools like MS Project, Excel, etc. where the task management is owned and maintained by a Project Manager, with the occasional showing for the rest of the team.
• Task pulling: One of the main differences between Scrum and Kanban, is that Kanban focuses on the team choosing which tasks should be processed next (pulled), compared to Scrums empathize on the product owner defining (push) which tasks should handled first (backlog prioritizing) and handled in the near future (sprint planning). Note, this isn't necessarily in contradiction with each other, the task pull and push mechanisms can coexist on two different levels in the project, task pulling is a daily activity, where task pushing is a done on a longer term basis. The Kanban push approach is again seen in JIRA's collaborative approach to updating the status of tasks, where project members 'pull' issues from the pool of open tasks. Any partitioning or prioritization of the open issue pool is a higher order concern, and isn't necessary for maintaining a working task model.
  
• Minimizing 'In progress' tasks: This isn't really addressed in JIRA, even though JIRA is a very efficient tool for monitoring this, the 'In progress' list is directly accessible from the project portal page. The problem of building a efficient way of resolving tasks in a consistent and predictable manor, is one of the core software development challenges which Kanban centers around. The mechanisms for handling issue resolution must be found in other tools and human work process, but are crucial for achieving any kind of project success, and certainly for any hope of extending the development process with any kind of more advanced project management methologies (like Scrum).
  

Now let's take a look at the problematic preconditions I listed in the SCRUM vs. JIRA post and see how Kanban performs compared to Scrum.

• Stable team: The impact on a Kanban project because of a unstable team is much smaller than on a Scrum project, because a Kanban team doesn't need to concern itself with the sprints failing. The number of tasks processing may become slower, but this is not necessary a problem in Kanban, the decreased velocity can be addressed on a continual basis by adjusting the amount of work in progress. The ability to process tasks may suffer from key competences disappearing from the project in a Kanban project, and might cause difficulty in finishing any tasks in a satisfactory manor, so the Kanban flow might break if this is the case.
  
• Stable sprint backlog: The stability of the backlog isn't a Kanban concern, because no predictions is made on when chucks of functionality (sprints) are finished.
  
• No external dependencies: Kanban task may of course also depend on external issues, but in Kanban it it much easier to mitigate any problems arising from this, because of the lack of sprints, eg. a task can be rotated out of the 'In progress' pipeline when a 'external block' appears without much interruption to the task processing itself.
  
• Clear goal: Not relevant, a clear goal is not a Kanban concern as this is a sprint/iteration concept.
  
• Small, well estimated tasks: Essential for Kanban, but this is ok as this is a fundamental precondition for building any kind af predictability into a project.
  
• Visual results: Not a Kanban concern, even though it might be a good idea in using this development aspect to assess the task resolution.

As it can be seen, the project requirements needed to get Kanban working efficiently are much more basic than for Scrum, and much closer to the core set of issue management concerns handled in JIRA.

The two constraints which still appear in the Kanban list are that a minimum set of team competences are required and the ability to breakdown work into small, correctly estimated tasks are need. This is pretty much the most basic capabilities you can add to the JIRA issue model, and still get added value in terms of project management. This means that a well-functioning Kanban process is a much more achievable goal than aiming for a Scrum based work process, and will make a robust platform for introducing more advanced methologies, like Scrum. If you on the other hand haven't got the basic issue management aspects addressed in Kanban under control, it will be impossible to get the planning and functionality oriented aspects of Scrum to work, and it will be hard to focus on the real problems in this case, because the symptoms in a Scrum based setup will be much more diverse, hiding the real problems causing the process to break down.

As you might have noticed, I really like Kanban's more basic approach to what lies at the core of good task management (and therefore project management), which introduces a better cause-effect mechanism into software development. This hopefully results in a much improved ability to focus on the projects root causes, compare to more complicated process frameworks.

In a JIRA vs. Kanban context, I also see the issue model found in JIRA much more recognizable in Kanban. This means a good understanding of Kanban and its relation to Scrum, could function as a nice bridge to implementing a smooth 'JIRA -> Kanban -> Scrum -> CMMI focus process' transition as the development process matures (inspired by the process complexity scale found on page 8 of Kanban vs. Scrum).