Posted on Leave a comment

eXtreme Programming Revisited (part I)

Extreme Programming InstalledChet Hendrickson is the co-author of the book Extreme Programming Installed (2001). In a paper of August 2009 he discusses the XP practices he feels that have changed over the last 10 years.

That triggered me to have a small retrospective myself.

I’ve read this book in November 2003 as research for my presentation at the BeJUG’s JavaPolis of December 2003. I presented a major project in which we (very successfully) applied eXtreme Programming (truly pioneering in Belgium at that time). I read the book after Kent Beck’s books in the same series, Extreme Programming Explained (Embrace Change, 1999) and Planning Extreme Programming (2000).

Looking back today, I still find that Extreme Programming Installed lacks structure, leaves an impression of randomness, misses a good ‘story’. I distinguish 3 main parts, without these parts being marked as such:

  • Introducing XP with the 4 XP values (communication-feedback-simplicity-feedback), the roles (customer-manager-programmer) and highlighting the On-site Customer and User Stories
  • In-depth description of the 12 XP practices (13 actually as Testing was split into Acceptance Testing and Test First)
  • Bonus Tracks with some of the authors’ highly personal experiences and coding insights

Although the practices are core, they are only listed at the end and the coherence is mostly neglected. Although co-author Ron Jeffries drew a perfect roadmap with his alternative to Kent Beck’s representation:

Kent Beck - 12 XP practicesRon Jeffries - XP Practices (circles)

My remarks on the changes that Chet identifies, are:

  • Views on User Stories Size have indeed evolved. My Definition of Agile Planning mentions Mike Cohn’s influence. But in Planning Extreme Programming Kent Beck & Martin Fowler had already treated the essential topics (including sizing) surprisingly well.
  • The Iteration Length (originally 3 weeks) has equally been given flexibility. The same goes for Scrum (30 days Sprints), that I started applying in 2004. I mostly stick to calendar month Sprints.
  • I agree that the Metaphor guideline has not been well adopted, despite its potential. But did it ever stand a chance, as even Extreme Programming Installed treated it marginally?
  • The topic of Dispersed Teams has really grown in importance. But no method (Agile or other) has ‘the’ solution. Alistair Cockburn has at least published remarkable thoughts on the communication aspects. I still refer to his Osmotic Communication.

And… I agree that the C3 pioneers have changed the world by the formal introduction of eXtreme Programming!

But… Chet nor Ron mention Kent Beck’s profound XP revision of 2004. I’ll come back on that in eXtreme Programming Revisited (part III).

Posted on 2 Comments

Kanban and Scrum (done or to be done?)

Kan and Ban are Japanese for Card and Signal. A Kanban (signal card) originates from the Toyota Production System (TPS) where it is a physical card that visualizes a pull question for inventory. It serves to minimize stock in a ‘Just In Time’ strategy and is a way to ‘eliminate waste’ while assuring a continuous flow of goods.

In an Agile context, a Story Card is a Kanban. Out of eXtreme Programming it grew into an established Agile practice in describing a feature. A Kanban Board holds the active Story Cards per ‘status’, thus being an Information Radiator (term by Alistair Cockburn, also my inspiration for the Games metaphor).

My.Fragility_logoMy Scrum Product ànd Sprint Backlog items are User Stories. (‘Minimal Marketable Feature’ is more generic, but I stick to ‘User Story’) The Sprint Backlog is made visible by sticking a printout from my (Excel) tracking model on a wall. Around the Daily Scrum (we do it standing up) each Story Lead writes the estimated time to finish a Story on the printout and I create the Sprint Burndown. That works fine. We use a Kanban Board only for feedback from functional testing. This is generally too small to create a Story (would be ‘waste’).

Velocity is a way to optimize the inventory and the continuity of work. Traditionally ‘velocity’ equals the #Story Points (gummy bears) that can be finished in one iteration (a Sprint). However, I apply an overall Velocity as a multiplicator on Story Points (ideal time) to result in #planning days. The size of the inventory (in #Story Points) for a Sprint is determined by dividing the available #planning days of a team (minus 2 slack days) by expected Velocity (Yesterday’s weather). Note: continuity is also assured by the presence of the Product Owner. He/she makes sure that no functional issue remains unsolved, on the spot!