Is agile smaller dimensions of water fall model?

[amita nagotra]

Is agile just a smaller dimension of the waterfall model , with fewer changes like it would be between two versions of a same product...?

[amita nagotra]

Does the book cover the significant and smallest differences between agile and water fall..?

[Ilja Preuss]

No, Agile processes aren't just small waterfalls. There are significant differences in what gets done when, who is responsible for which part of the work and how collaboration and communication is organized.

For example, a good Agile team will not wait to test the system until after the implementation is "done", but will do it at least concurrently. Ideally, the tests are even implemented *before* the production code.

[Ilja Preuss]

By the way, which book are you referring to?

[Stan James]

This one.

I think Kent Beck may have drawn a picture of waterfall as one sequence of analysis, code, design, test, deploy and XP as dozens of repetitions of the sequence, none more than a few minutes long. But it really isn't the same even at that tiny scale.

Vast oversimplification: Waterfall seeks to eliminate risk by thinking really hard in the early stages and checking really thoroughly at the end. Agile seeks to eliminate risk by building running software and validating it with the user in a very fast feedback loop.

[Ilja Preuss]

Originally posted by Stan James:
This one.

I wasn't aware of the fact that "Manage It!" is a book about Agility. (Well, it *is* from the Pragmatic Bookshelf, which could be a hint. Still not sure...)

[Johanna Rothman]

Agile and waterfall are very different. (Yes, there is a chapter and an appendix in Manage It! to show the differences between the two lifecycles.)

Waterfall assumes that you need to manage cost, and that the project will proceed relatively linearly to a successful conclusion. (Very few projects do.) And in waterfall done right, there are bazillion checks and balances built in, to make sure you are building the correct product. In Manage It!, I have some suggestions of when you could use a waterfall, and what to do if you're stuck in one.

Agile assumes the project is non-linear. You will have changes to scope. You might have changes to team membership (at the end of a timebox). But the key is that Agile embraces change, while waterfall has to hold off or contain change.

Johanna

[amita nagotra]

Thank you all for such elaborate discussion on the topic.

Is it possible to move a project (may be not legendary) following a waterfall principle to agile half way through its life time?

Another question ..
In agile is there a suggested span for an iteration or is it project specific ?
I worked in two projects with agile methodology , one had rigorous deliverables set for a every EOD, and the other had a release every fortnight.

[Frank Carver]

Originally posted by amita nagotra:

In agile is there a suggested span for an iteration or is it project specific ?
I worked in two projects with agile methodology , one had rigorous deliverables set for a every EOD, and the other had a release every fortnight.

In the limiting case, Agile can work with iterations so small that they effectively disappear. In such a situation, the project is driven by a "backlog" (or similar concept, we tend to informally refer to it as a "bug pile" here). The job of managing the project consists largely of defining and prioritising goals and using them to determine the importance of each task in the backlog. The job of the implementation team is to pick tasks in descreasing order of importance and implement them. The product is always working and always deliverable, but the longer you wait, the more you are likely to get. The concept of an "iteration" has become equivalent to the concept of a "task".

On the other hand, some projects need to synchronise with an external "clock". We recently had to ensure that a particular product was deployed on a live environment in time for some scheduled TV advertising. In another example, a customer operations department had a rigid once-per-month cycle of allowing updated software onto a live system. If we missed our time slot, even by a few hours, the delivery would have to wait for a whole extra month. In such cases, the concept of an "iteration" should really line up with the external timings.

In short, it depends a lot on the product and the customer.

In general, shorter iterations are better for development, but if external business processes impose a heavyweight ( meetings / documents / signoffs / training / ... ) penalty on each "release", then fewer larger releases may be more cost-effective.

[Ilja Preuss]

Originally posted by amita nagotra:
Is it possible to move a project (may be not legendary) following a waterfall principle to agile half way through its life time?

Sure you can. In fact I would say that you can start working on becoming more Agile tomorrow.

