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.