Tag: Chet Hendrickson

Posted on by — 1 Comment

eXtreme Programming Revisited (part III)

Extreme Programming InstalledWhen reviewing Chet Hendrickson’s paper on the evolution of Extreme Programming practices, I was surprised that he completely ignored Kent Beck’s revision of 2004. As does Ron Jeffries’ practices representation, by the way.

Ken Beck - Extreme Programming Explained5 Years of eXPerience resulted in a complete revision of Extreme Programming Explained. The general tone softened, partial adoption became acceptable and the practices were extended, and divided into primary and secondary practices. Maybe Kent considered XP as under-adopted, but I missed the strong and ahead leadership from v1. No compromise. Working software is the goal. Extreme focus. Programming is the way.

I also felt that in the v2 edition, good ideas were introduced, but good practices were also replaced. Because I instantiate Scrum’s engineering standards with logo-myfragilityXP practices in my framework My.Fragility, I decided to merge the best of both:

My.Fragility Grafx - XP Practices

Note: when checking the original Extreme Programming Installed book myself, I wondered (after all these -6- years!) why it did not mention the Coach role. When moving to Scrum after our ‘pure’ XP application, I kept promoting this role. I still do in my My.Fragility framework (on top of Scrum’s Product Owner, Team and ScrumMaster).

And I still don’t known why User Stories was not an explicit XP practice from the beginning…

Posted on by — Leave a comment

eXtreme Programming Revisited (part II)

Extreme Programming InstalledTo review Chet Hendrickson’s retrospective paper on his book Extreme Programming Installed, I went back in time myself. Back to my first experience with Extreme Programming.
In September 2003 I was asked to urgently take on a project as project manager. Customer approval was late but the predicted delivery date remained (December).

A 15 min introduction convinced me of eXtreme Programming. Because so much was incorporated that was traditionally so easily forgotten or overlooked. We convinced management, and off we went (October). After 3 iterations (of 3 weeks) we delivered… in time and on budget!

Kent Beck - Extreme Programming Explained (Embrace Change)Because I considered myself too illiterate (after all, we only did it) to present the project at Javapolis 2003, I started reading some books. The inevitable Extreme Programming Explained (‘Embrace Change‘), Kent Beck and Martin Fowler - Planning Extreme ProgrammingPlanning Extreme Programming and… Extreme Programming Installed. It was remarkable to find that our ‘naive application’ was an extraordinary match with what I was reading. Presentation went very well.

In 2004 I started using Scrum as process and certified as a ScrumMaster. During follow-up projects for our satisfied customer we kept combining Scrum and XP. However, we had to operate within a context of realizing a (negotiable) scope in a given timeframe. So along the way (2004-2006) additional practices, tools and views were embedded, to finally become my My.Fragility* framework.

The framework holds following (partially XP based) Quality Loops:

My.Fragility - Quality Loops

Implementation of Engineering Standards. To be performed every day:

  • A pair writes all code upon a Test First basis (including Selenium GUI tests)
  • Checked in code is tested in a Continuous Integration system (multiple times a day) and can be refactored
  • A ‘guide’ (additional, explicit role) functionally tests a stable, CI’ed version (multiple times a day) and feeds back results to the team
  • A functional working version may be deployed for performance testing (running overnight)

*myfragility_logo The name of the framework has its roots in the big relief I felt when morphing from project manager to ScrumMaster. The option to be fragile (agility through fragility), of not constantly having to intimidate people. Because, after all, it’s just a matter of talents and roles, not of… hierarchical slavery.

Posted on by — 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).