Home > Archive > Software Engineering > August 2004 > Bureaucracy vs Agile Methods
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Bureaucracy vs Agile Methods
|
|
| Rod Sherwin 2004-08-29, 3:56 am |
| I am currently consulting into government. The way a project roughly
happens here is:
1. A concept brief is prepared to extract money from the department's
budget (a fixed sized bucket). The concept brief needs to include an
overview of features of the system and initial estimates from
development team of time and resources. This is probably based on a
couple of w s investigation and estimation. The budget for the
project is supposed to be enough from start to finish. (Allocation of
scarce resourced from a fixed sized bucket.)
2. Frequently the delivery date is fixed by the passing of legislation
of some other external party.
Agile methods evolve the system over time with consecutive releases
until enough business value is available in the system to release to
the users.
How can this be applied when you need to estimate a budget up front
and you already have a fixed delivery date?
The current strategy is 'big requirements up front' to allow detailed
estimation of resources (= budget). Since the evidence is that this
strategy leads mostly to project failures what other strategies are
there for determining budget and resources needed to achieve a
delivery date?
| |
| clifford shelley 2004-08-29, 8:57 am |
| sd@modelthinking.com (Rod Sherwin) wrote in message news:<44bb31bd.0408281954.4ed8bd63@posting.google.com>...
> I am currently consulting into government. The way a project roughly
> happens here is:
>
> 1. A concept brief is prepared to extract money from the department's
> budget (a fixed sized bucket). The concept brief needs to include an
> overview of features of the system and initial estimates from
> development team of time and resources. This is probably based on a
> couple of ws investigation and estimation. The budget for the
> project is supposed to be enough from start to finish. (Allocation of
> scarce resourced from a fixed sized bucket.)
>
> 2. Frequently the delivery date is fixed by the passing of legislation
> of some other external party.
>
> Agile methods evolve the system over time with consecutive releases
> until enough business value is available in the system to release to
> the users.
>
> How can this be applied when you need to estimate a budget up front
> and you already have a fixed delivery date?
>
> The current strategy is 'big requirements up front' to allow detailed
> estimation of resources (= budget). Since the evidence is that this
> strategy leads mostly to project failures what other strategies are
> there for determining budget and resources needed to achieve a
> delivery date?
(A warning indicator is the word 'detailed'. Detailed is not the same
as accurate. Accurate estimates are not produced at the beginning of a
project. Projects involve risk and uncertainty.)
There need not necessarily be a 'versus' at at all. They could be
complementary.
Any incremental or evolutionary methods will probably be delivering
value, to the customer and as determined by the customer, well before
fixed delivery (finish?) dates, assuming these are credible.
Additional advantages are the opportunity to refine estimates (which
should have best, worst and most probable figures). If budgets are
assigned and fixed either on the basis of estimates or non-negotiable
targets then incremental/evo delivery provides early indicators of
their credibility with velocity figures or 'burn down' rates from the
work which can be used to refine the estimates, and manage resources
and risks - which should be valued by your customers too.
Potential downsides are that there is a need to produce 'big
requirements'and other big bang/waterfall deliverables that developers
may feel are unreal or an unhelpful overhead. This lack of cred can
leak into other aspects of the work. Try to reconcile approaches and
use project model and supporting admin to advantage, rather than fight
it. (It need not be 'bureaucracy', rather think of it as additional,
useful investigation opportunities, and project administration and
control?)
You may also find that intermediate deliverables - requirements,
designs and other 'non agile' documents - is need to trigger staged
payments, so make them as good as possible.
| |
| Asko Saura 2004-08-30, 3:57 am |
| Rod Sherwin <sd@modelthinking.com> wrote:
> I am currently consulting into government. The way a project roughly
> happens here is:
> 1. A concept brief is prepared to extract money from the department's
> budget (a fixed sized bucket). The concept brief needs to include an
> overview of features of the system and initial estimates from
> development team of time and resources. This is probably based on a
> couple of ws investigation and estimation. The budget for the
> project is supposed to be enough from start to finish. (Allocation of
> scarce resourced from a fixed sized bucket.)
> 2. Frequently the delivery date is fixed by the passing of legislation
> of some other external party.
> Agile methods evolve the system over time with consecutive releases
> until enough business value is available in the system to release to
> the users.
> How can this be applied when you need to estimate a budget up front
> and you already have a fixed delivery date?
Those two constraints are particularly useful from an agile PoV. When
you can't vary the budget and the delivery date, you will have to play
with project scope. XP in particular is concerned with just this.
Your initial concept brief will include a guess on the major features
and a guess on the budget required for those, same as any waterfall
project. Once you get the money, you'll go agile for the duration of the
project, ending up with some working subset of the initial planned
features at the planned time. You'll be on budget and on time, but the
system you'll have may not have all the planned features. It may have
other features discovered on the way. This is a good position to
yell "success!"
> The current strategy is 'big requirements up front' to allow detailed
> estimation of resources (= budget). Since the evidence is that this
> strategy leads mostly to project failures what other strategies are
> there for determining budget and resources needed to achieve a
> delivery date?
Do the same thing, but use less detail. If you can't do a budget based
on less detail, you are likely have experience with doing things in a
Big Budget Up Front manner anyway. If your experience is that those
things won't work for you, you'll not miss the detail on the budget
input.
--
Mä oon matkalla sinne missä
-as@iki.fi - http://iki.fi/as/
| |
| Scott Kinney 2004-08-30, 3:58 pm |
|
"Rod Sherwin" <sd@modelthinking.com> wrote in message
news:44bb31bd.0408281954.4ed8bd63@posting.google.com...
> I am currently consulting into government. The way a project roughly
> happens here is:
>
> 1. A concept brief is prepared to extract money from the department's
> budget (a fixed sized bucket). The concept brief needs to include an
> overview of features of the system and initial estimates from
> development team of time and resources. This is probably based on a
> couple of ws investigation and estimation. The budget for the
> project is supposed to be enough from start to finish. (Allocation of
> scarce resourced from a fixed sized bucket.)
>
> 2. Frequently the delivery date is fixed by the passing of legislation
> of some other external party.
>
> Agile methods evolve the system over time with consecutive releases
> until enough business value is available in the system to release to
> the users.
>
> How can this be applied when you need to estimate a budget up front
> and you already have a fixed delivery date?
>
> The current strategy is 'big requirements up front' to allow detailed
> estimation of resources (= budget). Since the evidence is that this
> strategy leads mostly to project failures what other strategies are
> there for determining budget and resources needed to achieve a
> delivery date?
In one of his books, Ed Yourdon has a concept about requirements
that you might find useful: "good enough to work with, flexible enough to
change".
"Good enough" has a few meanings; not overly detailed, not over-driven,
good quality, explicit without being elaborate, measurable, business
functional,
not 'false requirements' (as Thomas Gilb would call them.)
Can you generate 'good enough' requirements in a brief investigational
period? Are your requirements gathering skills 'good enough'?
In addition, how are you doing the estimating? Do you use historical data
from similar work on the same applications or systems? Do you use
any of the available estimating tools that compare work, complexity, and
so on against a broader database of similar projects? What kind of
'reality checks' do you apply to estimates supplied by other groups?
('You estimated that X report can be done in 1 w. The last 3 reports
you did on projects A, B, C each took 2 ws or longer. What's
different about this one?")
Scott Kinney
P.S. Over the last few years, I've done a number of projects whose
'due dates' were driven by legislation. They were, in fact, compliance
projects. Compliance projects have very stable requirements; the
functional requirements are documented in the law itself, and are
not subject to rapid or unexpected change. Also, 'compliance'
is pretty binary; you're in compliance or you're not.
For these reasons, an agile approach does not make a lot
of sense. Treating stable requirements as if they might change
is like walking through your office as if the floor might give
out from under you at any moment. Also, there's no 'business value'
until compliance is achieved. There might be good reasons to
use an agile approach on a compliance project, but requirements
instability, and sneaking up on business value are not two of them.
| |
|
| Asko Saura wrote:
> Those two constraints are particularly useful from an agile PoV. When
> you can't vary the budget and the delivery date, you will have to play
> with project scope. XP in particular is concerned with just this.
>
> Your initial concept brief will include a guess on the major features
> and a guess on the budget required for those, same as any waterfall
> project. Once you get the money, you'll go agile for the duration of the
> project, ending up with some working subset of the initial planned
> features at the planned time. You'll be on budget and on time, but the
> system you'll have may not have all the planned features. It may have
> other features discovered on the way. This is a good position to
> yell "success!"
Sort features in order of business value. Implement for a w, release a
demonstration version, and re-sort by business value. Sorting only works if
you reevaluate frequently.
Control scope in real-time, during each w. Cancel any detail of any story
that should not affect velocity.
Someone recently posted, somewhere, Big Requirements Up Front is like a
Christmas List. If you can only ask for 5 things, you will ask for them up
front or you won't get them. If you instead have a magic lamp that deals 5
wishes, each on command, you will ask for one and then wait for a reason to
spend the others. The second process is more relaxed and accurate, and will
generate a substantially different list.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
| JXStern 2004-08-30, 3:58 pm |
| On 28 Aug 2004 20:54:52 -0700, sd@modelthinking.com (Rod Sherwin)
wrote:
>Agile methods evolve the system over time with consecutive releases
>until enough business value is available in the system to release to
>the users.
That does not preclude the process being mapped out from day one.
>How can this be applied when you need to estimate a budget up front
>and you already have a fixed delivery date?
Nothing new here, you're just time-boxed, you can do that with or
without agile, iterative methods.
Schedule N iterations over the period, divide functionality into
phases, each iteration both adds functionality and refines earlier
work, INCLUDING earlier estimates of later phases. If time presses,
you need to throw some features overboard to stay on schedule.
Basic stuff, or so I thought.
J.
|
|
|
|
|