Tuesday, January 10, 2006
Saturday, January 7, 2006
Friday, January 6, 2006
During development we want to constantly measure how much more work we have to do and how fast we are doing work so that we know where we're at. Mike Cohn uses a nautical metaphor in his new book, Agile Estimating and Planning , to explain tracking a release. He identifies 3 factors that should be taken into account: The amount of progress that has been made by the development team. Any changes to the requirements. Developers may have learned things that make them want to revise estimates for future work in the release. While discussing tracking on Mike Cohn 's Agile Planning newsgroup, I came across a similar 'aeroplane in flight' metaphor. Unfortunately, I cannot find the original article to provide a reference. In this metaphor our measurements become: How much more work we have to do = Relative distance still to be travelled by the aeroplane. How fast we are working = Aeroplane's velocity. The factors identified by Mike Cohn are similar to the forces experienced by an aeroplane whilst in flight. aeroplanetrackingmetaphor Originally uploaded by sjb140470 . Drag (changes in requirements) will cause the aeroplane to travel less distance than expected, and if the cross-wind (changes in the estimates) blows from the north while the aeroplane is heading west, the aeroplane will also drift to the south. Without course corrections, the aeroplane will take longer to get to the target destination. The metaphor has more mileage (if you'll forgive the pun :-) ... Adding legs to a flight is like adding user stories to a release. You can add all the legs you want, but unless you can increase the aeroplane's speed you are going to arrive at your destination later. Increasing the speed of the aeroplane by increasing the engine size is like adding more team members. Installing new engines will cost installation time. Increasing the speed by pushing the engines harder is like working overtime. But this will decrease the engine's life span. Aircraft maintenance is like unit testing and merciless refactoring . Neglecting ongoing maintenance can be expensive with an aeroplane (project) grounded when it's supposed to be in the air or an aeroplane crashing to the ground. Boarding a plane is like release start-up overhead or iteration zero .
Thursday, January 5, 2006
After XPDAY5 I contacted Scott Gilbert at enthiosys and asked for a set of the innovation games cards used by Steve Freeman and Andy Pols in their session Getting To Know Your Customer . These cards arrived over the Christmas break while I was away in Austria and I'm now really looking forward to using them as part of my consulting To my surprise Scott also kindly sent me a copy of Luke Hohmann 's new book Beyond Software Architecture, Creating and Sustaining Winning Solutions . I'm looking forward to reading this.
Tuesday, January 3, 2006
Monday, January 2, 2006
In his post Doing fast things or doing things fast , Jeffrey Phillips says "there's a difference between efficiency and effectiveness, mostly in terms of intent". The difference between efficiency and effectiveness is one of the topics discussed in Tom DeMarco' s book, Slack . In the book, Tom DeMarco quotes Tim Lister as saying " People under time pressure don't think faster ". Basically, when working with software, thinking takes as long as it takes and there's nothing you can do to think more quickly. So if you want things to go faster you have to find other areas in which to accelerate. Tom DeMarco identifies the only options for making things go faster as eliminating wasted time, deferring non-critical work, and working late. If you're using agile techniques you'll be addressing some or all of these options already. Eliminating wasted time : Tom DeMarco says that healthy 'knowledge-workers' don't waste a lot of time anyway because they're more likely to be frustrated by it. One of the rules of lean development is to eliminate all waste, including wasted time in the form of extra processes, unwanted features, task switching, waiting around, and motion or chasing around, perhaps seeking answers to questions. Deferring non-critical work : Tom DeMarco says that healthy 'knowledge-workers' derive satisfaction from accomplishment and are therefore likely to work on tasks on the critical path. Extreme Programming uses an onsite customer and Scrum uses a product owner to prioritise the work by business value, and the development team selects an amount of work equivalent to their velocity from the highest business-value items. Working late : Tom DeMarco says that, in the short-term, working late can boost productivity but in the longer term excessive hours cannot be sustained. When you work late for extended periods your personal life and your health are not the only things to suffer. More directly, your concentration levels, your ability to focus and think clearly, and your attention to detail deteriorate and ultimately degrade the quality of your work. This style of working rapidly becomes a negative spiral. Extreme Programming employs the primary practice of energized work , which states that you should work only as many hours as you can be productive and only as many hours as you can sustain.