RSS

Tag Archives: waterfall

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. Read the rest of this entry »

Advertisements
 
Leave a comment

Posted by on May 17, 2012 in practice

 

Tags: , , ,

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. Read the rest of this entry »

 
2 Comments

Posted by on May 8, 2012 in practice

 

Tags: , ,

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. Read the rest of this entry »

 
1 Comment

Posted by on May 8, 2012 in practice

 

Tags: , , ,

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. Read the rest of this entry »

 
Leave a comment

Posted by on April 30, 2012 in practice

 

Tags: , ,

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. Read the rest of this entry »

 
Leave a comment

Posted by on April 23, 2012 in practice, Resource

 

Tags: , , ,

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. Read the rest of this entry »

 
Leave a comment

Posted by on December 31, 2011 in practice

 

Tags: