eXtreme Programming Revisited (part III)

When 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.

5 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 XP practices in my framework My.Fragility, I decided to merge the best of both:

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…

eXtreme Programming Revisited (part II)

To 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 as project manager to urgently take on a project. 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!

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‘), Planning 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:

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)

* 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.

eXtreme Programming Revisited (part I)

Chet 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:

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).

It’s better to read, not to watch… Watchmen

How watching Watchmen might turn into a depressing experience:

1. Either you’ve read the extraordinary comic and you won’t recognize it.

Gone are: a carefully revealing puzzle, everyday hero backgrounds, their naive intentions, the retro-graphics, the suggestion of violence.
Enter: explicit atrocity, underportrayed characters, übershiny costumes and graphics. Luckily the end scenes preserve the philosophical core of the book and (just partly) save some of the movie.

2. Either you haven’t read the extraordinary comic and you have doubts.

You wonder: what is this movie about? What connects all pieces?
One advise: read the book. Reconsider this obnoxious movie afterwards.

By the way, it is NOT impossible to make a good movie from an Alan Moore product. Check out V for Vendetta (soundtrack by David J). And while From Hell may have been mediocre, Watchmen is really disappointing.

The spell of the Man-Month broken?

Frederick Brooks published his essay The Mythical Man-Month in 1975, as one of 15 essays in the same-titled book on managerial aspects of software development. I wanted to check on the actual value of this historical piece of work. I have read the 20th anniversary edition, to which the author added an essay with his updated opinion on his original statements. This edition also holds the even more provocative (1986) paper No Silver Bullet (I will come back on that one).

The book: modern myth or ancient history?

The 1975 cases are technically not so appealing (IBM’s OS/360). But the organizational topics are striking, with the title essay on top (justly mythical by itself). The core statement (“Brooks’ Law”) that “Adding manpower to a late software project makes it later” is still valid. Blame the myth of the man-month for confusing effort and progress, for neglecting the need for communication, for ignoring repartitioning tasks and training, and decreasing team productivity. People (developers) are not ‘replaceable pieces of machinery ‘! Brooks also stresses the creative nature of software development.

I agree on the diagnosis, but the suggested remedies (a lot on estimating and roles) are somewhat vague and far-fetched. E.g. 1/6 = coding, surgical team and ‘directors’/‘producers’, ‘aristocratic’ architects, etc.

But then, there’s the author’s 1995 retrospective making the lecture vivid again. He formulates views that are greatly in line with… Agile. And indeed, since the mid ‘90s we have seen the definite rise of Agile (this common denominator was only established in 2001!).

Can we today overcome the curse of the mythical man-month?

I believe that at least Agile does show a way out! Because it has a fundamentally different approach on communication and the ‘people’ aspect of software development.

Estimating is done by the whole team and in Story Points, i.e. complexity. This is at the same time the base for measuring progress (i.e. velocity being the number of Story Points realized in a Sprint), and avoids the confusion with effort. In my personal approach:

1. I use velocity to uplift estimates in ideal time (cfr. Story Points) to planning time. It accepts that a base estimate is… too ideal, always limited to pure development. To be able to complete it in the real world you need to uplift it with a factor that I call Velocity;

1. I add 25% to the total planning time (sort of slack). It is based upon a traditonal Scrum Sprint of 20 days, of which 1 day Sprint Planning, 16 dev days, 2 days to achieve ‘Done’ and 1 day Sprint Review/Retrospective. I.e. upon 16 days of development work (in planning time), 4 additional days need to be foreseen for the team.

In his Agile bible, Agile Software Development, Alistair Cockburn has substantially stressed the fact that communication hàs a cost, increasing our awareness of the impact on progress and budget. He offers a great active solution in the form of Information Radiators and Osmotic Communication, meanwhile greatly adapted by Agile teams.

Okay, this subject needs a more elaborate paper. Consider it in progress…

From B to J

During a check on my favorite artists I ran into a music video of David J, reminding me of the fascinating artist and songwriter the man is.

The song brings up memories of Bound for Hell, which he wrote for the self-titled Love & Rockets album. Although this album divided not only the band’s 2 main songwriters, but also their fan base, I still love it. Exactly because of its playfulness, its fooling around with pop music. Subsequently they defined… pop music. And does ‘Roll On’ on the Daniel Ash album ‘Foolish Thing Desire’ bring up memories of ‘Motorcycle’ on L&R? (anyone saying “The Jesus & Mary Chain”?)

I have mostly known David J as the coolest bass player around. I found out only last year that he had composed the music for the V for Vendetta song This Vicious Cabaret, using Alan Moore’s lyrics. Following is not an official video, but pastes imagery of the (great!) movie on top of the (great!) song:

Fairly intrigued I bought me the full (mini) CD. Now, that’s what I call (avant-garde) CABARET! My edition also holds the demo version of the main song, which is truly great (knowing that it’s the result of a 1 night effort).

It all started with Bauhaus. And it’s quite fair to say that also Peter Murphy (I’m a huge fan!) and Daniel Ash are fascinating artists and songwriters, that have helped defining the face of music. If you want to know more on the forming of, the history of Bauhaus and the subsequent paths of its members, there’s this illuminating book Dark Entries (Bauhaus and beyond). It goes back to the days of various bands, of David J playing bass, his brother Kevin (Haskins) on drums (flower pots?) and Daniel on guitars. With Peter they came to be the legendary Bauhaus (1919).

