i saw an interesting article on infoq.com.
the term “fixed bid” is used in the article, but this article applies to another “fixed project situation“, too, i.e., where the resources are fixed, and there’s a specified, promised feature scope and a specified, promised delivery date.
In an agile software team you don’t estimate your work till right
before you begin. And you only estimate, in the case of Scrum, the next
iterations work. So how do you know how long it will take? You don’t.
Furthermore, you really don’t care. You’ll continue to deliver
functionality every iteration. As soon as product management and QA say
you have a good enough product; it’ll be released as a production
version. You might have a guess, but until the team estimates it….you
really don’t know long it will take.In a fixed bid situation….your estimation needs to take place up front.
….
In the 2nd scenario, if I told the team, … “we’re using Scrum”: they’d estimate the work
the next iteration. They would assume their estimates would be taken
seriously and you’d give them time to complete the work as it unfolds
regardless of whether their estimates fit your original project funding
or not. That’s only fair.
alternatively: they would assume they’d get the “time to complete the work with high quality regardless of whether their updated estimates fit your original project plan and delivery date or not”.
[this leads to failure]….at managing the project and therefore…….”this agile thing doesn’t work”.
The mistake was to assume the company’s leadership … was
organizationally committed to … agile principles. The mere fact
that they are asking you to estimate the funding you’ll need to
complete the project tells us otherwise.
alternatively: the fact that they are asking you to commit to a fixed feature set and a fixed delivery date tells us otherwise.
this isn’t bad, per se, it just isn’t agile.
[the real problem]
- Agile is often assumed … to be a development process with no impact on budgeting. This is not the case.
- Development teams assume leadership understands the implications of adopting agile at the budgetary level.
Developers and development teams often have zero visibility into
budgeting so they are unaware of how their agile efforts are being
accounted for in monetary terms. …. Likewise, management is often ignorant of
development and specifically agile development practices. Agile
adoption requires education to ease the clash and misunderstanding of
these two worlds.So what are some of the consequences of attempting to adopt agile
practices on a fixed bid project…essentially laying an agile façade
over the waterfall project?….
Agile does away with the need for a project manager. …. organizing and managing the development effort are more centered on
technical leadership, task and risk management. Timelines and budgets
go out the door.
….
if you’re in a non-agile situation … then traditional PM practices are … essential….
Doing iteration planning in a fixed bid situation will almost certainly
result in confusion, budget variances, and/or loss of functionality.
….In fixed bid scenarios the question is not … how much
functionality the team is doing per time period. It really doesn’t
matter. They need to get all the functionality done …
So using … iterations in a fixed bid project sends the wrong signal to the team and your customers.
using iterations in a fixed project situation sends the wrong signal to the team.
you can still visualize workflow, f.ex. with kanban, reduce work in process, do stand up meetings (very short, impediments only), etc.
but in general you should try to get out of a fixed project situation before trying to go agile.
Edit: About that last part… I think there’s a few basic, agile tools you can utilize whatever you’re doing: visualize how you work; get faster feedback; limit the amount of work in progress.