#LK2009 Rathore and Ladas

 

Amit is a former consultant for ThoughtWorks but currently works for a small startup in the financial services industry.  David Anderson gave Amit a glowing introduction explaining that he is an excellent blogger… has figured all this out based on first principles… and that he really gets this stuff.  This talk is based on Amits learning and was really structured like an experience report based on his own personal experience.

 

Amit starts his talk by explaining that startups are defined by their constraints.  Startups have less money, less people, little domain knowledge, constant change, fewer customers, and not so many chances to be successful.  For a small startup, t is always a recession.  It is essential in this environment that you eliminate waste at every step of the value chain.  Speed is the only advantage that a startup has.  

 

Amit goes on to talk about how process, systems thinking, technology, culture, and people all have to work together.  Constant change is the norm so startups have to understand the flow from idea all the way to production.  You have to understand the relationship between the sales person all the way through the development process.  Things are going to change so we have to be as flexible as possible for as long as possible.  Amit introduced the idea of progressive elaboration all the way from idea to implementation.

 

His team uses set based engineering… does not estimate… breaks features into stories that can be implementated in a day or so.  A startup is so subject to daily change… it does not make sense to commit more than a day or so out.  Estimating features and preplaning… even sprint planning… is subordinated to establishing flow… establishing a steady throughput across the entire organization.   

 

This talk was a really interesting counterpoint to some of the stuff presented by Dean Leffingwell and Jim Sutton earlier in the day.  These guys were talking about using lean across the technology organization to coordinate activities across multiple teams required to deliver a higher order feature.  The ideas certainly apply across the entire value chain… but managing flow in a technically complex organization seemed to be the main message.

 

Amit is focusing on a much smaller… much more dynamic and flexible software organizations… organizations that are much more subject to frequent change.  He introduces more directly the idea of managing value streams across the entire organization.  Frequent delivery is key… Amit encouraged the audience to reduce batch sizes and deliver often.  If you are going to fail in a startup… you need to fail fast and adjust quickly.  Reduce cycle time and get feedback as soon as possible so you can get more done with much less.

 

 

I am starting to sound like a broken record, but pretty much everything Corey said during this talk was worth writing down.  Let me see if I can distill a few of the ideas around Scrum-ban… a blending of the ideas of Scrum with the ideas around Kanban.  One of the most interesting things that Corey had to say was that Kanban is not a process any more than a backlog is a process. Kanban is a tool that can be used in a particular context… to derive a particular value.

Kanban is built around the idea of a Kanban card.  The card can be thought of as a user story… a use case… a scenario… or a feature; something that adds value to the business.  The way Corey explains this is very similar to the way I think about a user story… something small and discrete that can be delivered within the context of a single iteration or sprint.  The idea is that the Kanban cards are tracked through the various states of development within the sprint… analysis, design, code, and test… but that we put limits on the number of cards that can be in any given state at any given time.    

 

Whereas scrum attempts to limit this work in progress implicitly by encouraging the team to finsih work as soon as possible… Kanban handles this explicitly by setting management control around how many cards can live in any one state.  It provides an empirical method for managing the flow of work throught the team… and a way for teams to collect data and understand opportunities within the team to get better.  It puts some teeth around the idea of inspection and adaptation… it gives us some data to understand where we have weaknesses… where we can improve… and how we can deliver working software faster.

 

The interesting thing about Corey’s perspectve here… is that by introducing Kanban within the sprint… we can ultimately find that we no longer need the sprint boundares.  We can go iterationless and start thinking about continuous flow through the development team.  Even more interestng… you can now break the hold of the single product owner managing the backlog and think about flow outside the organization as well.  

 

If you read my blog… you’ll know that I have been on a rant lately about the role of the Product Owner and how it is an insufficient metaphor for the complexities of the business. Kanban and Lean can extend the single piece flow idea out to the business and take a look at the entire value stream from idea… to customer delivery… to support and operations.  

So… my main takeaway was that Kanban can be used within the Scrum sprint to help teams manage their constraints within the normal sprint planning, sprint execution, and sprint closedown processes.   Once we have maturity, and a but of data, around how effectively we build software… we can then consider breaking the boundaries of the timebox and go toward a continuous flow.