In the interview below, Mik Kersten, CEO of Taskop Technologies in Vancouver, discusses his own company's experiences with lean's principles in their quest to reach enterprise agility. Mik explains the differences between those two terms, and offers suggestions for companies looking to make productive changes across their own enterprise.
Noel: How long have you been working with lean’s principles, and what was the hardest principle to achieve when you first got started?
Mik: It was 1999 and I was on the AspectJ team at Xerox PARC. We were already running on short iterations. Then Kent Beck’s XP book came along, which we all got very excited about. Since everyone on the team was very motivated to apply it, the principles were easy to adopt. It was the lack of tools that caused problems. At the planning meetings some folks used physical cards, some were remote so they showed slides for their cards, and I would use Microsoft Project Server tasks, along with our bug database, trying to reconcile all of the sources of planning information. It was a mess, especially because the plans would get out of sync with what was in the bug database during the iteration.
Noel: Outside of the development and testing teams, what departments have you seen struggle with agile and lean’s principles the most, when attempting them for the first time?
Mik: All of them. It’s pitched the wrong way. DevOps folks are not overly excited about two week sprints, and neither are business analysts wanting to get their requirements implemented once they’re thrown over the fence, or the PMO who are trying to hold on to five year project plans. We need to start thinking about lean in the big picture of Application Lifecycle Management (ALM), which includes those stakeholders’ varying contexts and necessarily slower cadences.
Noel: How can developers and testers show those who may doubt or struggle with agile/lean that their adoption will truly benefit everyone, and not just themselves?
Mik: By making progress and results visible to the rest of the organization. The previous expectation was that things would magically execute according to plan, and with agile we learned that the plan needed to evolve to incorporate what we learned about the application through the delivery process. That feedback loop needs to circle back to the other stakeholders in order to support organizational learning. For example, business analysts will get a better application for agile when feedback from development informs the evolution of requirements in a feedback cycle and cadence that’s meaningful to their success. And the help desk will get more sense of the value if defects for a release are automatically pushed into knowledge base articles corresponding to a release. It’s time to push think agile across the lifecycle, and that’s what we’ve being calling Lean Software Delivery or Lean ALM.
Noel: How is the role of management on an agile project different from that of a lean project?
Mik: It’s no longer just about getting software project managers to think agile. QA managers, the PMO and executives now need to think lean, and to do that their toolchain and process model must be connected to the new cadence of agile delivery, even if their cycle through their iterations more slowly than developers.
Noel: Would you define enterprise agility as the same as you would define lean or is there more to lean than that?
Mik: Good question, as distinguishing the various lean terms can feel like splitting hairs. But I see two distinct concepts here. There is plenty of conversation about enterprise agility. The goal of having our