by clicking on the page. A slider will appear, allowing you to adjust your zoom level. Return to the original size by clicking on the page again.
the page around when zoomed in by dragging it.
the zoom using the slider on the top right.
by clicking on the zoomed-in page.
by entering text in the search field and click on "In This Issue" or "All Issues" to search the current issue or the archive of back issues respectively.
by clicking on thumbnails to select pages, and then press the print button.
this publication and page.
displays a table of sections with thumbnails and descriptions.
displays thumbnails of every page in the issue. Click on a page to jump.
allows you to browse through every available issue.
GCN : April 2015
OVER THE LAST DECADE, many have written about what agile software develop- ment offers to government IT. Effective practices for making agile work in the federal government were outlined in report from the Government Accountability Office and in the U.S . Digital Services Playbook. Yet while government IT has improved, it has a long way to go. We witnessed the spectacular failure of the initial rollout of Health- Care.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. 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 effec- tively. 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, as- serting key principles without prescribing how to accom- plish them. There is nothing about sprints, Product Own- ers, formal planning meet- ings or any of the ceremony associated with Scrum. Based on the lean manufactur- ing model espoused by the “Toyota Way,” Kanban is in a way a superset of Scrum. Depending on whom you ask, Kanban has five proper- ties or six practices, but I prefer to follow the example of Marcus Hammarberg and Joakim Sunden and focus on three objectives. VISUALIZE WORK Analogous to the Sprint Back- log in Scrum, a Kanban board is an information radiator that conveys the 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 ar- ranged in columns indicat- ing where they fall in the workflow. A typical column set from left to right might have these columns: ToDo, Analysis, Development, Test- ing, Acceptance, Deployment and 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 demon- strates unequivocally where everything is in the workflow and reveals potential bottle- necks. 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 pro- cess at the same time. Large chunks simply bog down the whole system. When you force the team to tackle too many tasks simul- taneously, it leads to context switching, mistakes, more work to correct those mis- takes 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, test- ing, continuous integration, cross-functional teams and splitting work into manage- able, similarly-sized chunks eliminate waste. The Kanban board helps identify blockers as cards accumulate in vari- ous 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 objec- tives, but it takes a formal- ized, sprint-centric approach to address flow. Scrum also focuses more on team inter- action when doing the work than on the work itself. Perhaps those in govern- ment IT intimidated by the rigor of Scrum should focus on optimizing workf low di- rectly and give Kanban a try. • — Neil A. Chaudhuri is founder and president of Vidya. BY NEIL CHAUDHURI INDUSTRY INSIGHT Struggling with Scrum? Try Kanban for IT projects IT managers struggling with the rigor of Scrum should focus on optimizing workflow directly and give Kanban a try. 20 GCN APRIL 2015 • GCN.COM 0415gcn_020.indd 20 3/30/15 11:31 AM