This post is just going to get us through the morning sessions. So… next up I’ll summarize sessions from Jim Sutton and Sterling Mortensen. We’ll pick up Amit Rathore in the next post…
James Sutton: Let Lean be Lean, Let Agile be Agile, and Ever the Twain Shall Meet
James Sutton is the other author of the book “Lean Software Strategies: Proven Strategies for Managers and Developers”. He is a systems engineer at Lockheed Martin, and much like Middleton, is not really an agile guy. Jim is bringing a very structured, large company, systems engineering approach to the conference. His voice is very welcome. This talk was so dense with information… it is going to be very hard to summarize. I understand that InfoQ is recording the sessions and will post them to their site… this is one that you’ll want to find a take a listen.
Sutton says that his goal is the save the middle class in the US and he is not kidding. Jim believes that if we lose industry… if it all goes overseas… we will no longer have jobs in the US. His fundamental paradigm is that business in the West is focused on a unit cost model and that this way of thinking is killing us. As you might expect that his focus is on value streams and optimizing flow through the system. Jim starts his talk with some stats on the efficacy of various software models… he makes the case that agile is good and has value but that lean can improve productivity by 400% and quality by over 1000%.
After setting up the problem, Jim gives us some background on Demming and lays out the philosphical underpinnings of lean thinking. He emphasizes that while there are lean practices… lean is more of a mental model… a way about thinking about systems and organizations and a fundamental disposition to put people first. Jim goes on to talk about Demming’s system of profound knowledge, systems thinking, and suboptimization. One of the most interesting comments in the talk was the distinction that lean introduces science into the idea of systems optimization where agile focuses more on how optimization emerges from the team.
After lots more talk around these ideas, Jim encourages us to take the tools of agile… and the tools of lean… to do the right amount of planning… but balanced with the legitimate need to just get started. I appreciated Jim’s perspective that agile and lean are complementary worldviews and that we need to evaluate our particular context to decide what elements of each that we need to implement. All in all a very valuable talk.
Sterling Mortensen: A Case Study, Hewlett Packard LaserJet Development
Okay… this is going to kill me. Every one of these speakers so far has been absolutely fantastic. I was thinking that this talk from Sterling Moretensen would be pretty dry… after all we are talking a case study here. I am pleasantly surprised once again to find myself with way more information than I am ever going to be able to report on. The takeaway density of these talks is really through the roof.
Sterling starts his talk explaining the situation he faced at Hewlett Packard. The number of products were growing rapidly… products were getting more complex… the number of features were growing rapidly… all while they were moving to a common, shared services type software platform. Things got so complicated… there was so much work in progress… the organization could not do anything and defect densisty was through the roof. Like most of the other talks we are hearing today… HP solved the problem through the application of lean and agile principles.
Sterling’s teams focused on small batch sizes… trying to deliver smaller features… and focused on delivering them on a fixed cadence. What they found was that by taking work out of the system… by reducing complexity… they were able to unstick the organziation and actually get features delivered. They found that as complexity goes down… productivity goes up. By delivering in a fixed cadence… by decreasing the time it took to get feedback… quality actually went up.
Many managers… especially Marketing managers (little jab there)… think that the more features you put in the queue… the faster work will come out. The metaphor is that of a hydraulic system. What HP found was that the development team was more like a highway… more cars don’t increase flow… they increase complexity… and the flow of value actually goes down. Taking work out of the system… focusing on done….reducing cycle time and feedback loops all dramiticaly increased overall system performance. We need to stop starting work and start finishing work.
My favorite quote of the talk said something like… if you optimize all the parts of a system, the system is not optimized. If you optimize the system itself… only a single part will ever be optmized. Said another way… in an optimized system you will only ever have ONE single part optimized. That is so counter-intuitive to most folks. Again… I appreciated Sterlings acknowledgement that agile and lean are very complimentary approaches to software development… that teams and iterations can have a place in a lean framwork…. and that it takes good engineering practices to really achieve the flexibility and productivity that agile and lean promise.
Overall a great talk… really appreciated Sterling’s contribution.
Comment (1)
Jean Tabaka
Mike, thanks for capturing James’s and Sterling’s talks! They were both brilliant! After listening to Jim, I went back and started re-reading a book on Dr. Deming by Rafael Aguayo. I highly recommend it, especially since Dr. Deming was invoked multiple times during the two, all too short, days. Jim’s eagerness to save the middle class and tying it in with Deming’s guidance is a compelling one. Why is it the American market overall doesn’t grasp Deming’s guidance and hence seeks “Fixes that Fail” (offshoring) in order to “succeed”? I think it goes to that fundamental failure to embrace systems thinking, seeing the whole, and paying attention to unintended consequences that arise when we maintain a narrow, here-and-now, focus.
That is one of the reasons I was intrigued by and questioning how the Kanban continuous improvement principle/policy moves from day-to-day decisions to long term trending in the larger system. I think the answer lies in Jim’s comment about Lean bringing “science” into the system optimization, while Agile focuses optimization emerging from the team. As we adopt Kanban, I fervently hope that we seek both the science and the team optimization lessons.
Thanks!
Jean