Project planning tools like MS Project generate end dates based on the assumption that productivity is linear result of effort by standard-sized resources. These tools encourage Project Managers to think that one software developer is much like another and to forget team impacts of adding/removing developers in one location or another. More worryingly they often place more trust in what planning tools tell them than advice from local technical team leads.
If I create a 20 day activity then it can be delivered twice as fast by allocating 2 people rather than 1 person. Of course, not all activities work like this - 9 women cannot produce a baby in one month! These tools are based on the fallacy that all people produce equal effort and that adding/removing or distributing them around the world has no impact on existing productivity.
There is evidence that software developers vary vastly in experience and productivity. Also, any software developer will need time to integrate with a team, get up to speed with a domain, technical architecture and legacy code. Outsourcing development will add additional activities in communicating requirements, setting up infrastructure and checking deliverables.
It would be more realistic if such planning tools had a wizard for adding new people which would create the appropriate lags caused when adding new team members.
I just read Agile Software Development in the Large by Jutta Eckstein.
This book tackles the tough topic of scaling agile software development. The author shares stories with top tips from her experience of working on large agile projects.
Several alternatives for communication and organization structures are presented with advice on how to select and refine an approach to fit the project. Much emphasis is placed on reflective practice and the use of retrospectives to help the team adapt the way they work.
If you work in a large organization and have found the standard agile texts leave you with questions about how the ideas might be applied on your project - then this book can help shed some light on many of the issues you may be faced with.
Of course, that said small software projects have the best chance of success.
As a coach I am sometimes asked for guidance on how to write stories. My advice is that form is unimportant, there is no right way to write a story and writing them is not the important part. What is essential, is that a conversation takes place between customer and developer.
I use the Ron Jeffries mantra Card, Conversation, Confirmation as my guide.
1. Writing the story on an index card keeps it small.
2. Without talking to developers, customer cannot know if a story will fit in an iteration.
3. Acceptance tests bound the scope enough to be able to estimate.
So try very hard not to think of the story as a document. It is simply a token in an iteration plan. Treating stories as documents can lead developers to refer to them rather than asking customer and then get defensive if it's not everything is set down in writing. The key is to collaborate rather than get into a contractual mindset.
Since I started working as a coach/facilitator, I have found it useful to carry with me a kit of useful supplies rather than rely on my client's stationery cupboard.
Here's a list of the items that I find useful for XP planning:
* index cards - my preference is white unlined 6x4" (no logo),
* black marker pens
* rubber bands - to keep an index card stack together,
* paper clips - to clip cards together,
* push pins - clear or white head to avoid distracting the eye,
* coloured stickers - to use as progress indicators on cards,
* packet of biscuits or other snacks.
If you do not have a cork pin-board handy for your iteration plan then a large sheet of cardboard works well as a temporary solution.
and for Retrospectives:
* sticky tack - to fix flip-chart paper to wall
* coloured markers - for fips and whiteboards
* post-it notes - at least 3 different colours for timelines
* koosh ball as 'talking stick' token.
Final item is a digital camera to capture outputs. When I write up retrospectives, it's much easier to do this from a photo than unrolling a piece of flip-chart. It's also a way of answering those people worried we might lose our iteration plan - if cards blow away, get left on developers desks, etc.
To follow the XP literature, I probably should also include toys but it's just not my style. Perhaps I should worry but I just don't get a kick out of dart-guns, frisbees, etc.