Category: Werk / Work

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

Posted on by — Leave a comment

Introducing Scrum.org

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

Logo - Certified ScrumMaster SealI 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.

Scrum.orgKen 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 (note: no longer available), 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.”

Posted on by — 2 Comments

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:

My.Fragility - Tracking LoopsThis assures a continuous image of spent and expected progress, effort, budget and delivered value, at Product and at Sprint level.

Mike Cohn - User Stories AppliedThe 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:

Posted on by — 1 Comment

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…

logo-myfragilityThe 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.

Agile on the Hype Cycle for Application Development 2007 (Gartner)

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

Agile on the Hype Cycle vs. TALC

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…

Posted on by — Leave a comment

The spell of the Man-Month broken?

Brooks - The Mythical Man-MonthFrederick 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 known 1986 paper No Silver Bullet.

The book: modern myth or ancient history?

The 1975 cases are technically not appealing (IBM’s OS/360) and hardly relevant for today’s technological environments. But the organizational topics are striking, with the title essay on top (justly mythical by itself). Although the core statement (“Brooks’ Law”) “Adding manpower to a late software project makes it later” has again been overtaken by history. But 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 seeming to make the lecture vivid again. He formulates views that are greatly in line with… Agile. But then (bis), Brooks doesn’t seem to recognize it and sticks to his ancient solution, i.e. a sort of surgical designers. But since the ‘90s we hàve 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! Of the problems highlighted by Brooks, but in a very different direction than surgical design. Because Agile has a fundamentally different approach on communication and the ‘people’ aspect of software development.

e.g. 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 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. His views on Information Radiators and Osmotic Communication have meanwhile been greatly adapted by Agile teams.

Posted on by — Leave a comment

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

Scrum (all sorts of people)

logo-myfragilityScrum 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:scrum-diamond

think (talk) about it…

Posted on by — 1 Comment

Loving Facebook, Hating Facebook

facebook-logoPablo 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
Posted on by — 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!

Posted on by — Leave a comment

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!