Still thinking waterfall trying to get to Agile

Applying Principles from The Agile Samurai: How Agile Masters Deliver Great Software by Jonathan Rasmusson

This article has less to do with The Agile Samurai book and more to do with passing on some wisdom of my own to others.

The teams I am working with are very much trying to get to an Agile approach.  There are some very clear indications we are still have a waterfall mindset.  The clearest indication of this is that the last week of a sprint is when almost all of the QA testing is done.  So we are just doing mini-waterfalls, waterfalls in a three week sprint, instead of Agile development.

Waterfall development characteristics

  • Distinct phases of development:  requirements, design, code, unit test, QA testing, validation, regression, etc.  The work is very serial.
  • Finishing a whole phase is considered a good sign of progress.  So if there are 30 components and all of them are designed but none of them work yet, this would be consider a good result.
  • Rework is ‘bad’
  • Output from each phase is a distinct and formal document
  • Documents tend to be large
  • Team members have distinct roles (BA, developer, testers, project managers, etc)
  • Reporting on partially done is normal.  “I am 50% done with this task” is normal.  Reporting % done is considered a good way to report doneness.

Sprint/Story development characteristics

  • Development still has requirements, design, code, unit test, QA testing, validation and regression BUT the work is done more in parallel
  • One working/QA tested story is more important than having 5 stories partially done.
  • Rework, i.e. refactoring, is considered normal
  • Output from each phase is intended to bring about working/tested code.  The only valuable ‘document’ is working code
  • Minimal documentation.  We still have too much documentation.  The QA Test document and the story information in the Wiki can be combined and I think the verbiage can be streamlined to provide more useful information.
  • Distinct roles are less important and what is more important is who can get something done.
  • Reporting is “I finished this task yesterday and I will be finishing X task today.  I have an impediment towards getting it done which is …”  Getting small pieces done each and every day is important towards showing progress.

The root cause for this problem still seems to be the size of the stories.  They need to be even smaller than they have been.  Implement a single field or small set of fields through a vertical slice of the application.  This would help get the whole team involved in the story or small set of stories.

It also means getting my product owner, who has spent years doing product development, out of the mindset that the old way (waterfall) 'worked'.  Getting the data that proves that it worked will be my next step to demonstrating that "waterfall does not work".

You have no rights to post comments