Extreme Gtd

Steve Yegge's famous rant (GoodAgileBadAgile) gives some insight into the developer nirvana operating at Google. One tidbit explains that each developer has a work queue; they do the tasks in their queue, and the project just kinda manages itself. No GanttCharts, no CommitmentSchedules. Just give everyone a task queue and let 'er rip.

Of course, this works best when you never announce a release date and you keep your products in perpetual beta ...

GettingThingsDone provides an excellent way to manage task queues a.k.a. action inboxes. If you haven't tried GTD, the main draw is you can radically reduce stress while greatly improving your ability to master the complexities of modern life.

Back in January MattCornell? (http://ideamatt.blogspot.com/2006/01/is-gtd-extreme-programming-of-time.html) noted strong parallels between XP and GTD. As WholeIsToPartAsPartIsToWhole?, this naturally leads to thoughts of using GTD to streamline and formalize XP.

RobertPeake?, DavidAllen?'s CTO, recently attempted to do just that (http://www.43folders.com/2006/10/17/robert-peake-part-one/, http://www.43folders.com/2006/10/18/robert-peake-part-two/). Peake's treatment isn't bad - but it's pretty much just XP minus a few core practices - PairProgramming, SystemMetaphor, PlanningGame, ArchitecturalSpike, ProjectVelocity, IndexCards, and so on. Peake's thesis is that GTD style breadth-first analysis and management is a panacea. While this may strengthen his process's resemblance to GTD, it encourages a hill-climbing approach to development limited to local quality minima. Peake describes surmounting such local minima with MindMapping and BrainStorming practices, but provides no formal definitions for these. Nor for the contents of his "revolutionary" LotusNotes database.

And this is fine - Peake's audience is non-technical, and such material would only confuse them. But I believe it is possible to go much further than this. GTD isn't just a metaphor for XP, nor vice versa. The two processes can be fused to create one with elements that formerly appeared in neither. And still ExtremeNotAgile.

Speed and control. XP and GTD. These things reinforce each other. I want to unify them. So I'll start with a few mappings. Naively:

GTD Actions <=> XP EngineeringTasks
GTD Projects <=> XP UserStories
GTD Contexts <=> XP EngineeringTask type.
GTD Tickler <=> XP AcceptanceTest stuck in a calendar?
GTD 43 NextActions? <=> XP CommitmentSchedule.

But this doesn't quite answer. What about BusinessStories? Are the NextActions? really a schedule? And if we're doing stuff with a lot of different people's calendars, how do we juggle them? Less hand-waving please.

Okay, let's consider two views of the process: the ExtremeManagement view and the ExtremeProgramming view. The former is about dealing with the business and prioritizing the development. The latter is about dealing with the technology and estimating the development two views meet in the NextActions?, which replace the PlanningGame.

ExtremeManagement Projects are BusinessStories; their actions are UserStories; their contexts are OnSiteCustomers, channel partners and their systems, and internal and external service providers of all sorts. Per Yegge, each of these is responsible for servicing a collection of NextActions? - which is to say, UserStories. Unlike Yegge, the NextActions? don't form a queue owned by a developer; they are pulled opportunistically from multiple Project queues pre-ordered and weighted by the management. It is a management responsibility to go about ordering and weighting these queues.
ExtremeProgramming Projects are UserStories, their actions are EngineeringTasks, and their contexts are SystemMetaphor elements - @model, @view, @controller, perhaps, or whatever patterns you prefer. Developers PairPromiscuously with each pair taking responsibility for delivering an entire UserStory at a time. NoSecondChances? and all the related XP practices apply.

The basics of an ExtremeGtd process then follow the five phases DavidAllen? originally outlined.

Collect: In classic XP, the OnSiteCustomer originates UserStories, or at least BusinessStories. In general practice, all team members originate these things, but the OnSiteCustomers accept accountability for prioritizing them. If we're to take a GTD view of this, we want to get all the stories out of everyones heads and into CollectiveOwnership. In classic XP, developers selfishly hold onto OpenLoop?s, calling them ArchitecturalSpikes or just plain doing them late at night and apologizing later. In ExtremeGtd, we use a CollectiveInbox? for all stories that derive from all team members and adjust our process (a.k.a prioritization process) to this collective.

Process: To ensure that developers don't hide their OpenLoop?s, and to ensure that business folk don't hide their business factors, we apply the same technique for priority estimates that we already apply to time estimates; most optimistic (i.e. lowest priority) assessment wins. Unlike classic XP, we don't lump all our stories into one big CommitmentSchedule and triage all at one time; that's a recipe for long meetings and authoritarian resolutions. ExtremeManagement keeps the UserStories siloed by BusinessStory and prioritizes each silo independently. Where this causes debate, as it inevitably must, we leave the lowest priority estimate intact but make a new top priority story in which the debaters take their debate offline. By the next WeeklyMeeting?, we expect they'll have come to an agreement on the priorities of their controversial stories and we'll adjust that BusinessStory's CommitmentSchedule then.

Organize, Review & Do: coming soon. -- Pete

CategoryGtd