One of the things that makes your Agile framework of choice work is that it abandons the old waterfall approach to software development. There are still times when a traditional waterfall approach might be preferable to an Agile one, although I can’t think of such a thing off the top of my head. One of the problems that we face when implementing Scrum (or any Agile framework) is that people still often have a waterfall mindset, and try to apply that way of working within Scrum.

Waterfall “worked” because it created a sense of safety at the engineering and quality levels. We had the BRD to fall back on, and we knew every aspect of every feature before a single line of code was written. In theory, anyway. There was a huge amount of chaos at the Product level, because we asked the people writing the BRD to predict where the market for our software was going to be months in advance (sometimes years in advance). The problem with those guesses is that we are going to be wrong, and end up delivering product nobody asked for or needed. Scrum reduces the likelihood of this happening by working in short iterations and reviewing the new product with our stakeholders and customers on a regular basis, making adjustments based on rapid feedback cycles.

That’s a good thing.

One of the problems we face, particularly early in an Agile transformation, is that people see Sprints as mini-waterfalls in which every activity must necessarily be preceded by another. We can’t write any code until we have all of the information we need in our User Stories, and testing can’t happen until everything has been written and deployed. By doing this, we end up creating dead space at the beginning and end of our Sprints where members of the Development Team feel partially handcuffed and don’t know what to do next. A good user story has just enough information for the Development Team to begin work, and the design will emerge as discussion around the work takes place. The dialogue between the Development Team and Product Owner drives development forward on a daily basis. QE specialists can get a jump on writing test cases because they know from the Daily Scrum Meeting which User Stories are in development and will therefore be coming to them first, making it easy to prioritize their work.

All of this requires excellent technical practices, including Continuous Integration and Continuous Deployment in order to succeed. If no builds are making it from development and into testing until late in a Sprint, we have forced ourselves into a waterfall pattern, no matter whow Agile we say we are being. You still need to go through all of the various stages involved in creating good software, but these stages should largely overlap each other, allowing us to turn out highly valuable product in short periods of time.

If you find you’re getting to the end of a Sprint with a lot of undone work, take a look at the process and see if you are actually waterfalling your Sprints. Moving away from this behavior will make you that much more Agile!