#LK2009 Shalloway, Leffingwell, and Middleton

I’ve been down in Miami all week at the Lean/Kanban Conference. The conference didn’t actually start until today but I came down early to participate in a few meetings and ended up having a voice in the future of the Lean/Kanban movement… more on that in a moment. For now… I want to let you in on what’s going on down here… why it is important… and maybe… just maybe… give you a few anchor points for our discussion on scaling agile in the enterprise.

Alan Shalloway: Opening Remarks

Alan Shalloway got the conference going with a few opening remarks around what’s getting him excited about the lean movement. When agile was introduced it opened up new possibilities for how we write software. Lean represents a similar paradigm shift in the software community. Alan is a scientist at his core and appreciates the science behind lean and is pretty geeked on the idea of utilization theory… options theory… and flow theory. Lean will give software practitioners a scientific language to describe the process of creating software.

Alan announced the creation of a new organization to support the lean community. The organization is called the Lean Software and Systems Consortium… creating this organization was the reason for the pre-conference meetings.

The Lean Software and Systems Consortium will support the lean community by gathering a body of knowledge, establishing a set of competencies, creating a new certification for practitioners, and reaching out to business and academia for accountability, support, and feedback. The consortium will support an annual conference and a multi-tiered membership model. Speaking of the annual conference… the next one will be in Atlanta in 2010… venue to be announced.

Dean Leffingwell (Opening Keynote): A Lean and Scalable Requirements Information Model for Agile Enterprises

I’ve been a big fan of Dean Leffingwell for a while now. His book Scaling Software Agility is probably the most clear… well reasoned explanation of doing agile at scale that I have ever read. As we’ve been exploring here for the past few months… agile at scale is not a trivial problem… and that means the solutions are not likely to be trivial either.

Dean starts his keynote by explaining some of the basics of agile software development and why certain practices break down when you start to scale. He addressed some ‘controversial’ ideas like agile architecture, component teams, and managing dependencies across multiple agile teams. His talk leverages pretty heavily his recent work on a Lean Scalable Requirements Model but never really got into the Lean concepts that are required to make it all work.

During the Q and A session, Dean began to address the idea of creating a pull system to drive requirements across the team of teams concept. I totally agree with Dean’s approach and really respect his work. You are going to see me explore some of these ideas over the next few weeks in my blog posts. That said… I think his keynote missed an opportunity to directly link lean into his lean agile requirements model. Dean’s explanation of his model brought up issues that many in the software development community really needed to hear and he delivered a great talk.

Peter Middleton: Lean Software Development, Achieving Better Requirements

Peter Middleton is the co-author of “Lean Software Strategies: Proven Strategies for Managers and Developers”. He is an academic at the Queens University in Belfast and has been researching Lean for the past 20 years. Peter writes about how lean will have an impact on the software community going forward.

Peter’s talk starts with the fundamental assumptions of agile… agile methodologies assume that there is a high level of noise in the system… that requirements are evolving… technologies are evolving… and we just need to do something to make progress in the face of uncertainty. Peter’s perspective is that this is a flawed paradigm… he postulates that the reason we don’t understand our requirements is because we don’t understand our purpose.

The talk focused on the idea that much of our problems with software requirements is that we have too much noise in the system.

Lean can help us reduce that noise by identifying our failure modes and improving them first. Middleton says that we should focus on what delivers value to our customer and work to optimize that value delivery. Getting there is a non-trivial problem… it involves reducing variability in the process… establishing the correct measures, constraints, and context… making sure your KPIs drive the right organizational behavior.

Taking the noise out of the system helps our requirements become more stable. Cleaning up the noise will help you improve performance but getting people to see this is the real challenge. Many folks have quite a bit invested in the status quo. To lead change you have to take a more indirect approach. As change agents we have to design an experience that lets the leadership team see the problems for themselves. Software is often not the problem… we need to address the bigger constraints in the system.