This presentation was given at the Lean Software and Systems Conference 2012 (LSSC12)
What does Kanban have to say about risk? Some of the answers may surprise you.
Even early on in its implementation, Kanban can help you to recognize certain types of risk quickly and to manage them visually. As the dynamics of your processes are revealed in action, Kanban may prompt changes to the way your work is structured, scheduled and monitored, with clear benefits in process performance. Less obviously, Kanban may challenge deeply-held assumptions about when, where and by whom risk should be managed, perhaps with wide implications for your organization. Most surprisingly of all, Kanban may encourage you to embrace certain types of risk, both to improve your process capability and to help achieve better results from the systems you build and maintain.
This presentation was given at the Lean Software and Systems Conference 2012 (LSSC12).
Lean initiatives start out strong, with healthy principles and exciting rhetoric. But we still run into issues along the way - people become bottlenecks, teams wage war against other teams, deadline pressures make us break our WIP, blame still rears its ugly head. Why do these still happen to allegedly enlightened lean teams? What happens when our lean team fights with other non-lean teams? Why do we instinctively keep promising deliverables by certain dates - even when we know we can't reliably do so? Jim Benson discusses the fetid underpinnings of the human psyche and how knowledge workers are extremely susceptible to them.
Early adopters of Kanban in the IT services realm are designing systems which consider high levels of interrupt driven work and big differences in task size. This work doesn't typically drive revenue and thus creates unique challenges. Add to that, the conundrum of handling dependencies, distributed teams, and shared resources, a kanban design for IT Ops may look very different than a Kanban design for development. This talk covers real world examples from IT teams working to optimize the whole of their organization.
When the Wright brothers flew their first plane, one of their key inventions was the ability to change the shape of the wings in flight, so as to steer the plane and keep it aloft. At first all of the control was done by the pilot, but feedback control systems were soon developed to automatically simulate a good pilot’s actions. When the first cars rolled off of Henry Ford’s automotive assembly line, they were made with thick, uneven sheet metal made with manually controlled processes. But feedback control systems were rapidly developed that allowed the manufacture of much thinner and more precise sheet metal, leading to lighter, sleeker cars.
As systems increase in complexity, feedback control systems have always been developed to manage that complexity. In our world of developing complex software-intensive systems, we have recently arrived at the stage of Wright brothers were during their early flights – we can now design our systems so that we can modify them in flight, observe the results, then manually make corrections.
This talk is about using feedback control to radically improve the process of developing of software-intensive systems. It covers:
Continuous Delivery: A surge in organizations engaged in continuous delivery (weekly, daily, or more frequently) has changed the development game from iterations to flow, and from intermediary product “owners” to sending system-level feedback directly to the technical team.
Continuous Design: Continuous delivery requires the ability to continuously take the feedback into account and adjust the software content accordingly. Instead of designing features based on speculation, system development decisions are based on real data – for example, A/B testing, Cohort analysis, etc.
Continuous Demand Management: One of the biggest problems development managers face is demand management – and resolving this problem is fundamentally about the ability to match demand to capability. A rapid full-system feedback control loop is increasingly practical, and is a very effective way to manage demand.
Continuous Progress: Recent research has shown that the most potent motivator, the one that gets people deeply engaged in their work is not incentives, not goals, not even teams. The most effective motivator of knowledge workers is: making progress in meaningful work. Continuous delivery and design put members of the technical team in direct contact with the end result of their work – making the work more meaningful and progress highly visible.
Continuous Experimentation: Research also shows that the most successful organizations are those that take a disciplined, empirical approach to improving business processes – questioning conventional wisdom and experimenting to find out what works. This includes questioning the conventional wisdom behind approaches to developing software-intensive systems – including agile and lean approaches.