Over the past few years the software community seems to have come to attach totally positive values to an agile approach and wholly negative ones to other methodologies. Agile is the new and the future, everything else is old, dusty and past.

We also completed a few projects in this sphere, although I yet have to come across a museum customer that endorses or even allow us to work using an agile approach. Specifications are always set at the beginning and everyone want to know what they are getting out of their budgets - at the start or near the start of the process. There is a technical reason agile project cannot go over budget, as the customer buys 'points' (which translate to man days) and establishes priorities. They would not know what they get at the end of the process, as as soon as the points are over, so is the project - unless some of the important features got left out and a new scope and stage is required, which necessarily involves more time and budget. I understand why software developers love this approach, as the entire risk falls onto the customer. I also understand that with entirely experimental work, this is a good system. What I'm not sure about it's that it's the only one that everyone should use in every situation.

At the same time a waterfall approach does not necessarily mean that the client *must* know everything in advance, as they may not have the design and technical expertise to do so - but also as that would neglect the fact that they are working with experts in the field. As a designer and software developer, I feel that our role and responsibility is not only to execute (and especially to execute what we know is wrong!) but also to consult and help our clients getting the best out of their brief. In that respect, a project may include some budget for scoping and specifications. The crucial difference is when you decide what you will get out of the project: with a considerate waterfall, you'd know a few days or weeks after the start, with agile you know at the end. And that may not be what you wanted. Plus a considerate waterfall approach would have some built in contingency to make room for some change.

When there is a complex project, my preferred approach would be to offer an initial consultation stage, for a fixed budget and set of deliverables, to clarify what the final result should be. At that point, you should be in a position to know where you are heading and can share the risk with your customer.

Best, Cristiano



> >>
> I'm not an expert in Agile approaches http://en.wikipedia.org/wiki/Agile_management but my concern over an iterative approach is that it unbal;ances control of the project in favour of the software expert. That may be fine, but my view is that its the service provided by the technology that is important, rather than the technology itself, and the museum folks are best placed to judge the effectiveness of that end result.
> >>
> Hmm, There's many flavours of agile approaches but I really wouldn't agree with it makes the technology more important than the technology provided by that service or that it "unbal;ances control of the project in favour of the software expert"
> 
> In a waterfall approach its up to the client museum to come up with an exact specification of what they want despite never having build one before. All the software person has to do then is build it to the specification - even if it turns out to be wrong. What almost always happens is that once the project is built the client realises that they need alterations to the specification which the contractor then charges more for. So it's very usual for waterfall projects to go over budget.
> 
> With an agile approach you set down you requirement priorities and ask the contractor to come up with a prototype which fulfils the most risky ones. You "the museum folks" then get to judge "the effectiveness" of "the service provided by the technology" of that prototype. This is particularly useful for things which are difficult to specify like "easy to use" or "fun". Depending on your judgement the contractor either then gets another go to refine their effort to meet your priorities or adds some of the less important features. Agile approaches are less likely to go over budget but you're more likely to end up dropping some of the less important features because you spend the time concentrating on the getting the most important ones right.
> 
> What I think may bother Ed about Agile approaches is that it seems that you need a higher degree of trust in your contractor because you don't have a final list of specifications to check off at the end. My experience though is that because you're asking  for frequent working prototypes you get much better feedback on progress than if you're just expecting the final product to pop out at the end.
> 
> Cheers
> 
> Joe
> 
> 
> 
> Joe Cutting
> Digital exhibits and installations
> @joe_cutting
> www.joecutting.com
> 35 Hospital Fields Road, York, YO10 4DZ
> 01904 624681
> 
> ****************************************************************
>      website:  http://museumscomputergroup.org.uk/
>      Twitter:  http://www.twitter.com/ukmcg
>     Facebook:  http://www.facebook.com/museumscomputergroup
> [un]subscribe:  http://museumscomputergroup.org.uk/email-list/
> ****************************************************************

----

Cristiano Bianchi
Keepthinking

43 Clerkenwell Road
London EC1M 5RS

t. +44 20 7490 5337 (Office)
m. +44 7939 041169 (UK)
m. +1 347 681 2471 (US)
m. +852 9706 6581 (HK)
m. +39 392 9939359 (IT)

[log in to unmask]
www.keepthinking.it  


****************************************************************
       website:  http://museumscomputergroup.org.uk/
       Twitter:  http://www.twitter.com/ukmcg
      Facebook:  http://www.facebook.com/museumscomputergroup
 [un]subscribe:  http://museumscomputergroup.org.uk/email-list/
****************************************************************