Archive for May 2009
Dean Leffingwell on the Lean & Kanban 2009 Conference
As the recent podcast with Dean was held prior to the Lean & Kanban 2009 conference in Miami, I enquired through email about his major takeaways from the conference. Here is Dean’s answer:
I obviously think Lean Software will be big. It will be to the enterprise what Scrum is to teams.
I believe that Kanban (a subset of lean, being used as an agile team method now), will be more readily adopted in 3-5 years than Scrum.
Reasons:
- Easier to adopt at the team level.
- Far less overhead for planning and estimating, and fewer ceremonies (approaching zero in the edge case and with appropriate context).
- Based on both solid science and people aspects: theory of constraints, continuous flow and pull. Kaizen mind.
- Much easier to sell to PMO and VP level folks where agile=Dilbert=bad, and Lean=Toyota=good. Plus you can lean a PMO with value stream analysis and other tools. What do you do in a PMO with Scrum?
- Support from industry stalwarts such as Lockheed Martin, who are applying proven lean manufacturing practices to software development for projects like the Joint Strike Fighter. i.e industries on the other side of the agile chasm are adopting Lean now and will provide creature comfort for enterprises considering the leap.
- Plus agile already has a bad rap (perhaps undeserved) in many of those places; lean does not.
- Lean and Lean SSC’s focus on the role of management in continuous improvement and problem solving, as opposed to agile, where management is either a “chicken” (you can attend our meetings, but you have no role in our process…) or an “impediment” (If you attend an agile conference, manager’s, CEOs etc are routinely denigrated; that does not help our industry).
- Lean provides richer tools for improvement for the manager and practitioners – Kaizen meetings, five whys, root cause analysis, theory of constraints, flow and pull science and metrics, cumulative flow diagrams, etc. rather than just the single “retrospective.”
- Question: does agile scale? In my opinion, yes, but it is arguable in the industry. Question: Does Lean scale – Yes, not remotely arguable. Lean started at scale.
- Lean optimizes the whole enterprise and gives you tools to reason about the enterprise, from order to shipment, rather than just the team optimization.
- Potential for leadership from the Lean SSC as an open, science and knowledge-based consortium with an academic and industry approved certification process for managers and practitioners.
I could go on and on, this is just the short list.
In addition to Dean’s insightful points, a guest post on the conference will soon be published in this blog by colleague John Heintz. If you look for stroke-by-stroke coverage of the conference, Mike Cottmeyer‘s posts on the subject in Leading Agile are very informative.
How Agile Projects Measure Up, and What This Means to You
The Cutter Consortium Executive Report How Agile Projects Measure Up, and What This Means to You by Michael Mah and Mike Lunt is now available to anyone who is interested in software metrics. This is a rigorous data-driven report. Click here and use the promotion code MEASUREUP in the registration forum.
Dean Leffingwell – Agile Executive Podcast 002
To listen to this podcast, download the podcast directly, subscribe to the blog/podcast feed in iTunes (or whatever), or click play below to hear it:
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.
Confluence
The approach Eric Ries advocates for the Agile start-up has been covered in previous posts (click here and here). Basically, Ries sees the need to iterate on the customer problem alongside iterating on the solution to the problem. Furthermore, a process of discovery – finding the customer – accompanies iterations on the problem and on the solution.
In a note today entitled Three Designing Bears, Kent Beck brings up a great example for the approach Ries promotes:
[JUnit] Max is a bootstrapped product, so I need to find revenue as quickly as possible. I have no idea what people might actually pay for in a testing tool, so I need to try things as quickly as possible. Features only need to be finished enough to give me reliable feedback about their value. Will people pay for features like those? If so, I can afford to finish them later.
Various other threads are quite relevant to and consistent with the ideas of Ries and Beck. For example, commenting on Flickr in The Art of Agile Development, James Shore highlights their speedy {code –> test –> stage –> deploy} cycle:
When a user posts a bug to the forum, the team can often fix the problem and deploy the new code to the live site within minutes.
When coupled with “real time” user feedback, the confluence of speedy development with fast deployment reduces the risk of developing features that are never or seldom used. It applies to both start-ups and established enterprises. It opens the door for new software business designs that would have been considered infeasible just a few years ago. For example, one could enhance the Marauder Strategy (“seek out slow ships and take them out”) proposed by Jeff Sutherland by competing not “only” on velocity of development, but on accelerated deployment cycles and ultra-fast feedback loops.
Agile Roots
How very gratifying it is to experience the evolution of the Agile Roots conference. This is a true bottom-up conference. I only know some of the organizers, but my hunch is that the open source philosophy is at the roots of Agile Roots. There is freshness and genuineness to this conference that clearly come across even before the conference started.
At this point in time, the following speakers have been confirmed:
I will be delivering a keynote presentation entitled Four Principles, Four Cultures, One Mirror. Click here for the full abstract. The short version is as follows:
The path an Agile roll-out should follow depends on the core culture of the corporation: control, competence, collaboration or cultivation. Irrespective of the specific culture, the Agile roll-out invariably tests cultural integration, wholeness and balance. In particular, it exposes inconsistencies between approach with customers versus approach toward other constituents of the corporation such as partners and employees. Consequently, corporate reactions to Agile often express the disappointment of an organization when it is forced to take a good look in the mirror.
I have been known to quip I feel like “one foot in cold water, one foot in hot water” with respect to Agile. So much has been achieved, yet so much is still to be accomplished. I have no doubt the conference will addrress this dissonance, integrating Agile past, present and future in a very insightful manner.
Agile Scotland Clinics
Colleague Clarke Ching summarizes his initial impressions from launching the Agile Scotland Clinics, as follows:
Wow! I’ve been very pleasantly surprised by the overwhelmingly positive response to the Agile clinics. I was a little nervous that people might think it was a daft idea, but apparently not.
Clarke goes on to to compare the modus operandi for Agile Scotland with the Ask an Expert approach taken by Agile Austin:
I’ve taken a slightly different direction in that rather than dropping in, I’m asking people to book. I’m not sure what’s best but I was concerned about confidentiality and scheduling issues.
Clarke and I will compare notes on the subject and report how the two communities evolve from time to time. For now, suffice it to say that I am as excited about the Agile clinics in Scotland as I am about the one in Austin.
2020 Leadership
Colleague and friend Pollyanna Pixton has started a 2020 Leadership group. To quote Pollyanna:
As a starting point, questions we might address are:
– How do we lead innovation and unleash the talent in our organizations?
– How can leaders give ownership (and not take it back) while delivering competitive products to tight market windows and changing marketplaces?
– What works for making better business decisions?
– How do we lead business agility and business transformation?
Standish Group: “More Projects Failing”
The Standish Group has published its CHAOS Summary 2009 report. Here are two excerpts from the press release:
“This year’s results show a marked decrease in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions” says Jim Johnson, chairman of The Standish Group, “44% were challenged which are late, over budget, and/or with less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used.”
“These numbers represent a downtick in the success rates from the previous study, as well as a significant increase in the number of failures”, says Jim Crear, Standish Group CIO, “They are low point in the last five study periods. This year’s results represent the highest failure rate in over a decade.”
Statement of Purpose for the “Ask an Expert” Program
A recent post in this blog outlined Agile Austin‘s intent to start an “Ask an Expert” service. Plans for the program have been solidified now and it will be kicked off next week. The statement of purpose for the program is as follows:
The objective of the Ask an Expert program is to provide free consultation by experienced Agile Austin coaches to any Austinite that wrestles with issues related to promoting, planning and executing Agile methods. The program will address the needs of practitioners in companies that produce software, embed software, or use software as an integral part of their business processes. In addition to 1-1 consultation, coaches will gladly hold discussions with entire teams.
Ask an Expert sessions should be primarily regarded as a step toward addressing concrete Agile issues that manifest themselves in a specific environment. Coaches might not be able to complete a comprehensive analysis, but will make certain to suggest what the heart of the problem might be and point out Agile resources that practitioners could use on their own.
To ensure available access to experts, consultative session time will be divided between attendees. Team discussions with any Agilists attending the program will be encouraged to maximize the sharing of experience and draw out the wisdom of crowds. One-on-one sessions are available on request, but will be time-limited based on attendance (15 minutes typical).
The program will strive to balance utility with fun. Utility will primarily be delivered through actionable insights; fun will be had through passionate exploration of Agile topics in a friendly and collaborative manner.
Starting the coming Thursday (May 7), the program will be held every Thursday 6-8PM in the Chicago room at Mangia’s Pizza, 8012 Mesa Drive, Austin, TX.
Click here for the website for the program. Many thanks to Agile Austin volunteer Chandler Sweetser for constructing it. In a true Agile fashion, the site will evolve as we go along.
A Question of Correctness
Colleague John Heintz brought up a question about the the post Uncertainty, Complexity, Correctness. To quote John:
How are “uncertainty” and “correctness” related?
Doesn’t uncertainty mean my definition of correct may change? Could I have totally correct direction, but still have uncertainty?
What gives?!?
John is referring to the way I try to pinpoint the exact “pain” Agile is expected to address by an executive considering an Agile implementation. Specifically:
Agile is all about effectively addressing uncertainty, I say. I stress that Agile does not address complexity per se. It might indirectly help with complexity if it leads you towards deeper thinking about Complex Adaptive Systems. For example, you might consider evolving the product architecture in the course of your Agile project instead of pre-defining it. However, Agile is not a “medicine” for complexity pains.
Nor is Agile about correctness. A hyper-productive Agile team could actually go fast nowhere implementing a poorly conceived product. The “real time” feedback loops of the project team might help uncover that a product is mis-conceived. However, independent of the team feedback, you still need to determine what correctness means to you and how you would assess it as the product evolves.
The answer to John’s good question is that correctness is a matter of the level of abstraction as defined in Hardware Engineering: A DEC View of Hardware Systems Design. Suppose you are coding a service enabling passengers to check in for flights. At the functional level, the correctness of the coded service is fairly unambiguous and (hopefully) will be established through testing. The check in service might be correct functionally, but still subject to change. For example, an airline could aspire to enable its passengers to check in through any mobile device whose volume of sales exceeded one million units. Such an aspiration will necessitate fairly frequent changes to support new mobile devices as they cross a threshold of popularity.
So, yes: one could have a totally correct direction, but still have uncertainty.
The Agile Executive 