Struggling with Scrum? Try Kanban for IT projects
Connecting state and local government leaders
IT managers struggling with the rigor of Scrum should focus on optimizing workflow directly and give Kanban a try.
Over the last decade, many have written about what agile software development offers to government IT. Effective practices for making agile work in the federal government were outlined in a report from the Government Accountability Office (to which I was a contributor) and in the U.S. Digital Services Playbook, which I wrote about for GCN.
Yet while government IT has improved, it has a long way to go. We witnessed the spectacular failure of the initial rollout of HealthCare.gov, and many far less visible failures happen all the time. One reason is that not enough government IT projects are agile. Another is that Scrum, the most popular agile framework, is hard.
In fact Scrum is so hard that the primary duty of the ScrumMaster is to serve as its guardian. Too often senior management pays lip service but does not make the commitment necessary for Scrum to succeed; even if it does, too often the team lacks the discipline to see it through.
Although I am certified in Scrum and teach a Scrum course, I am not so dogmatic as to ignore how hard it is to execute effectively. Thankfully, it isn’t our only hope. As Yoda once said, “There is another.”
Let’s examine why Kanban may in many cases be a better choice for government IT projects than Scrum.
Scrum is a process. Kanban is more of a metaprocess, asserting key principles without prescribing how to accomplish them. There is nothing about sprints, Product Owners, formal planning meetings or any of the ceremony associated with Scrum. Based on the lean manufacturing model espoused by the “Toyota Way,” Kanban is in a way a superset of Scrum.
Depending on whom you ask, Kanban has five properties or six practices, but I prefer to follow the example of Marcus Hammarberg and Joakim Sundén and focus on three objectives.
Visualize work
Analogous to the Sprint Backlog in Scrum, a Kanban board is an information radiator that conveys your workflow in an explicit way. Each item of work is represented by an index card or Post-it color coded to the type of work (e.g. new feature, bug, etc.) with a short description, a deadline, the team member who has pulled the work and other pertinent information.
The work items are arranged in columns indicating where they fall in the workflow. A typical column set from left to right might have these columns:
- ToDo
- Analysis
- Development
- Testing
- Acceptance
- Deployment
- Production
A Fast Track column could be added for urgent work items that arise. Another useful tidbit might be criteria for exiting a stage in the workflow. For example, what makes code ready for testing?
The Kanban board demonstrates unequivocally where everything is in your workflow. It also reveals potential bottlenecks where you may wish to apply the Theory of Constraints. The board can even reveal steps you weren’t even aware exist.
Limit work in process
Queuing Theory offers insight into reducing the cycle time for an item in your workflow. In particular, Little’s Law states cycle time is the quotient of work in process and throughput. In other words, to speed up the flow, you need to limit work in process and/or increase productivity. The latter will happen with automation, training and familiarity with the work. Meanwhile, you should make sure as few items as possible are in process at the same time. Large chunks simply bog down the whole system. Ponder that while sitting in traffic or waiting in line at the grocery store.
Work in process in software development takes many forms:
- Code not under version control
- Code not tested
- Code not in production
- Code not working (bugs)
When you force the team to tackle too many tasks simultaneously, it leads to context switching, mistakes, more work to correct those mistakes and ultimately delays.
Manage flow
Limiting work in process is a key component to managing flow, but a related element is eliminating waste.
Lean experts Mary and Tom Poppendieck identified seven wastes of software development analogous to wastes in manufacturing. Those familiar with Scrum know source control, testing, continuous integration, cross-functional teams and splitting work into manageable, similarly-sized chunks eliminate waste. The Kanban board helps identify blockers as cards accumulate in various columns.
Also avoid open-ended commitments. Deadlines make you focus. In Scrum, timeboxes are built-in with fixed sprints during which the team delivers the highest-priority features. Kanban has no sprints, but you should impose timeboxes in the form of deadlines and service-level agreements.
Scrum is just as focused on meeting these three objectives, but it takes a formalized, sprint-centric approach to address flow. Scrum also focuses more on team interaction when doing the work than on the work itself.
Perhaps those in government IT intimidated by the rigor of Scrum should focus on optimizing workflow directly and give Kanban a try.
NEXT STORY: NHTSA crash data upgrade slowed by tight budgets