How do agile teams ensure quality of their deliverables?  The principles of the Agile Manifesto guide us to “deliver working software frequently” and that “working software is the primary measure of progress”.  But, how can teams new to agile achieve this?  And more importantly, how can they do it in a way that does not incur a lot of technical debt?  If your team is striving for agility, but you have a lot of waterfall in your past this article is for you.  It is a lot harder for you to move your agility forward without risking the quality of your software.

Waterfall Testing

Before we talk about moving forward, let’s talk some about the past.  In waterfall, the development team works for a long cycle on building software and then there is a formal handoff to a QA organization to perform the certification of the release.  Almost always, this certification effort took much longer than originally planned.  This is because of the amount of software changes pushed into the process.  In the waterfall process, there is only one big feedback process at the end of the process.  This is the problem that agile attempts to resolve by including frequent delivery of software and shorter feedback cycles.  This is almost always a drain on development and QA resources.  It is also a very big stress on the business because planned deliverables are late and/or poor quality.  In the diagram below you can see the effect of this delay.  I call this behavior the “Waterfall Testing Tail”.


Agile and The Waterfall Testing Tail

Now that we are converting our processes to agile, we want to eliminate the tail.  But, it is not so easy.  Since we have been building our systems for years and relying on the tail to ensure our quality, we may have created some deep dependencies on it.  Typically, when teams begin converting to agile, they tend to execute more of a scrummerfall model.  The scrummerfall is when teams perform waterfall testing within a single sprint.  They do this because they are not yet mature enough in their automation testing.  But, there is a significant danger in this approach.  The problem is that even though the team is delivering at a much more frequent pace, the testing tail is still causing them difficulties.  Let’s look at the cycle as it fits within a sprint.


There can be a quality gap.  This occurs because teams want to deliver within a sprint.  They are excited about agile and want to deliver value at a frequent rate.  (Just as defined by the manifesto).  The problem is that their system is never set up to support this.  They continue to under-estimate the testing tail just as they did before when using waterfall.  Therefore, each sprint, they create a quality gap. Because of the quality gap, their scrummerfall process could be rapidly producing technical debt that could eventually sink the entire product.  It might be only small cuts at a time.  But over time it can produce death of any product.

Converting Safely to Agile

Typically, I recommend whenever possible to adopt Extreme Programming (XP) techniques before converting development teams to agile.  Because without the mature quality practices exposed by XP, there is a risk of quality gaps that create long term technical debt.  Practices such as test driven development, pair programming, continuous integration, and continuous delivery are critical to avoiding quality gaps in your agile software releases.  But, this is rarely what companies do.  Why?  The jump to XP can be a very sizable investment for any company with a history of waterfall.  They’d need to do substantial refactoring, retraining, and retooling.  I call this the 3R conversion.  No business people in their right mind can suggest shutting down production for the many months it would take to perform the full 3R conversion necessary to adopt XP.  Instead, they jump right into agile.  Project managers and business people can get their mind around agile concepts.  But, the importance of XP is mainly understood only by the developer.  So, the journey typically begins on the wrong foot.  So, where do we go from there?

Rule #1:  Don’t be in denial!!

In my opinion, the #1 impediment to becoming more agile is denial.  Companies love to forget the years and possibly decades they spent digging into the situation they are in.  They think throwing a few sticky notes at the problem will solve it.  Since we have started out on the wrong foot, we need to learn how to adapt and improve at the same time.  Here are some key adaptation strategies:

  1. Embrace the fact that the best you can do for now is some sort of water fall test cycle.

Without mature test automation, your software base still needs rigorous quality assurance before it is released.  Don’t release until you fell confidence in the quality of the end product.  This will prevent you from releasing as often as you would like.  But don’t be seduced by the promise of agility.  Be sure you are ready before aggressively releasing at an agile cadence.

  1. Make sure that the quality gap is not ignoredWorkInProgress

Agile teams should own the total quality of their releases.  But, given your current situation, that may not be possible.  Don’t be afraid to throw traditional QA resources at the problem.  Having a system/release team can help fill the gap.  This means you cannot be truly agile.  But, you will have sufficient stop gaps in place while you work to improve over time.

Here are some key improvements to begin today:

  1. Implement continuous integration

Even if you have 0% code coverage you can start building your code on every check-in.  Begin to condition your teams to owning the build stream and reacting to broken builds.

  1. Train your teams on proper unit testing

Teams that have been doing waterfall for a long time may not even fully understand what TDD is and how to write proper unit tests.  The could be using unit test frameworks and writing automated tests.  But, they are not building proper unit tests.  They probably include many dependencies that can cause them to run slowly, break easily, and make them unable to run in a CI environment.

  1. Create a strategy for long term refactoring

In most cases, it will never be possible to refactor your entire system.  But, you can identify target areas that have a high amount of code churn and a low amount of code coverage.  These are the areas that you should start with first.  Refactor with both testability and maintainability in mind.

Moving Forward

Each step of the way moves you closer to agility.  Don’t try and shortcut the process by avoiding reality.  Satisfying your customers by delivering valuable software is your goal and don’t let the allure of agile perfection cause you to lose focus.  You can get there, but it may take a lot of change and a lot of hard work.  Keep your eye on the end goal and KEEP MOVING FORWARD!!!!

moving forward

Agile Quality Practices

One thought on “Agile Quality Practices

  • March 6, 2016 at 11:03 am

    I read blogs and books that tell us what the end state of being agile is, and many of them do not address the practicalities of getting there. Transformations will have a hard time if they don’y understand where they are and dealing with the practical gaps that are found due to the organization starting state. Management some times believe there is magic in the disciplines that support agile and lean principles. Therefore if we put people together and call them a team, they will be self organizing and self managing. They will be able to deliver valuable tested software every sprint or in a continuous flow. The “magic” of agile is definitely alluring however, you cannot ignore the harsh realities it takes to move from the waterfall world to an agile world. This belief in agile magic masks the need to address the real problems that need to be addressed in order to achieve true agility. In the end dealing with these realities in a practical way will have payback and management will wonder why they have not paid the price to move to agile before now.

    Thanks for grounding us in the reality of pulling off true agility. I am looking forward to more blogs on the practical nature of moving to agility!

Comments are closed.