Combining Agile with teh need for Business Cases

[christophe...@ntlworld.com]

Hi, I'm Chris Baker, a freelance project manager and newly-joined
member of this group.

I'd like to discuss the major hurdle I find in getting Agile methods
adopted - that the organization wants to know up front what it is
getting, when and how much it will cost. That is, of course, what an
old-fashioned Business Case and PM approach SEEMS to give you. Things
of course don't always ACTUALLY work out as planned, but instead you
do have a nice picture of the overall plan to show the boss, and
figures to put in you budget, which you may have to do many months in
advance of the expenditure.

Agile includes an element of figuring-it-out-as-we-go-along. This
alarms folks who can remember badly-planned software projects of old
which meandered around until time or money ran out.

How to convince people that they are not leaving themselves open to a
return to no effective overall planning?

[Tim Pizey]

Hi Christopher,

If you can make a plan then do. Agile is primarily useful when you cannot
make a plan, so any plan you make will necessarily be a fiction.

Agile should not mean sloppy or lazy.
I also do not buy into the 'past high profile failures were all due to
waterfall'
line: government contracts die because they have politicians as customers.

If you have real customers within an XP framework, ie a customer representative
who has the power to approve spending, then agile/xp can help.
If your customer is a politician, rather than a business man, engineer or other
honest citizen, then your project will 'fail', even if the engineering
goes well.

cheers
Tim

--
Tim Pizey - http://pizey.net/~timp
Centre for Genomics and Global Health - http://cggh.org

[jageall]

Hi Chris, Tim,

I only meant to write a couple of lines, but my fingers got carried
away. Hopefully I haven't waffled too much and with some luck, some
of it will be useful.

I would agree that this is the most common major hurdle I normally
face. I don't agree that agile is primarily useful when you don't
have a plan. Agile, and particularly scrum has more time spent
planning than almost any other methodology I can think of, it's just
that we don't tend to have a gantt chart as a deliverable. The team
may need to spend quite some time (a few days for a big backlog) doing
the planning (which is breaking stories down, identifying the value of
the stories, estimating the story points for a story)

I think that the key thing to winning an organisation over are to
focus on value delivered versus cost of delivery. If you can get the
client to put a monetary value for completing a user story (and oh boy
can that sometimes be hard) and the team estimate a cost for
completing it (story point) you are doing a cost benefit analysis on a
per feature basis. The key benefit of the value being put on the
story is that the user is making a decision about what is important
before you start and telling you about it(which they often forget to
do until things are going wrong!) and it is something that they will
have to justify to the organisation if things are done in the wrong
order.

If you then get the team to work out how much work they think they can
pull into a sprint you can do an initial velocity plan which will give
you a ball park figure for how many sprints you will need, obviously
not very accurate unless the team is already familiar with the product
and has worked together for a while. But that gives you an initial
schedule, an estimate of the total cost and a window when the project
will probably finish. Which is pretty much what the business case
and overall plan is, we just put the stuff of least value at the
backend of the project so if the plan is wrong the project can still
succeed.

Issues I have had with this:
The team does not exist yet - means you have to guess the velocity and
story points which will be wildly inaccurate
The business won't/can't put values on stories
The backlog contains stories that are too large to have accurate
estimates of value/story points
Churn in team members between the initial estimates and the actual
implementation

So for me:
The product backlog is what you will get in business priority order.
Story points give you an idea of what each will cost to implement.
Sprint planning tells you how much you are going to do in a sprint
Velocity planning tells you how many sprints you need to get the
product backlog done.
Cost per sprint is easy to calculate, so cost for the backlog can be
calculated for budgeting.

I'd add some contingency (hardware/software costs, team pizza etc) and
then you have your budget figure.

On the subject of folks with alarm bells, I would point out that at
the end of every sprint you will be demoing production ready code so
that they can visibly see the progress through the backlog and make
informed decisions about the project as it goes along. The demo's are
critical to build trust.

Sprint planning and re-estimating the story points each sprint is a
commitment to review the plan on a regular basis to ensure progress is
on track, and an opportunity for the product owner to add or remove
work. It is therefore essential that the product owner is the person
responsible in the business not just for what the project does, but
that it comes in on budget. (Pretty much what tim was getting at with
having an honest citizen as the product owner)

James

> Tim Pizey -http://pizey.net/~timp
> Centre for Genomics and Global Health -http://cggh.org- Hide quoted text -
>
> - Show quoted text -

[christophe...@ntlworld.com]

Hmm - useful points. So maybe a good starting point is to pick a
project where everyone agrees that conventional planning is
particularly difficult. Agile should have a clear advantage there, and
whether or not agile is superior under wider circumstances (or all
circumstances) can be left as moot for a while.

Do you find that organizations that adopt agile then become converts?
A bit like usability work perhaps - it can seem far to fluffy to be
useful right up until the point where the team sees a user struggling
with a well-meant piece of functionality and suddenly see the light?

[Tim Pizey]

I do not think that agile is much used in Big Science ( I may be wrong).
Similarly it is not so great for engineering.

Where it is useful, IMHO, is providing a framework for the
requirements owner (client/customer)
and the development team to explore an unknown space, that is a space
where there are still
choices to be made.

This can be very useful for taming end users who are new to system
implementation and want the world on a stick.

cheers
Tim
PS Is scrum still agile? It is pretty inflexible here.

--
Tim Pizey - http://pizey.net/~timp

[jageall]

Although they are not my field, I would guess this is because Big
Science and engineering often don't have the advantage of being able
to rebuild any part at anytime due to physical implementations of
those models.

The iterative process of agile methods allow the user(who may well
know exactly what they want upfront) to feed back to the development
team about anything that didn't make it from the user's requirements
into the implementation. The reason it wasn't in the implementation
may be because of a misunderstanding rather than a change in
requirements. This can be really useful when the user has expert
system knowledge that the developers don't.

Scrum is agile, not all implementations of scrum are actually scrum :)

> Tim Pizey -http://pizey.net/~timp

[jageall]

I have seen some success where the team internally worked in an agile
manner but where the project appeared to be prince2 to the business.
It does require stealing a user and a tester or 2 and making them part
of the team. Success and a good post-mortem on the project led to a
much greater openness within that organisation to change how projects
were delivered and more projects were delivered using agile methods.
It was not a small organisation either.

On Oct 27, 10:13 am, "christopher.baker....@ntlworld.com"