Iterative Development

Mark talks about the process of iterative software development. This was filmed at our "Introduction to Agile Methods" training course that we did in Plymouth in January 2009.



For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)

The Trouble with Waterfall

Matt talks about his early experiences of waterfall project management methods - this is the first of a series of clips from a training course we did in Plymouth in January 2009.



For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)

White Paper on Agile vs Waterfall, uncertainty and open loops

I've just finished a white paper that I've been wanting to write for a while on the differences between Agile and waterfall project management methods. The perception of many people who are new to Agile is that it actually makes the outcome of projects more uncertain, rather than less.

This is absolutely not true, but I think that sometimes, we don't do a good enough job of convincing people.

Lets Not Start at the Very Beginning (pdf, html)

For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)

Why bother with Agile training?

Just heard this quote from David Allen author of "Getting Things Done":

"Do you folks understand that when they jump you in the dark alley - it's too late to train?"

For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)

Good to see...

...that I'm not the only person thinking about this "difficult conversation" stuff in relation to project management.


http://commentsonmyworld.wordpress.com/2009/01/08/good-pm-3-convey-bad-news/

For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)

Two-day Digital Project Management Course in Central London

We're running a course on Digital Project Management at the Publishing Training Centre on the 23rd and 24th April 2009, the cost of the course is £880 + VAT.

The course takes in Agile Methods, but also covers conventional project management methods, as well as risk management, estimation, negotiation and other practical matters involved in managing a digital project. The course is aimed particularly at the publishing industry and at those people who are moving from managing conventional publishing projects to on-line and digital projects.

For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)

Using a Geometric Mean to Estimate a Piece of Software Development

I've just been reading a fascinating book about estimation:



My friend Tim was telling me about a problem he'd been having when talking to a client about software estimates and I found myself recommending using a geometric mean, although, right there and then over a deep-fried breakfast, I couldn't remember the precise details - so I'm writing them down here.

A geometric mean is another way of trying to get an estimate, slightly more complicated than just guessing, but not that much more complicated. Say you're trying to guess how long it would take to do a website. First of all, guess the maximum that it would take - say 3 months. Now guess the absolute minimum that it would take - say 2 weeks. Now, before we do anything else, put these things in the same units - 60 (excluding weekends) days and 10 days respectively.

OK, here comes the maths part, rather than "splitting the difference" i.e. taking the arithmetic mean between the two numbers. The book that I've been reading suggest that you take the geometric mean which is:

a = √bc

In our example, that comes out at:

ab = 10 x 60 = 600

√600 = 24.5 days

Of course, the arithmetic mean of the two estimates is:

(10 + 60) / 2 = 35 days

I think using a geometric mean may very well be a good way of "loosening up" people's estimating abilities. And also getting them familiar with landscape of possible outcomes of a software development project. Very often, people are just stuck with one figure and start to react with near hysteria when that line in the sand is passed.

Running a few trial numbers through a spreadsheet, it seems that one of the advantages of a geometric mean might be that terrible pessimism only has a mild effect on the outcome. For example for an estimate where the best case is a fortnight (10 days) and the worst case is a year (200 days), the geometric mean is 45.

By getting customers to think of the worst case scenario - maybe by using "yesterday's weather" of software development projects that they've been involved in in the past and then getting them to imagine the best case scenario, you're detaching them from one single figure and forcing them to grapple, just a little bit with the space of possibilities.

For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)

5 Ways Agile Methods Help you Save Money on Software Development

1. Agile methods emphasize working software at the end of each iteration - conventional methods don't

This means that, if you're a client, after the end of each iteration, which might be a week or a month, you will have some tested, working software, which you can use in your business.

2. Agile methods prioritise aspects of development - they deliver the valuable stuff first

Using stories - short descriptions of the functionality that you want - rather than enormous, detailed, specification documents, Agile allows the client to work with the developers to prioritise which stories they should work on first. This means that at any point on an Agile project, the developers are working on the software that is of most value to you and your business. It also means that stories that consistently end up without high priority can be discarded.

3. You can change your mind while you still have time and money

Because development is done in short iterations, you can change the direction of development after each iteration. If new functionality/new stories are required they can be exchanged for old stories. By adding some new stories and re-prioritising some old ones, changes in functionality needn't cost extra cash.

4. If the developers get the wrong end of the stick, there's still time and money to put it right

If you've had any experience of software development, you'll probably have experienced that awful moment when the developers show you what they've done and your heart sinks. You think to yourself - "That's not what I wanted at all!". Agile doesn't promise that this will never happen, it just gives you lots more chances to put it right - and a chance to put it right before all the money is spent and time has run out. One way of thinking of Agile is that it moves difficult conversations to the places where they are most effective - and cost effective.

5. Agile saves developers money as well as clients

Agile gives developers a chance to test their understanding of what the client wants at regular intervals throughout the lifetime of a project - rather than in one very awkward conversation at the end of a project. This greatly increases the chances that the software you're working on is something that your client actually wants rather than just a waste of your time.

If you want to know more about how Agile Lab can help your company save money using Agile methods, email mark@agilelab.co.uk