In agile is there a suggested span for an iteration or is it project specific ?

As far as I can tell, there is the common wisdom in the Agile community that everything longer than four weeks is hard to justify, with a strong preference to two to one weeks.

I worked in two projects with agile methodology , one had rigorous deliverables set for a every EOD, and the other had a release every fortnight.

Note that you only need to have a releasable system at the end of an iteration - you don't necessarily truly release. So the release cycle could easily be longer than the iteration cycle. (You still should release at least several times a year.)

[Ilja Preuss]

Originally posted by Frank Carver:
In the limiting case, Agile can work with iterations so small that they effectively disappear.

True. I've heard of a team that hosts its own web product, and is able to deploy a new version every evening.

I think there still is value in having a longer kind of heart beat to the project, though, for example for regular team for reflection (i.e. holding an iteration retrospective) and similar.

On the other hand, some projects need to synchronise with an external "clock". We recently had to ensure that a particular product was deployed on a live environment in time for some scheduled TV advertising. In another example, a customer operations department had a rigid once-per-month cycle of allowing updated software onto a live system. If we missed our time slot, even by a few hours, the delivery would have to wait for a whole extra month. In such cases, the concept of an "iteration" should really line up with the external timings.

In that case, I'd still want to have smaller iterations than a month. I would probably want to align them so that the system gets *delivered* every n-th iteration.

[Johanna Rothman]

I like to think about deliverables to the team and deliverables to the outside world. When I run an agile project, I don't have iterations longer than 4 weeks, because it's too easy to lose the project heartbeat.

But just because the team delivers running tested features to itself every 4 weeks, doesn't mean the customer wants to see it or take it. I have a client that does 2-week iterations resulting in running product every 2 weeks, but their customer only wants to see updates to the product once a quarter. So far that's working for them.

And yes, you can move to agile at any time, assuming you want to.

Johanna

[amita nagotra]

WOW i am enjoying this discussion.

Here i have another question...

how much importance is given to project documentation , and processes in agile?
For a 2 week iteration, it is not feasible to go by doing requirement traceability matrix, or updating risk and issue logs, or update the design, as agile deals with continuous change of requirements.
It may be possible for one time, but with time constraints is it feasible to go by having all these in place with frequent changes.
Even for the shortest of the story in agile, hell lotta documentation would be required? isn't it?


Suggest...

[Ilja Preuss]

Originally posted by amita nagotra:
how much importance is given to project documentation , and processes in agile?

Do you know the Agile Manifesto? http://agilemanifesto.org/

Documentation is good as far as it supports the team to steadily release working software. Processes are good as long as they support the people and their interactions. All of this, in my opinion, needs to be reflected upon continuously.

To some amount, an Agile team will simply have to find ways to do the things necessary that don't inhibit their ability to react to new learnings and produce value early and often. Other things simply will be identified as waste - things that don't add enough value that it's worth doing them - and gotten rid of.

For a 2 week iteration, it is not feasible to go by doing requirement traceability matrix,

A good Agile team will express all their requirements in the form of automated acceptance tests. So the tests don't need to be traced to the requirements - they *are* the authoritative requirements document.

And if you want to know what requirements some code is needed for, you can (temporarily) remove that code and watch which tests fail, for example.

What more traceability would you need?

updating risk and issue logs

I'm not sure what this refers to and why it would be a problem.

update the design

The design in the form of diagrams on paper or something actually don't provide direct value. They are typically an intermediary form to get the design in the heads of the developers, which is where you really need it.

An Agile team will do a couple of things to reduce the need for detailed design documents:

- they will keep the code clean and simple, so that a lot of the design can be understood by just looking at the code,

- they will keep automated tests that explain, in an unambiguous language, what the code is doing and tells them when they break something,

- they will probably do pair programming, which helps getting parts of the design from one head to another,

- they will all work closely together, enabling osmotic communication,

- they will keep currently important design sketches up to date on white boards