Dean Leffingwell – Agile Executive Podcast 002
In this Agile Executive podcast, I talk with Dean Leffingwell. We start out going over Dean’s background both in the software and Agile world (check out his bio for more).
Since Dean worked at Rational for some time (after his company was acquired by Rational, Requisite, makers of RequisitePro), I ask Dean the broad question, what was up with RUP? That is, what went wrong there? In retrospect, it seemed like a flexible enough process, but it got applied as One Big Honking Thing, as The Poster, if you will.
Pulling from Dean’s work at, as his book would put it, Scaling Agile, I ask Dean how large companies go about applying Agile to, large, existing code-bases, like version 10 of a product. Put another way, how does Agile apply when you’re dealing with legacy code. His answer is the usual, crisp and pragmatic Agile approach, “let’s worry about the new code” and then move on to the old stuff when we have time. The other side of that comment is interesting as well: the old code “works” already, so try not to mess with it. At the time, I should have asked him how to deal with developers endless desire to refactor the code, which buts up against the “let sleeping dogs lie,” as it were.
Connected to this, I ask Dean to tell us what the “enterprise” in “enterprise Agile” means. We also discuss what Agile implementations seem to fit in enterprise situations. My perpetual questions here is: how do you fit in product management, sales, marketing, training, support and all that? Dean says that the strength of the Project Office (or the “PMO”) is the lynch pin here. We also get into using a sort of Facade approach to reporting and interfacing with the organization in the old ways while changing to Agile in-flight.
Also, touching on my interest in IT Management and Dean’s experience running a SaaS-y company with Agile, I ask Dean what he’s seeing in the way of “Agile Ops.” Dean points out that while “Agile” as developers know it doesn’t have big mind-share in operations, those folks tend to have very similar structure and goals to their process: quickly running, doing small things, and tracking all that.
Finally, we close out with the never-ending question when it comes to Agile Leadership, how do you get the organization to want to do it? As always, the approach is to use small successes to establishing credibly early on and then snow-ball those successes into larger ones.