AGILE IN ACTION

I said this today: 80% of the business value is typically delivered by 20% of the features . I was speaking with someone who was trying to convince me that all 267 features identified and specified by the business analyst were absolute must-haves for the product to be attractive to end users. I guess he'd never heard of the Pareto Principle more commonly known as the 80-20 Rule .

In my post Getting to know people , I referenced a simple questionnaire that I use in my coaching which is based on the Myers-Briggs Indicator and classifies a person's type (alternative descriptions of type are available here ). I thought it only appropriate to share my type with you:

A Scrum Master steers a Scrum team like a gifted helmsman steers a boat. He uses the lightest of touches because he knows that each use of the rudder produces drag, which holds the boat back. helmsman Originally uploaded by sjb140470 . This is based on an analogy found in Tom DeMarco' s book, Slack .

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 .

One of the branches I've had on my to-do mind map for ages is to build a personal agile consulting toolkit. This is simply a collection of cheat sheets, artifacts, articles, links, etc. One of the sub-branches is to produce a list of games and simulations that are available. The infamous XP Game , which introduces a development team to the planning game, velocity, user story estimation, yesterday's weather and the cycle of life. The Extreme Hour where a team gets 1 hour to completely develop and test a fictional product using Extreme Programming principles and practices. Jean Tabaka's 59 Minute Scrum , which simulates a sprint planning meeting, a sprint with daily scrum meetings, and a sprint review meeting. James Shore 's Offing The Offsite Customer demonstrates the difference between having an onsite customer or product owner that works directly with the development team and having the same customer or product owner located offsite working indirectly with the development team through intermediaries or documentation.

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.

The time is coming when every person who lays claim to ability (i.e. agility :-) will keep the question of waste before him constantly. The scope of thrift is limitless. - Thomas Edison

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.