What do we mean by Quality? The word Quality is commonly used in software development, but it isn’t always clear what is meant by it. Teams create Definitions of Done, configure thresholds in their CI/CD pipeline, write performance tests and agree service level agreements, but are these sufficient for the level of Quality the customer expects?
There are formal Quality assessments and standards, but these are often regarded as unnecessary for Agile teams – a source of excess documentation and process that is at odds with the Agile Manifesto. Yet, the Manifesto also talks about ‘Working Software’, ‘Valuable software’, and ‘Continuous attention to technical excellence’. Software cannot be regarded as ‘working’ or ‘valuable’ if it isn’t good enough to be trusted with live data or production environments. Therefore, even with small Agile teams, it is important to know the Quality required by the customer and important to know that it is being met.
The challenge is to do this without imposing bureaucratic quality management processes or delaying the delivery of value to the customer.
Do we trust the development team?
The first question to ask is why we have quality management processes, particularly those that are independent of the development team. Or to put it another way, why don’t we trust our development teams to build and verify the necessary quality into the product by themselves? Developers are not generally cheap, fungible, easily replaced resources. They are sentient, skilled, professional people who come to work wanting to do a good job. No developer wants to create rubbish code that users can’t use. They want to create valuable software that solves a need and which they can be proud of.
So, instead of taking their work, assuming it is poor quality and subjecting it to external scrutiny to prove that it is before throwing it back to them to improve, let’s make it easy for them to build that quality in from the start.
Essence helps teams to this in two simple ways:
- It focuses on measuring progress by progressing through states, not by measuring tasks completed; and
- Its checklists provide a clear and simple way to ensure standards are maintained and important criteria are addressed.
Most teams are used to measuring progress through tracking completed tasks or work items. Higher level stories, epics, features or other items are split down into smaller units until we are left with atomic things we can assign and complete. As these small units are completed they can be tracked in burndown charts, work management tools or Agile boards and we get confident that the business outcome we want is getting closer to completion.
The last 20% of the work takes 80% of the time
However, there are two problems with this – as any developer will tell you, progress is not linear. The adage that the last 20% of the work takes 80% of the time is popular because it is true. Simply measuring tasks complete compares to tasks incomplete it not an accurate indication of progress. Furthermore, the breaking down of a big goal into smaller goals is also an inaccurate endeavor.
Often we create tasks that don’t turn out to be necessary and omit tasks that are. This causes a problem when we declare success once all the initial tasks are complete without independently testing the original, larger goal. If we do test the original goal, even once all its subsidiary tasks are complete, we frequently identify additional work to meet the goal, compounding the first problem.
Don’t measure the activities; measure the outcomes
Essence provides an alternative view on progress. Rather than measure the activities; measure the outcomes. As a user need progresses from being identified to the user accruing the benefit, we will be able to observe that progress by inspecting the Essence states. By knowing which states we want to achieve along with the states we are in, we can gain a more objective view of our progress.
By including a simple state inspection in each iteration, teams can use the knowledge that brings to adapt their next iteration or goal. They may also spot leading indicators of future problems, such as changes in team collaboration, stakeholders or dependencies.
Checklists save lives
The second way Essence helps teams is through the use of checklists. Checklists are used in many situations, including for seemingly routine tasks carried out by highly skilled professionals such as medical surgeons and pilots. In these highly skilled environments, requiring them to complete checklists detailing the procedures they must follow has been found to drastically reduce mistakes and deaths. In other words, using checklists has massively improved quality. If this is true for surgeons and pilots, it should also be true for other skilled professionals such as software engineers and developers.
In Essence, each alpha state and work product level of detail has a checklist that is used to test whether that state has been achieved. These checklists can be customized by a team or organization. This customization can be at organization, team, product or even instance level. This means that a team can create checklist items for a specific requirement or feature. Since checklists exist for state changes that matter, this is an excellent way to build quality into the product.
For example, for a public facing web system, we could add checklists to the ‘Ready’ state of Software System that specify particular performance tests to conduct or set limits on web hosting costs.
The check box is a contract
You may think that having expected criteria already written down – for instance in a Definition of Done or as Associated Non-Functional Requirements – means that you don’t need to include them as checklists. However, don’t underestimate the emotional power of ‘ticking’ off a physical (or electronic) check box. Surgeons know to wash their hands and check the patient’s name before starting surgery, yet a surprising number of times they did not do so. When they have to check a box that reminds them, compliance is near 100%.
The same is true for software developers. They know the Definition of Done is there and they know what it says. But it’s easy to forget or assume someone else has done it. Ticking the box behaves like a contract signature. It’s a promise that you have been compliant. It’s a good kind of contract, even for Agile teams!
Work Together
Quality criteria, whether in Definitions of Done, Non-Functional Requirements documents or story acceptance criteria should be created with the development team, not imposed upon them. This doesn’t mean they need to do them on their own, but they need to be involved. Doing so will ensure they understand them better, and they will feel more accountable for meeting them.
This is true for checklists, but it is also true where bespoke practices are created as part of the organizational governance. Involving people from delivery teams and not just quality or process engineers will increase developer buy-in to the practices, increase the chances that the teams will engage with them positively and is also likely to make the practices better because of the developers’ input.
Improving Quality Retrospectively
When teams are regularly inspecting their states, they will also be able to respond to changes in state criteria. Just as with other artefacts, Essence elements should also be regularly inspected and adapted. One of the things that can change are Quality related criteria.
As an endeavor progresses, and the teams learn more, expectations on Quality and other aspects of the system may change. States, levels of detail and checklists may need to evolve. Since teams are measuring state progress holistically – checking previous states, not just the current and future states – then changes to any state or checklist will be spotted and the team will know to apply it.
This allows quality related changes to be applied retrospectively and for continuous, iterative improvement to flow through a large endeavor.
Conclusion
Quality Assurance doesn’t need to be an external, independent process applied after a development team thinks they are finished. It can and should be an integral part of developing a solution. Essence makes this easy to do by measuring outcomes rather than activities and using a checklist concept that encourages current behavior by development teams. Co-creating quality criteria with Quality experts and delivery teams further improves the criteria and makes it more likely to be followed.