Well, we’re back. We participated in the Agile Project Leadership Network Summit as well as the actual ABC. Being three of us we managed to cover most of the presentations. Of particular interest was the British Telecom decision to transfer their 14000 persons IS/IT business to Agile. There where some ups and some downs, perhaps I’ll transform my notes into a blog entry in the near future.
Responsive Going to Agile Business Conference
All of us (all 3) are going to the Agile Business Conference in London on 7-9/11. Initial day will be Agile Project Leadership Network Summit. We hope for some interesting presentations and workshops.
Coder’s Dojo Sweden is open!
Yesterday Andreas Larsson and myself hosted the first ever Coder’s Dojo in Sweden. If you have never heard about it before you can visit its home page and explore more.
It was an interesting experience. Having run through the Bowling Kata a number of times, both together and by ourselves, we still found that discussing with people was a learning experience since many of the attendees did not have the experience we did. And as always, talking about something forces you to be clear in a way you don’t need to otherwise.
My personal insight with the Kata the way we played it out (inspired by Uncle Bob’s presentation of it) was how strong the urge to create new classes is in all of us. Andreas and I fell into that same hole when we did the Kata in Oulu the night before XP2006.
I also discovered that I had insights that I where not aware of with regards to the brittleness of testcases; that you should be careful to test the intended behaviour, and not the design. E.g. when doing the first test case for the Bowling Kata, don’t test that the score of the created (presumed empty) game is zero. That’s implementation! The required behaviour (and the only thing that should be tested) is that calculating the score, after all the rolls of the game, should give the correct result.
And of course, you can find a lot of thinking on the BDD (Behaviour Driven Development) on the web.
Development is Investment
One irritating circumstance in the world around development is the fact that customers and company managment tend to view the voyage of development as something that has to be calculated like any other investment. Or at least I thought it was irritating until last week.
This investment calculus that has to take place upfront drives big design upfront, detailed planning and everything bad that goes with a model with “upfront” in it.
But last week I had a discussion with my two collegues about how to draw a curve illustrating the fact that we need to get early payback from any development project or activities. I suppose you have all experienced the fact that given multiple checkpoints a long the way, as opposed to only a single at the end you are much more likely to hit the target (after all that is what being agile is all about).
We started talking about how to visualize the fact that worked hours (the most common tracking parameter for development projects in the world, it seems) is not a good way to measure, and consequently show in a follow-up diagram, project progress. Instead it is the value of the current development result that should be put on the y-axis. This is actually nothing new (what is?), already function points and earned value are classical methods to do something this.
But the real insight here is that if we just could turn this earned value (which in agile terms of course is working functions delivered) into money we would be in a position to argue all the benefits of agile thinking to management and into the contract problem area.
Why? Because to a company executive it is easy to understand that the value returned did not come from exactly what we planned but we could still cash in the same value. Dollars for dollars, as it where. This opens up a possibility to work agile in rigidly contracted environments also, if only we can formulate the contract in terms of investment and return on investment.
So how would we estimate progress in terms of ROI? Well, I guess that anyone that can guess the ROI on a completed product, given some essential functions and properties, could also do a fairly good job of estimating partial value of same. So, do an earned value estimate on each function (or story or UseCase according to your preferences), follow up on that, and handle any change in features also as a change in the earned values. Then trade one earned value for another and, if they are comfortable with the estimated values, they will have no objections to whatever changes your agile project uncovers or requires.
A Vaccum Cleaner and an Aircraft
What is the similarity between an aircraft and a vaccum cleaner? Often product developing companies get stuck in old thinking. No surprise there, but what I mean this time is their thinking about what is their primary competence and as a consequence of this, how they need to think about their product development.
Apart from the pure software products there is a large number of products being developed out there, which, some decades ago where hardware only, but now also includes software, often increasingly so.
Since the company has successfully developed products according to rules and conditions which are valid for a hardware only product, it is often difficult to make managers on all levels to understand that once you introduce software in a product, you are in a completely different ballpark.
Software has completely different characteristics, different minimal lead times, different complexity properties which must be taken into account when organising product development. This is is not only a difference, it is also a set of opportunities to exploit. One of the more obvious opportunities is the the short lead times possible, which, if done correctly, could mean shorter time to delivery, shipment and return on investment. This means, of course, becoming more agile, but it doesn’t stop with the development -Â project, product and company management must embrace the agile principles and change their thinking.
If you cross a vaccum cleaner with a computer you get a computer, and if you cross an aircraft with a computer you also get a computer!
One you introduce software in your product you are stuck with new values, characteristics and opportunities. Too many developing companies fail to exploit these opportunities for rapid return on investment and improved quality.