Interview: Alan Shalloway on Lean Agile Software Development, Part One
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
Today I'm privileged to share with you the first portion of an interview that I conducted with Alan Shalloway (part two will run on Thursday). I first encountered Alan while searching for podcasts on agility. I luckily stumbled upon "Lean Agile Straight Talk," on which he regularly appears with his colleague, Jim Trott.
Matt: So Alan, why don't you introduce yourself briefly to our readers?
Alan: Thanks. I’m CEO of Net Objectives and live in Seattle, WA. We’re committed to providing the latest methods and services to assist people in being more effective in their software development. This includes better focus by the business side of the organization, effective agile methods and coding by the team and supportive management to enable it all to tie together.
Matt: You recently published a book along with your colleagues entitled Lean Agile Software Development: Achieving Enterprise Agility. What were you hoping to accomplish with this book?
Alan: The book discusses the methods we’ve used to achieve enterprise agility at a number of our clients. Most of our clients started with Scrum and then called us in when their initiatives stalled. It is unfortunate that most people consider Scrum to always be the Agile method to start with. The book is intended to serve two purposes – first, to introduce lean-thinking and how it applies to Agile software development and second, to show how this alternative approach works at the enterprise level, solving challenges Scrum has had difficulty achieving.
Matt: What exactly is "Lean Agile" as opposed to simply "Agile?"
Alan: Agile as it is usually described is team-centric and is fairly lightweight. I sometimes feel it has been an over-reaction to poor and/or oppressive management. Unfortunately, we’ve established a belief that lightweight is good. I prefer “right-weight.” My belief is that Lean-Thinking is essential to all but the smallest software development organizations (and even userful there). So Lean-Agile means to be doing Agile within the context of lean-thinking.
You can think of lean-thinking as having a context of optimizing the whole value stream – from idea to consumption. We’re not attempting to merely get team agility. Instead, our focus in on enterprise agility – that is, the ability for the enterprise to respond quickly. I liken agile to being about the engine while Lean-Agile is about the entire car. But just saying you’re going to look at the enterprise is not enough. You need a different approach. Lean-Agile recognizes that there are many principles that must be attended to in order to be effective. In particular, one must understand the laws of product development flow. In particular, too much work creates extra, unnecessary work (waste in some people’s vernacular). These laws help guide us in how to do product portfolio management and how teams must work together. It gives us ways of working both top-down for vision and bottom-up for efficiency. Many agilists act as if management must stand back and only help teams when they ask for it. Lean-Agile includes management by providing a way for them to coach and lead teams without micro-management.
Matt: You've repeatedly asserted that there isn't one best method for developing software and that organizations must select the method that is best for their own contexts. How do we do that?
Alan: First, that there these isn’t one best method should be self-evident. No one-size fits all. So why would we expect any prescriptive method to work everywhere? Another difference between Lean and Agile is that Lean includes principles of how things work as well as values. Most Agile methods are based on values and practices and therefore work in many situations but in many others you’ve got to play it by ear. Lean provides guidance in providing you principles to use. For example, Lean suggests shortening the cycle time of development will increase quality while dropping cost. Thus, one can use this as guidance for how to do one’s work. When selecting what to do, one must recognize that more important than the practices you do, you must make sure your beliefs, or mindset, matches the reality of your situation. I talk about this in great length in my recent blog “The Real Differences between Kanban and Scrum.”
Many in the Agile community have resisted the notion of laws like this existing. I suspect it smacks too much of over-bearing process. I liken using the laws of product development flow to assist our developing software to the way NASA scientists used the laws of gravity to assist them in putting a man on the moon in the 60s. Unfortunately, many in the Agile community still doubt whether such laws exist.
Matt: And yet you seem to be recommending Kanban over Scrum for the majority of organizations. Why is that?
Alan: Actually, this isn’t quite true, but I understand the way I’ve discussed this makes it sound like I’ve been saying this. I would say I typically recommend Lean-Agile over Scrum. But Kanban is actually a change management system that uses lean-thinking to implement it. It enables organizations to control how much change they undergo. Ironically, you can apply Kanban to Scrum, adding work in progress (WIP) limits to make your Scrum practices more effective. Thus, from a method point of view, I would say that I endorse Lean-Agile over Scrum, and then from a practices point of view I would suggest that the team do Scrum’s iterative practices or the flow based practices of Kanban as necessary. All this being said, I would suggest that I do believe there is a mindset difference between Kanban and Scrum and that I always prefer the Kanban mindset, which says "look to see how much you can change an organization at any one time." Merely jumping in and following prescribed practices to start with is often a bad idea.
From a practical point of view there are situations where Scrum either does not work or does not address the key problems, whereas Kanban does. Companies that have the right organizational structure for Scrum have mostly already adopted Scrum. Those with challenges not conducive for Scrum to solve are trying to adopt Agile now, but Scrum doesn’t always fit.
Matt: What situations are you talking about?
Alan: Scrum mandates that you have self-organizing, cross-functional teams working on one project at a time. If you have a matrixed organization with highly specialized skill-sets and too many projects underway, this is an incredibly difficult challenge. Scrum’s simple model, while exposing many of these impediments, doesn’t explain the challenges causing them nor the solutions required. Kanban, with its mandate to limit WIP, will provide insights and a step-by-step method for improvement.
Look for part two of this interview on Thursday, July 15!