The Agile Executive

Making Agile Work

Posts Tagged ‘David Anderson

A Note on the Kanban & Retrospectives Post by David Andreson

with 3 comments

David Anderson wrote an interesting post on Kanban & Retrospectives. David observes that some seasoned Kanban teams ceased doing “official” retrospectives. To quote David:

Some mature Kanban teams did drop the use of retrospectives. No one told them to do it. They just did. Retrospectives were not adding value in their lives and hence were seen as a wasteful activity that could be eliminated.

David carefully examines retrospectives in the Kanban context. His concluding recommendation is as follows:

Kanban can enable a team to reach a level of maturity where they may choose to eliminate retrospectives (or not.) It’s a choice! Every situation will be unique. The important thing is not to see elimination of retrospectives as wrong or bad or “not agile.” Equally, don’t rush in and eliminate retrospectives. Don’t proscribe retrospectives. Let the team make its own decision when it is ready and embrace the evolution of process that comes with continuous improvement.

I certainly understand where David is coming from and the sound logic of his reasoning. However, the question on my mind is whether core Scrum practices could be reduced without jeopardizing the method. The following excerpt from a recent Cutter Consortium post entitled Breaking the Facade of Truth: An Introspective View into and a Case Study About the “Apparent Truths” of Agile by David Spann nicely summarizes how minimalistic Scrum is:

Scrum, as a management methodology, is elegant in its design, requiring only three roles (i.e., product owner, ScrumMaster, and self-organized team), three ceremonies (sprint/iteration planning, daily Scrum/debrief, and sprint review meetings), and three artifacts (product and sprint backlogs and the burndown chart) — just-enough practical advice so agile teams do not overcomplicate the development lifecycle with too much ceremony and documentation

Can one meaningfully drop a core practice of a just-enough method?

Opinions please!


Written by israelgat

March 21, 2009 at 2:07 pm

Customer Driven Testing

with 4 comments

David Anderson, James Shore and I engaged in a Twitter dialog about the post Every Nine Minutes. Our exchange highlights the importance of balancing development, deployment and operations, as follows:

what concerns me about continuous deployment is it is developer centric. Deployment has a cost for the customer [DA]

Continuous deployment involves automating what must be done anyway. Unless you mean end customer, don’s see the costs you mean [JS]

yes end customer. not everyone wants the UI changing every 9 mins 😉 what about training? marketing? etc..? [DA]

I think that’s an issue that’s raised by, but independent of, continuous deployment, and quite manageable. [JS]

 I want 2 c people talk about this holistically. If deploying more often is better then how do u reduce cost/impact on customer? [DA]

It seems to work quite well for their clientele. Their iterative customer development work might be the ‘secret sauce’ [IG]

is this an aspect of their tech enthusiast, early adopter market? [DA]

I think it is deeper – they adjust their testing to the needs of their market segment. Will blog on it later today. [IG]

The software IMVU produces is similar in some respects to what Clay Shirky calls Situated Software: “… designed for use by a specific social group, rather than for a generic set of users”. . .  IMVU’s  testing seems to be in good accord with the needs and priorities of their young users. Certain deficits in their software do not seem to be terribly important to their clientele. As pointed out by Elizabeth Hendrickson it might not be perfect but the software does the job for the target clientele and creates value.

The way IMVU develops the customer in an iterative manner (in parallel with iterating on the product) seems to be the key. Deep understanding of customer and problem determines testing strategy. Given their Lean Startup orientation, “good enough” testing seems to be quite appropriate for their business design:

  • Product release cycle in hours, not years
  • Tightly coupled with customer development
  • Minimum feature set, maximum customer coverage
  • Rapid hypothesis testing around market, pricing, customers,…
  • Extremely low cost, low burn, tight focus

IMVU is an example of the approach advocated in Agile Considerations for CXOs: don’t harness Agile into a rigid business design; instead, develop a business design around the capabilities of Agile.

Written by israelgat

March 15, 2009 at 3:28 pm