Classic Date Drift Case Study

A waterfall project is required to predict dates that certain things will happen in the future.  There are usually many pieces of the project, each with their own date, and each dependent upon others.  No one can change a date without effecting others, and so a game of “chicken” ensues where people report dates they plan to complete and never hint there is a problem.  At the last possible minute they declare a change in date, and when you look at the history, you can easily conclude that they should have known ahead of time that the deadline was to be missed.  But everyone waits for someone else to change first.

Partial Agile: No Such Thing

On several occasions in the past, I have heard software engineering management suggest that they would like to “try” an Agile approach by implementing it in part of a project.  For example one feature, a couple of team members, would work in an Agile approach, while the rest of the team works with a waterfall model.  Another manager told me they were using Agile, but instead of time-based Agile, they were doing feature-by-feature Agile which involved the normal 3 to 6 month time cycle.

Growing Software like a Plant

Maybe it is helpful to view the development of a software in using an Agile approach as being like way that a small tree grows.  In contrast, development of software using waterfall is like that of a factory.  The difference between a tree and a factory tells us a lot about the difference of these two styles of software management.

Complex Projects need Agile MORE than Smaller Projects

I met another Japanese executive last week who said “An Agile approach may be fine for other projects, but our software is big and complex, and because of that we have to use Waterfall approach.”  This is the exact opposite from the truth:  the larger and more complex the code, the greater the need for an agile, iterative approach.

Don’t Fear Rewriting New Code

The last post #28 Avoid “Test Script” Fever was about simplifying an implementation that was more elaborate than it needed to be.  There was a waterfall-style project in exactly this situation, and leader responded saying “It has already been coded the other way, and if your goal is to save programmer time, rewriting will just waste more time.”   No, it won’t, and this post explains why.

Waterfall method fails to account for unseen benefits

My epiphany for today comes from working with a team dedicated to developing software using a waterfall methodology, and how there is a decision patterns that leads teams to produce worse code.