6 April 2017
Software development processes have been written about, hotly debated on, and explored thoroughly for several years. Over time, Agile became mainstream, all types of online Kanban boards sprung up, and dozens of Scrum books were published every year. Somewhere along the way, the conversations started to centre around rituals. The focus of debates shifted to appropriate durations for standups, the sanctity of estimation techniques, how to plan projects to every last detail, and much more. So much so, that the rituals came to be seen as a part of the framework. I see that the teams often commit to a framework or a practice with such enthusiasm that they follow it blindly to the depths of misery and unproductivity.
The way I look at it, is that each method (Agile or Scrum or Kanban) is a set of principles. There’s no reason why we can’t adopt one or more of these principles to our current method of working. Having the whole team move to an entirely new method is often unnecessary, when we can make simple, small changes instead. This blog series attempts to resurface the fundamentals of software development methods and the intent with which they were created, and tries to rescue us from the quagmire of prescriptive rituals and processes that teams seem to be drowning in today.
We have to start somewhere, so let’s start with exploring the principles of Kanban.
Kanban (Japanese for “signboard”) has interesting origins in the world of manufacturing and inventory control. Toyota developed a production system to balance supply of automobiles based on demand, while keeping the production line running at all times. The fundamental idea is that manufacturing works on a ‘pull system’; When a piece of inventory is sold, then production and shipment of another piece begins. A product begins its journey in the process only when inventory needs to be replenished. New items are pulled into the next stage only when the number of items in that stage has dropped to below a limit i.e. when there is a void to fill.
David Anderson’s book, Kanban, made the application of these five principles in software development very popular. While we examine how these are used, we’ll use Mingle’s Kanban template for reference.
You’ll notice in the Kanban template that there is only one type of work – Work. This is in stark contrast to, say, Scrum, where work is classified as Stories, Defects, Tasks and more. Kanban believes that all work is fundamentally the same and needs to be done. Work flows through the system all the time, and does not necessarily need to be confined to time slots such as Sprints, Iterations and Releases.
In the same vein, Kanban does not define what roles are essential on the team. Anybody who does work and keeps work flowing is useful – there are no explicit role definitions that the framework imposes.
Kanban believes in keeping the workflow simple. At any time, work is in one of three stages – Yet to be worked on, in progress, and completed (To Do, Doing and Done). All work flows through these stages in order. Once work is Done, any new work that is discovered (feedback, defects, enhancements) are treated as new work cards and are put in To Do. That means work never moves backwards in Kanban – the workflow is one way only, towards Done.
However, Kanban does not inflict a fixed workflow. While keeping the workflow simple is recommended, Kanban suggests periodically looking at how the workflow is working for the team, and making small tweaks that may be helpful. This is called Kaizen – continuous small improvements.
It is also important to note that, in order to keep work flowing and prevent bottlenecks, team members are encouraged to be role-agnostic. Team members should not be assigned to handle work in a particular stage, but should focus on getting work all the way to Done. Should a work card be stuck in a stage, any member of the team can be assigned to move it through.
Toyota’s inventory control problem was solved by limiting the number of items in any stage of the production and distribution system. This is an application of the Theory of Constraints – any system is more likely to meet its goals when limited by a small number of constraints.
Limiting work in progress (Doing) brings focus to the work in play. Typically, software development teams limit the number of work items in progress to the number of developers or developer pairs on the team. This 1:1 ratio of work to people doing the work ensures that their whole focus is on getting the work done. New work may be pulled into Doing only if a work item has moved to Done. This ensures that work flows constantly through the flow, and any blockers are immediately addressed. The underlying rule is to stop starting and start finishing.
Further, limiting work in progress (setting WIP limits) compels the team to prioritise what work to pull into Doing next. Only one item can move to replace the item that moved to Done, and the team makes a call on what is most important at the time.
I was deeply influenced by this principle; it is no coincidence that Mingle now supports WIP limits. This is a recent addition to the tool, and it can be used with any project, even if you don’t use the Kanban template. If you want to give the Theory of Constraints a go and make throughput of work better, set up WIP limits on your team’s board.
Tracking progress can be tricky on busy teams. Project managers who are keen on finding out how much work is left and where the bottlenecks are could use the Cumulative Flow graph: a simple way to track and report progress. By plotting the number of tasks in each stage of the workflow against time, we can see what the current status is of the project. For any day on the X-axis, we can easily see how much work is done, how much is in play, and how much is left to do.
When tasks accumulate on a certain coloured band on this graph, it points at a bottleneck in that part of the workflow and should immediately be addressed. It helps analyse the cycle time of work, and points out the stages that take most time.
I believe that Kanban is the simplest method to adopt. A fundamental ethic is that it respects the current process and set of roles. It advises that the team continue with what they do now, and introduce small incremental changes to the process. The aim is to make work flow through as quickly as possible, and all tweaks made to the process should target this. A good way to track whether progress is being made towards this goal is to use the flow efficiency metric. This tracks how much of the total lead time on a piece of work was spent on actively working on it.
When this number is low, it means that “work” is spending too much time waiting for someone to begin on it. Reducing wait time on cards drastically improves the flow efficiency.
Kanban is a wonderful, simple system for teams that want to get work done quickly. We use Kanban on the Mingle team (our workflow is To Do → Doing → Ready for Sign Off → In Production), and we’ve seen a lot of success with it (especially with our recent Mingle + Slack feature releases). Shoot us any questions you might have and we’d love to chat!
Even if you aren’t practising Kanban on your team, don’t hesitate from using one or more of the principles to help your throughput get better! That’s exactly why, in Mingle, you could choose to use WIP limits, the Cumulative Flow graph and the Work card type in any project, regardless of which template you’ve used (or even if you haven’t used a template). If you’d like help, do reach out.
In upcoming posts, we’ll explore Scrum and Agile, and look at the principles behind them that made them so popular. Stay tuned!