Of course, over the past 25 years the guys have kept creating new, distinct and fantastic work, have reformed a couple of times, even put out a new Bauhaus album. Too much for one lousy blog note…

Who watches the Watchmen?

I certainly haven’t (yet). Because I first wanted to read the Watchmen book. As I (luckily) also did with From Hell and V for Vendetta.

As usually with Alan Moore it took me some time to get through it. Because of the figuring personas, their psychology and backgrounds, a complete society sketched and, not to be underestimated, the plot. Moore’s works are truly ‘Graphic Novels’, balancing images and narration (both of high quality). Guess why it took 4 years.

As usually with Alan Moore it was worthwhile. Certainly for Watchmen. In a historically twisted world, numerous layered tales are served, that eventually all interact and interconnect (with the Pirates’ book-in-the-book and its writer’s role as supreme example). The written intersections in the book (of varying ‘written’ nature) required my patience but added perspective. All to present a hyperoriginal perspective on superheroes, also behind the scene (how common), the early amateurism and marketing attempts of the masked avengers, their objectives, motives and ethics, the fact that they get old and… retire. No wonder that The Minutemen weren’t meant to last.

Alan Moore is without any doubt one of the greatest graphic novelists of our times. He gave us a complete hypothesis on the identity of Jack The Ripper and the motives and instructor for his outrageous killings, in an historical London with all its (dark) facets, in From Hell. Mediocre movie if you know the book. He told about this fascinating superhero-like character fighting a fascistoid authority in the truly haunting V for Vendetta (brrr, the scaring philosophy -liberating?- behind the torture scenes…). The movie was good, respecting main roles, colours and story of the book. He has not just written another Batman story with The Killing Joke, it soon became a well adapted standard for the becoming of Batman’s biggest opponent, The Joker. But Watchmen is the best I’ve read to date of Alan Moore. It really stands out with all its magnificent complexity. Sorry to say that The Ballad Of Halo Jones was just good, entertaining above all. Others would kill to be able to write it, I guess.

Now I will sit and wait. To watch the Watchmen on DVD (director’s cut).

The Dark Knight returns (in Lego)

In Legoland (returning from Italy) I completed my Lego Batcollection with the Battank (vs. Riddler & Bane) and the Batcopter (vs. Scarecrow). I already had the Batcave (with Robin & Alfred, vs. Penguin & mr. Freeze), the Batwing (vs. Joker), the Batboat (vs. Killercroc) and the Batmobile (vs. Two-face).

As Catwoman (Batman dragster) wasn’t available (I’m trying to get to her, and the Arkham Asylum, in the US) I’ve bought her as a keyring.

And now a whole new Lego series from the new Batman movies is available (explains the Harley Quinn keyring)… can’t wait to get it!

Brings up mixed feelings: should I feel fine that Tim Burton’s great creations were ruined? As I really love the realistic feel of the new movies, even more inspired by Frank Miller’s incredible Battales. Great scripts, atmosphere and acting.

Without having seen the new movie, Ledger’s pose (movie posters) seems inspired by Brandon Lee’s The Crow.
And do check out the Lego movies:

Scrum and the Cooperative Game

In many (IT) partnerships and implementations people seem to prefer to strangle each other rather than assure mutual benefits.

I’m applying Scrum (over 4 years already), in my projects and in my management. It continuously helps me to cross fences; between suppliers and customers, business and IT, analysts and developers, x-layer developers and y-layer developers, etc.

In my Scrum-based development process I use Pre-Game Staging to name the barely enough preparative phase for 1 stage of software development. The “Games” metaphor was described by Alistair Cockburn in his biblical work Agile Software Development. I strongly agree with him that software development should be a Cooperative Game.

• Cooperative: a team of people works together towards a common goal, not to fight each other.
• Non-zero sum: the players are not opposed and do not try to win by getting the other at zero. There are multiple winners.
• Finite and goal-seeking: the game ends when the goal is achieved. The game is not meant for just staying in existence.

You will find this as well in the integrated prerequisite for supplier-customer relationships (possibly multi-tier), from Toyota’s Lean Production to Poppendieck’s Lean Software Development. It offers far more certainties than our commonly applied bidding processes. Think (read) about it!

(how he lost) CONTROL

I have finally watched Control (on DVD). It was good, even great, but it didn’t fully live up to my expectations. It is not the story of a relationship with the band as background, although the movie is based on Deborah Curtis’ book Touching From A Distance, which I have read a couple of times. It is neither the story of Joy Division (gotta get “Joy Division” by Grant Gee). So I guess it just ends up somewhere in between, leaving me with this not fully satisfied feeling. I also grew into it, as during the second half it felt better. The feeling remains that it is somewhat overstyled and polished.

I did not feel the alienation, the pain, the fits, the distress, the inability to handle the success, the loss of… control, as in the book. Deborah shows Ian’s dreams were complete after releasing Transmission and Unknown Pleasures. Her pain of not being involved more by Joy Division’s entourage, e.g. when listening to Closer (too late). Never mentioning the name of her man’s mistress. How she hàd to divorce him (almost did).

One crucial scene I really missed is how Ian didn’t dare to hold his little daughter for what turned out to be one of the last pictures of him.

Overall it was worthwhile. Certainly the actors are astonishing. Check out the frightening resemblance with some original footage:

And watch the movie trailer: