Five quality patterns in Agile development
In this blog series, I’ll discuss five quality patterns in Agile development to deliver the right software with great quality.
For years now companies have been adopting Agile ways of working and mostly the Scrum framework as their way to develop software. Scrum is all about working in dedicated teams on small increments of working software. Software that can potentially be released every single sprint. I’m sure you agree with me that this means that this software is therefore always tested every sprint as well. How could we otherwise release it right? This blog is about a trend I have noticed in a lot of companies that after time teams have more and more issues delivering quality software that conforms to business requirements.
Moving from waterfall to agile
Most self-respecting companies have adopted Agile ways of working. They have implemented scrum. Or I should say have started with sprints of mostly 2 weeks, do daily standups, perform reviews, planning sessions and retros. Oh, and they’ve hired a scrum master and an agile coach for good measure.
But working with Scrum really is fundamentally different. Working in small iterations makes that you have to think differently about your requirement, development, delivery and test process. Teams seem to overlook this at times. At first, all seems well. Teams follow the scrum patterns and are delivering something new every couple of weeks. Due to the refinement process, the business is often more involved and the feeling generally is that the speed of software development is improving. This is in part because the team generally takes less time for documentation and testing compared to working in the traditional waterfall environment.
Regression kicks in
And then things go wrong… After a year or so the code base has expanded so much, or the team has changed from their original setup, that keeping track of all the functionality in the application becomes an issue. Making small changes becomes more and more difficult. The impact of changes is often bigger than anticipated and changes have unforeseen side-effects. Issues pop-up during the development process, or worse, in Production.
By now the productivity has gone down. The team cannot deliver every sprint anymore, let alone each story. We slowly go into firefight mode where a bigger and bigger part of the sprint-backlog is being filled with bugs.
5 Patterns for the right software with great Quality in Agile
I see this pattern time and time again, and it seems so obviously clear that this needs to be avoided. I’ve learned that there are 5 patterns that are key to delivering Quality Software in an Agile environment. They ensure that you deliver the right business value and that these functionalities keep working despite the team making small changes to the application sprint after sprint.
Note: Besides applying these 5 patterns you still have to make sure your architecture is sound and that you develop high-quality code that is unit tested. This is making sure you “build it right”. For now, I’ll dive into “building the right thing”! We will touch upon what this means for development and test (automation) as well. These five patterns lay the foundation for designing, building and testing software as a team with the focus on creating business value and ensuring that the build functionality does not break over time.
In this blog, I will quickly touch upon each aspect and I’ll go deeper into each subject in subsequent blogs in this series.
1. Treat your acceptance criteria as your tests.
Invest in the quality of your user stories and acceptance criteria. Don’t rush through this process! Collaborate, use the power of the group and make sure you have a “common understanding” between the development team and all involved stakeholders. A way to be smart about your refinement and the basis for your development process can be to use Specification by Example in combination with Example Mapping. It can visually show you the size and complexity of your story. Too big? Slice it up! Too complex? Create a different model! The specific examples are your test cases! Development can use them to develop against and know exactly to what standards it should work. If you already like to know more, take a look at this previous blog: Refine using Specification by Example
2. Automate your acceptance tests.
After you’ve completed step one, make sure that you automate these scenarios and examples. All of them, without exception. They are your guard-rails for the future. On every change, these tests should run and you receive fast feedback on the status of your new and existing functionality.
3. Automate your build and release process.
A direct consequence of the point before. If you want to run the tests continuously, you need to automate this as well. On every merge, run the tests. If they fail, reject the release and update your code to make sure all tests keep passing all the time. Everybody follows the same rule, no exceptions, no workarounds. All tests are green, all the time. Zero tolerance.
4. Acceptance tests are your documentation.
Ever had the problem that after a couple of years on a project you get in the discussion on what the business rules are? Well, you have the acceptance criteria in clear examples and you’ve automated these as your automated acceptance tests. So why not use that as documentation as well? Your tests reside in your source control, but that is often difficult for the business to access. You can configure your release pipeline in a way that after running your tests successful these specs get published to a wiki of your choice. Now every new release means publishing of updated documentation that contains new specs. Now we don’t forget to update documentation anymore and it’s always available for the business in a format that they understand.
5. Monitor everything and act immediately.
Define KPIs and Metrics that are important for your team and your business. Continuously measure the performance of your application(s) delivery process (CICD) and your software running in production. As soon as a metric turns red, drop all your work and focus on getting it back green.
Where and how to start
These five patterns might seem obvious and easy, but it turns out that in practice it’s not. Teams start to implement a few of these patterns, but then don’t see the need to do them all, or don’t have the discipline to keep working on them and improving them. In the next five blogs, I’ll discuss one rule in depth at a time to explain how to do it properly so that you use these five quality patterns in Agile development to deliver the right software with great quality!