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 software-based business adapt quickly to change is clear. In the pursuit of that goal, with our focus on lean software delivery and lean ALM we are trying to shine the light on the tools, systems and process model needed to keep task batch sizes flowing across a delivery process that has agile development at the center of it.
Noel: I know the lean startup movement is still relatively new; do you see the movement being able to be applied on an even larger scale than it already is? With the continuous improvement mindset, it’s difficult to imagine that it can’t be even further improved.
Mik: Tasktop, having been bootstrapped on revenues, has lived the lean startup path first had, with agile development at our core. That’s relatively easy to put in place at a fifty-person company. What’s more interesting is how you get the benefits of lean when you have thousands of people involved in your software delivery process. For most, it’s not currently feasible to make your app portfolio a collection of lean startups. So we have to look at connecting the build/measure/learn loop to slower churning parts of the organization than a management team calling the shots in a lean startup, and that’s where things get interesting.
Noel: Your upcoming keynote presentation at the Agile Development/Better Software Conference is titled “Lean Software Delivery: Synchronizing Cadence with Context. What does a team need to look for to know if they’re in need of synchronization? Will it be painfully obvious, or are there some areas that you’ve seen teams maybe not think to look?
Mik : Teams converge on a suitable cadence over time. The challenge is what happens across teams, especially from different disciplines across the lifecycle. For example, while the development teams get increasingly more proficient at shorter iterations, the testers and business analysts may need to work to a cadence that constrained to longer iterations. And that’s where things start to get out of sync.
Noel: Your session also brings up “naïve agile transformations.” Where does that naivety come from, and how easy, or difficult can be to overcome?
Mik: The naïve approach comes from the view that the organization can work to once cadence. That’s just not the case. Requirements churn more slowly than user stories, but the cadence of the business analysts must be synchronized to that of developers and testers. This is not as simple as embedding a developer and tester in each team, especially not at large scales where distribution and outsourcing mean that some automated connectivity must be put in place to connect these disciplines.
As CEO of Tasktop Technologies Mik Kersten sets the strategic direction of the company and drives many of Tasktop's key partnerships and key customer accounts. He is very active in maintaining the company culture and values. Mik created the Eclipse Mylyn open source project and the task-focused interface while working on his Ph.D. in computer science. As a research scientist at Xerox PARC, Mik implemented the first aspect-oriented programming tools for AspectJ. He has been an Eclipse committer since 2002, is a three-time elected member of the Eclipse board of directors, and serves on the Eclipse Architecture Council.
