We Don’t Do Waterfall

Is the cry of many software teams I interact with.  In fact, they are always very quick to point out to me that they follow agile principles and practices such as TDD, iterations, automation etc etc very closely but after a couple of minutes of discussion, we usually find out that they may not be as agile as they think in their core approach.

Most teams that say they don’t “do waterfall” mean that they don’t do all their analysis, then do all coding, then testing for a set of requirements etc etc in a sequence, rather they decompose sets of requirements down into smaller features, MMFs, user stories (whatever) and work on those.  These teams should be applauded for adopting an approach that allows them to deliver value faster than they probably did before.

However, my observation of such teams (including teams that I have managed both past and present) is that they are still very sequential in the development of smaller work items.  They are waterfall-esque, just at a user story or feature level. What can be more surprising is the (at times) averse reaction to concurrent development e.g. having design and coding or coding and testing on the same feature happening at the same time.  Somehow, this is considered to be a bad practice and I’m not sure why.  For example, even though the designer and developer both know that something will have to be implemented, designers don’t want developers to write any functional code till they (the designer) have documented it even though its inevitable that the developer will have to code some form of that functionality.  Waiting for days with zero code is deemed a better tradeoff than having to modify code that was written in the case that requirements change.  Software development teams in the interest of preserving sequencing, minimizing change and refactoring sacrifice delivery times significantly with little to no observable improvement in quality and don’t think much of it.  Think of how much time in the delivery cycle could be recouped if activities were happening concurrently.  In fact, don’t just think, try it out!  It’s not that hard to put certain controls in place to ensure that the necessary documentation is in place before the software is released.

In my experience, I’ve heard designers (for example) say that they are being asked questions by developers that they haven’t thought about yet, i.e. they haven’t been able to go “deep” on a feature and are hence not ready to answer their questions.  Now tell me, why is this a bad thing?  The fact that the developer brings this up is the type of early feedback that we want in the development process.  It shows that everyone cares.  This is a culture that needs to be cultivated.

Part of the solution to fostering concurrent development is to identify what activities are truly essential for the delivery of high quality software.  We also need to understand that a working solution is what is of value to our end users and practices that get us to a working solution sooner should be encouraged and promoted.  Our assumptions as to what is required is very ever reality.  It may even mean redefining what designers, developers, testers actually do and how they do what they do.  Only software development organizations that are willing to improve their practices will improve their delivery.  The status quo should not be acceptable.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s