It feels like there's quite a false dichotomy here between the
methodologies.
As I understand them, Prince 2 is strong for the start and end of a
project, but not hugely useful or specific about the actual building bit.
Agile as an approach is very strong on building, but not on initiation. So
they can very comfortably exist together, and you can easily pick the best
bits of both.
The Guardian runs a pretty classic agile process, and in my experience its
strength lies in its prioritisation of extremely regular communication
(daily stand-ups and biweekly planning and evaluation) and regular,
working, code-drops and demos. The projects I've seen go most wrong are
those where designers, devs, and managers weren't in very close contact,
leading to confusion, and agile is great at ensuring that this doesn't
happen. As noted by others, it also lends itself to helping you see
progress easily, which leads to nipping problems in the bud, and useful
prioritisation.
Hope this helps!
Tom
On 22 Feb 2013 11:08, "Cristiano Bianchi | Keepthinking" <
[log in to unmask]> wrote:
> 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/
> ****************************************************************
>
****************************************************************
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/
****************************************************************
|