November 10, 2004

Release 2: the NoVNoS framework...too radical?

What about the NoVNoSNoP (No Value - No Story - No Product) approach? Would that be too radical?

I am spending a bit more time going over the case study I will present on the 25th November at XP Day 2004, and frankly, I can see some real added value in what we managed to achieve during this project.

For those who cannot attend the conference, here is in substance what I demonstrate:

Because our IT function declared it was "Agile", the "Business" thought they could throw anything at it and magically transform it into golden outcome. In other words "we don't really know what we want, we don't really know how much value there is in there, we don't really know if it plays towards our strategic corporate goal... but, we know how much budget we can give you (with capitalisation vs revenue split!!!), and how long you have to do it.

Whoah! Wait a minute, that just does not work!

XP states (sorry, most of XP practitioners state) that XP is really good at delivering business value... well, sorry, but this is completely wrong.

XP is really, really, really good at delivering the value which has been built into the story pack. If the story pack or basket is full of stories that deliver virtually no value to the business, then XP will be really, really, really good at delivering nothing at all (apart from good quality software).

Now, let's imagine a world where no XP team would start delivering before the value in the pack of stories is in line with the strategic corporate goals, and that the overall value of this pack is to a level satisfying strategic milestone objectives. That would be a good idea... I think.

One way of ensuring that companies build this story pack value the as efficently as possible may be to apply the NoVNoSNoP principle.

ONLY WRITE STORIES THAT DO CARRY VALUE (this is to be moderated by the fact that there are Minimum Marketable Features that might not carry any value but still need to be story boarded).

I have managed to apply this principle to one of my projects, with distrurbing results. If you want to know more, please visit the http://www.xpday.org/ website (session slides section), and download the eXtreme Analysis slides.

Release 2: Pair Programming and Programming Outcomes

One of the most controversial practice of XP is that it advocates the use of Pair Programming.

Why on earth would you want two people in front of one screen, sharing one keyboard. Surely this is a waste of time and money, and the capacity or velocity of the team would be improved if we did not do pairing at all.

Maybe, maybe not... In fact, probably not.

Some research has been done (http://www.pairprogramming.com/) to try and compare singletons and pairs in code production.

When somebody sits down to write some code,


  1. they don't just code, they also "communicate"
  2. there are more than one outcome to this action (ie: sitting in front of a computer to "produce code"). The first few outcomes I have in mind are code does what it is supposed to do + coding conventions are respected + it is the simplest thing that could possibly work + it is refactored + test is writtent first + integrated at often as possible...
  3. nobody can for an extensive period of time keep more than one primary outcome in mind and deliver to all of them (see above, there are probably more outcomes actually).
  4. we are after all human and can make mistakes
  5. we are after all human and need a bit of encouragement and recognition when we do something is always welcome. A pair can provide this.
So, why is it so difficult for the teams who want to pair to be able to do so?

One of the reasons is that whatever we say, we are bums on sits, and we cost money. The source of this money is largely the "Business". They mandate the IT function to do stuff, and there is no metric that exists to actually convert them to the fact that it is not how much code you write that matters, it is how good your code is for the project and the rest of the organisation.

The "Business" speak about Total Cost of Ownership (TCO) as a measure of how much a project will really cost. Needless to say that this measure is most of the time based on finger in the air calculation, that nobody really endorses and signs up to.

There is yet no plan to introduce the notion of Total Value of Ownership, where the utlimate value of a programme/project/storie and eventually how it is delivered comes into play. If this did exist, pair programming could be "sold" to the business. One of the main "Business" and "IT" disconnect regarding XP could be overcome...


November 02, 2004

Iteration 2: Planning Game

This week, I plan to deliver posts on the disconnect that exists between the "Business" and "IT" when it comes to XP.

Still in the story pot:

Story ID: 1 (from Iteration 1 Planning Game)

  1. Create blog (Estimate: .2) (Status: done)
  2. Publish blog (Estimate: .2) (Status: done)
  3. Communicate blog address to trusted contacts (Estimate: 1) (Status: done >> will need V2 for increased value though)
  4. Publicise blog (Estimate: 5) (Status: done)
New stories:


Story ID: 2.1


Estimate: 3.5
Type: BAU
Status: Complete (will require V2 for further value release)
Value: 5


Description:
As a project manager, I want to highlight some of the disconnect I have witnessed between the "Business" and "IT" when it comes to using XP so that I can compare it with other people's experience.


Acceptance criteria:

  1. Posts must clearly have both Business and IT as central stakeholder's
  2. Posts should present disconnects
Tasks:

  1. Do retrospective on the last 2 years in terms of disconnect between Business and IT (Estimate: 1) (Status: done will need V2)
  2. Break down output into themes (Estimate: .5) (Status: done will need V2)
  3. Create and post blogs (Estimate: 2) (Status: done)