Quality is a Process — Baking in Quality in Software Development
Having owned my own bakery where we made everything from scratch, I learned a few things about delivering quality consistently and why that is so important in building long-term repeat customers. Food is a very funny thing and people have opinions about what they like and don’t like and when they find things, they like they want them to be consistent every time. How many times have you gone to a restaurant and liked something and when you went back it was different and not as good to you? Consistently delivering quality in an environment where the variables can change, from different chefs to different quality ingredients and most importantly different approaches regarding how to produce the recipe they are following.
When I left my bakery and went back into technology, I kept the quality mindset that I developed for baking. To produce consistent quality baked goods meant that the approach to making the dough had to be the same, but it did require that we modify certain things due to known variables. For example, we learned that oatmeal packed in summer had more water content than bags that were packed in winter and we had to adjust our recipes to accommodate those facts to ensure our cookies came out the same every time.
Building quality software takes the same approach in that there is a recipe (process) for quality and there are ingredients (such as tools, automation, etc..) that we can leverage to support the consistent delivery of quality software. We call this as Baking in Quality.
What I learned over the years is that we need to have a consistent process that allows ideas to flow from Discovery to Delivery and within this process are all manner of approaches and tools that can leverage to deliver a quality product for our customers.
These approaches include:
1. Discovery — When taking on a new initiative, you want to bring together everyone who will be providing input into the project, this includes UX, Architecture, Developers/Testers, BAs, Project Managers, and most importantly our Leaders. If we get leaders engaged at the very beginning, they will understand very quickly that their ‘idea’ is complicated and not as straightforward as they have in their minds. During discovery you might:
a. Have group sessions with everyone, where we will create Low-Fi wireframes from which we can begin to see the vision of the product and then have conversations with Architecture and development as to what is a practical approach and where might are limitations and alternatives be from a design perspective.
b. Leverage Story mapping to understand the customer journey.
c. Bring in leadership at the end of every day to review what we came up with and obtain their feedback as input into our next daily session.
d. At the end of Discovery, we should have a clear idea of the scope and direction of the effort and will have built a high-level backlog from which to start working with.
2. Development — During the development phase a key process you can leverage is to master story writing combined with BDD. Additionally incorporating XP technical approaches will ensure that we have quality code that supports the quality functional product we deliver.
a. Every story that is brought into a sprint should follow the 3 C’s format and for the Confirmation, you will incorporate Behavior Driven Development acceptance criteria. One thing to know is that BDD is not a simple Given/When/Then statement, that is a single test for a single outcome.
To gain the benefit of BDD you must develop an outcome-based example table (which almost no one ever does) so that you provide a specification for that story. This means that you will be writing stories at a higher level and then using BDD to elaborate. Doing BDD this way is a key ingredient in delivering high-quality software and though it seems like a lot of overhead, it’s not that hard to master, and once you do it will cause you to look at requirements in a brand-new light. Developing BDD example tables will ensure that when work is in the sprint that nothing extra gets added, if the outcome is not in the example table, then you shouldn’t be developing or testing other outcomes. If you find a new outcome, add it as another story to be dealt with in the next sprint.
b. Test automation is another key ingredient in developing quality software and it’s an investment that absolutely must be made if you are going to be Agile you cannot go fast without it, teams will flail and fail, and defects released to production will be common. For many organizations with legacy systems, you either have little automation or your systems don’t lend themselves to fast sprint-level automation. In these situations, you want to focus on the BDD outcomes of your stories and identify core tests that need to be rerun every sprint, think of how you would test a critical defect that has to get to production quickly and build your manual testing around that.
But if you don’t have legacy systems then one of your key metrics has to be the development of test automation that provides easy regression testing. You aren’t going to get it all done in a couple of months but be sure to establish quarterly goals and provide capacity for the teams to both learn how to do automation in their sprints, but also to have time to fix the tests that will inevitably break as we continue to develop sprint to sprint. To capture the idea of automating tests in the sprint that they developed think of this as progressive regression, ultimately you will test everything more completely and build more confidence in your product quality over time.
When thinking about your test automation strategy, leverage tools such as Sonar so that you gain insight into the areas of the complexity of the codebase, focus your automation efforts on the most complex areas once the team has mastered automation skills, this will provide the biggest return on your investment.
3. Delivery — The most important aspect of what we do is to deliver to our customers a product that they said they needed and to do so with quality. To deliver quality in an Agile delivery model, you need to combine the test automation you are building with effective Continuous Integration and Deployment. These things can and will have different interpretations based on how you deliver features to your customers. If you have a bigger bang approach, then your teams will be developing in the Dev/Test environment for longer periods of time before they deliver to the Staging and finally production environments. Regardless of when you deploy (which can always be thought of as on-demand) CI/CD will both speed code deployment and make the deployments safe and consistent.
To develop high-quality software, we need to develop a highly contextual understanding of what we are doing, whom we are doing it for, and how we will develop and deliver on that promise.
Just like making cookies, there is a recipe and a process that you can follow to deliver great products every time.
If your organization would like to learn how to build its recipe for success, please contact me at michael@soundagile.com
