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

Introducing Scrum.org

Recently Scrum godfather Ken Schwaber resigned as chairman from the ScrumAlliance, which he co-founded.

I remember Ken from turning my ScrumMaster certification course in 2004 into a great experience. Not because of the certificate, but for comprehending Scrum. I’ve since then advised people to attend the certification course, but mainly to get in touch with other people and dive into the matter.

Ken launched Scrum.org as a move from ceremony and formal organization to process and community. From certification to assessment (for self-improvement). There’s an online Scrum Assessment, upon a Scrum Guide. Because… “Unlike certification, assessment makes no public claim of competence and cannot be misused to assert qualifications that may or may not exist“.

I scored 69 out of 80 (86%), which took 25 minutes (1h allowed). This feels okay but the most important aspect was that through the reflection on some missed points I could improve my insights.

“Although there’s value in certification, assessment is valued more.”

Definition of… Agile Planning

In The adoption of Agile I stated that ‘Agile’ is not one method, but a set of common principles and practices. The same goes for ‘Agile Planning’.

I created my My.Fragility framework iteratively over the various software development projects I mastered, all serving to realize a (negotiable) scope within a certain timeframe.

The included Product Backlog Estimation model allows to:

1. Write User Stories. Or Epic Stories
2. Make up estimates in Ideal Time / Story Points
3. Determine Velocity. Possibly, but not advisable, per story
4. Determine #pairs. Consider project elapse time, max = 6
5. Determine #FTE for umbrella tasks. Upon #pairs and complexity
6. Set daily rates
7. Set slack, holiday percentage and coach development
8. Assess result & iterate using other parameters
   
9. Set Value of Stories. Total to be 100 (for relative tracking)
   

The Product Backlog Tracking model implements my Tracking Loops:

This assures a continuous image of spent and expected progress, effort, budget and delivered value, at Product and at Sprint level.

The book User Stories Applied by Mike Cohn was a great source of inspiration. Essentials I still use are:

• User Stories, Epic Stories and micro (tiny) Stories
• The INVEST acronym
• Complexity scaling. I use ‘1-2-5′ (over Fibonacci)

Mike’s publisher (Prentice Hall) has made 2 chapters of his second book Agile Estimating and Planning available, for F R E E:

• Chapter 1: The purpose of planning
• Chapter 3: An agile approach to estimating and planning

The adoption of Agile: TALC vs. Hype Cycle

An interesting poll was posted at Scrumology asking us to indicate where we consider ‘Agile’ to be on the Hype Cycle. A little note…

The presentation of my framework My.Fragility starts with a general introduction on ‘Agile’ before diving into Scrum and going beyond. This introduction ends with a maturity assessment of Agile using Geoffrey Moore’s Technology Adoption Life Cycle. The conclusion is that Agile has Entered the Bowling Alley (so has definitely Crossed the Chasm).

In 2008 I added a comparison with Gartner’s Hype Cycle for Application Development, which puts Agile in the Trough of Disillusionment and predicts a period of 5-10 years before mainstream adoption.

However, having studied and compared both models I am convinced that Agile is -at least- on its way to the Slope of Enlightenment:

Other objections I have with Gartner are:

• Agile is primarily the common denominator of a number of methods and is as such not one defined method. As a practitioner of Scrum, combining it with XP and going beyond with My.Fragility, I believe these methods to be certainly farther in adoption.
• A complete Agile approach covers a number of practices and disciplines that Gartner separates (e.g. various testing levels). See my indications on the Hype Cycle.
  
• My intuition and daily experience contradict the 5-10y expectation.

Challenge: from the TALC I expect Scrum to become the Agile Gorilla…

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…

7 Rules for the Ruler (not to be ruled)

Rule I: One rule to rule them all

“You shall not be subject to emotions”

Rule II:

“Expecting gratitude is not the attitude”

Rule III:

“When fought, you shall not fight (nor shall you weep; you shall smile)”

Rule IV:

“You shall concern but not be concerned about”

Rule V:

“You shall act beyond ethics or morality”

Rule VI:

“Your weakness shall be your strength”

Rule VII:

“Fairness was not part of your job expectations”

What can I say?

Oh, what to do?
Not to feel and who are you?
What shall we do if baby turns blue?

I see further to a day, to a day never to come.
With eyes in the back of my head I see all around me.

Scrum (all sorts of people)

Scrum is also in the minds of people. My mind is set on the ability of fragility. How about you?

Are you ‘management’? Then you should not only be willing to believe that a software project can truly deliver quality and business value. You should also do (a lot) more than just gather a group of programmers with a project manager on top during a (project’s) timebox.

Okay, so far for a view the community will quickly agree upon.

What is usually less focused on is the level of commitment of the actual team members. In my experience this may turn out to be at least as difficult to achieve. Because it takes the absolute will to self-organize, not wanting to depend on other people to take decisions for you (the essence of ScrumMaster facilitation versus Project Management’s execution of control), to outweigh every (technical) choice against the (business) value and functional profit, to discuss and communicate openly, etc.

Scrum is a simple way to outperform and excel but all parties should respect its essence, that I represent on my Scrum Diamond:

think (talk) about it…

Loving Facebook, Hating Facebook

Pablo Zarate made a clear statement. Capo wrote about it. I’m getting bored with it. And here’s 25 reasons not to love it:

I don’t agree on every single reason, but certainly on a majority.

So let’s be trendy (for once) and:

• Get rid of unused friends
• Keep professional contacts at LinkedIn
• Don’t accept silly requests or things getting thrown
• Bluntly… defriend (I will start with people that don’t even respond to a personal e-card for their birthday. I just hate that!)

Okay, maybe my virtual network will look as friendless as my real life network :-(. But I will surely feel relieved and de-stressed :-).

Let’s use it pragmatically to keep informed of:

• Real messages of real friends
• Real friends’ birthdays
• Events of bands/groups/subjects of interest
• Worthwhile causes

Gestapelde intenties (lees::boeken)

Eerder heb ik al eens bekend dat ik koop. En dat dit tot een weldadige overdaad aan boeken leidt. Maar sinds het schooljaar is losgebarsten, heeft er zich, bovenop deze chronische overgroei van blijvende aard, ook een meer accute opeenstapeling van leeswerk voorgedaan:

Een gedeeltelijke oorzaak is dat ik zelf nog zoveel wil uitspuien, waarbij: het hypothetische voornemen om voor den arbeid elke dag 1 deliverable te k*kken, uitwerking en beschrijving van mijn persoonlijke expertise in Scrum en andere schrijfsels -van eerder literaire aard-.

En dan ga ik het toch weer niet kunnen laten om op de boekenbeurs enkele werkjes aan te schaffen. Ik denk al jaren aan (het verzamelde) Het Beleg Van Laken van Walter Van den Broeck, ben erg geïnteresseerd in de nieuwe Grunberg (Mijn Oom), wil toch ook naar Dinsdagland met Dimitri Verhulst (remember godverdoms bericht), heb weet van Duivels van Dostojevski (alles van gelezen in mijn verre jeugd), in een sjieke uitgave van Athenaeum-Polak & Van Gennep (heb al verscheidene andere titels van de reeks).

En, awel, op de tijd dat ik dit bericht heb gemaakt, had ik ook weeral zòveel andere dingen kunnen doen.