Improving Delivery Quality with Agile

When people hear about Agile projects continuously delivering working functionally at the conclusion of each increment, it’s often easy for them to assume that quality must have been compromised to ensure that something can be finished.

The reality is, however, that the quality of what we’re delivering with an Agile approach far exceeds expectations; mainly because adding value is at the heart of everything that we do.

The Iron Triangle Of Unrealistic Expectations

A traditional project management approach would look to fix as many of the iron triangle points as possible:

Quality is assumed and will often not be a constant; normally in the real-world, we see it reducing radically as the time constraints on a project, with a fixed scope to be delivered by a fixed day in a big-bang delivery, take priority. We’ve all sat in project meetings where the Project Manager has asked something along the lines of a “quick and dirty” solution in the interests of saving time.

It’s another example of something that is just accepted as part of the tyranny of waterfall delivery; working quicker results in a lesser quality. Simple economics. If we’re treating testing as a phase, rather than an integral part of the development practice, then it is always their time that gets cut in half, or even worse; simply because it’s the last phase to happen.

Expecting your development team to deliver a sizable fixed scope within a lengthy fixed time period will always result in frantic overwork towards the end of that timebox, forgetting best practice and simply doing enough to say you’re done.

Fix Quality, Not Scope

Within Agile, we’re a little more realistic. We want to fix the quality, and we want to fix the time so that we can ensure frequent delivery, but what we ask for in return is a little flexibility around the scope:

Allowing for a flexible scope will ultimately result in an assurance that quality is never compromised because whilst allowing for emerging requirements, we do not have to waste time building the wrong thing just because it was something we agreed to 6 months ago.

It all starts with a misunderstanding around the Minimal Viable Product (MVP). It is often assumed that an MVP is a rushed, unfinished delivery with little emphasis on quality. Every decision that we make within an Agile project should be driven by the value that it ultimately adds to the product we are working on.

Just because we are working with vertically sliced features, developed over shorter increments, it does not mean that they are unfinished or untested. The reality is that because we are giving our test team the chance to test a feature end-to-end and throughout the development process, the quality will actually be considerably better as feedback, and ideas can be collaborated throughout the team.

Focusing On Quality Allows Emerging Best Test Practices

In the past, testing teams have been measured according to how many bugs they find, thus straining the relationship with the development team. Within a highly collaborative Agile team, we are looking to offer a better way for both developers and testers to work together to reduce the number of bugs within the code and also help to produce software of a higher quality more consistently.

To help us achieve this consistently high level of quality within Agile, we turn to techniques such as Test Driven Development (TDD); a practice that can only work well within a very short development cycle. TDD is a highly valuable method of testing but is at its most effective when used as a complement to manual testing. This twin approach affords the tester a more complete method of testing when working in Agile iterations.

In a nutshell, Test Driven Development tells us to write the test first and then develop the new functionality. It feels backwards at first, but working this way allows us to define success up front (which is critical for knowing when we are done), and ultimately it means that the team can produce unit tests to prove that the developed code is indeed done, as it is being developed. Again, we want to avoid waiting until the end of development to begin testing, thus allowing the focus on quality to reign supreme.

Unit tests are powerful because when combined with a continuous integration Agile delivery process, they enable us to make changes to our code without fear of what is going to break elsewhere. It also gives the testers confidence that once a feature is completed, it can be actually marked as done, rather than “done, but”…

Quality Comes Naturally Within Agile

In the simplest terms, using an Agile approach yields many benefits for your testing team. They are far more integrated to estimation and planning for starters, and the ability to regularly test and work with developers directly, as and when features are completed, is a major advantage. Furthermore, because the testing isn’t left until the last possible moment with this approach, you’re giving your test team time to work more efficiently, which is a situation they have never had.

Adopting an Agile approach is always the right decision to deliver software. There are many different benefits – which we’ll explore over a number of different blog posts – but improving quality is the one that’s often most overlooked. The reason for this, perhaps, is that it happens so naturally because of the working practices adopted, that you don’t even give it second thought.

So don’t feel short-changed by an MVP; embrace it and rest easy knowing that it will probably be the best quality software you’ve ever had the pleasure of testing or using.