I think it was Jamie Arnold who first introduced me to this phrase.
In engineering teams it’s – sadly – still all too common that Quality Assurance (QA) is the last step in the delivery process. Developers code, then throw it over the wall to QAs to test. Teams working this way typically have a high rate of failure and large release bottlenecks – features and releases pile up, waiting on the QAs. Developers pick up more new work whilst they’re waiting. Bugs come back and developers are now juggling bug fixes and new work.
It’s slow, inefficient and costly!
What I dislike the most is the cultural aspect – the implication that quality is the responsibility of QAs, not the developers who wrote the code.
Quality is a team sport. The most valuable role for QAs* is to ensure quality is baked into the entire end-to-end delivery process. This has become known as “shift-left” – QAs moving away from spending all their time at the end of the delivery lifecycle and focusing more on how we can “build quality in” throughout.
What does this look like in practice?
– QAs involved in requirements gathering and definition, making sure requirements are clear, well understood and we’ve considered how we’re going to test it (inc. automated tests).
– QAs ensure we’re following our agreed Software Delivery Lifecycle (SDLC) and the steps and control we have in place to ensure quality is front of mind.
– QAs collaborate with developers to write automated tests, developers collaborate with QAs on mutation testing, compatability testing, performance testing.
– If there’s any manual testing required, /everyone gets involved/. QAs make sure everyone in the team is capable of doing it.
It’s a much richer role for QAs, and far better for everyone!
*Some teams don’t have QAs. That’s fine, I’m agnostic, as long as everyone cares about quality 🙂
With all the stories I still continue to hear of failed agile implementations (often now called “digital transformations”), it feels like it’s time for an XP revival.
Extreme Programming (or XP) is one of the original agile software development methodologies, and it’s a shame I see it talked about less these days. It was pivotal in shaping agile practices, and crucially, focuses on engineering practices as well as ways of working, which none of the most popular agile methodologies do.
Why didn’t XP take off like Scrum, Kanban or any of the scaled agile frameworks? Two main reasons (my opinion):
Unlike the most popular methodologies it was never commercialised or marketed. There are no (highly profitable) training and certification programmes for XP. It’s the garage punk band of Agile!
It’s harder. Because of XP’s focus on engineering practices, unlike e.g. Scrum or SAFe, you can’t as easily get away with superficially plonking XP on top of your existing processes and not really change anything.
The second point is why, as often as not, there’s often little meaningful impact with Scrum, or especially the scaled agile frameworks (well, apart from adding a lot of bureaucracy to your processes).
I’m continually hearing of failed scaled agile implementations (often involving lots of very expensive consultants). These stories don’t often go public because, well, you’re hardly going to shout about it, but WalMart is one of them, as I found out from Dave Farleyrecently. How did they fix it? By focusing on the engineering practices over the process! You can watch Bryan Finster‘s excellent InfoQ presentation on it here.
For me personally, Scrum is OK (I’m not a hater). I prefer Kanban, or even ScrumBan – mixing the two. But XP as well. Following XP does not mean you can’t use or be inspired by other methodologies, but without the XP practises you’ll unlikely get any meaningful improvement.
However I’d argue you don’t need much more than XP in the first place, and it’s as good a place to start as any.
It’s time for an XP revival
I’ve watched as first, Scrum proliferated the industry, and then the scaled agile frameworks come along. They’ve had plenty of time in the sun and there’s enough evidence now indicating that these methods are regularly not delivering on the intended outcome, certainly not on their own, without focusing on the engineering practices as well.
It’s time for the latest generation of development teams to learn about XP. It may be over 25 years old now, but that’s also as long as I’ve been working in tech, and whilst the languages, tooling and platforms have changed markedly in that time, the fundamentals have not.
Appendix: What is XP?
For those not familiar, I’ll try to summarise XP’s Values, Principles and Practices, but I’d recommend getting a copy of Kent Beck’s masterpiece Extreme Programming Explained if you’re keen to learn learn more.
XP Values
Communication: Clear and frequent interactions within the customer, stakeholders and team
Simplicity: Focusing on what is necessary at the moment and avoiding over complication.
Feedback: Actively seeking feedback to continuously adjust and improve the product and processes.
Courage: Being bold about making changes, trying new things, and facing challenges directly.
Respect: Valuing team members’ contributions and creating a supportive environment for all.
XP Principles
Humanity: Acknowledging the human aspect in software development, emphasising respect, understanding, and communication among team members.
Economics: The need to consider the economic impact of decisions made during the development process, optimising people, resources and return on investment.
Mutual Benefit: Encouraging practices and decisions that are beneficial for all stakeholders involved, fostering a win-win environment.
Self-Similarity: The principles and practices of XP should be applied at all scales of the project, from the smallest code block to the entire development process.
Improvement: Advocate for continuous improvement of the process, code, and team dynamics, always seeking ways to do better.
Diversity: the value of having a diverse team with varied perspectives and skills to tackle complex problems creatively.
Reflection: The importance of regular reflection on practices, progress, and problems to learn and adapt.
Flow: Aim for a steady and continuous flow of work, minimising disruptions and maximising efficiency.
Opportunity: Encourage viewing challenges and changes as opportunities for growth and improvement rather than obstacles.
Redundancy: The value of having some redundancy in skills and knowledge within the team to enhance resilience and flexibility.
Failure: Acknowledging failure as a natural part of the learning process, encouraging a positive attitude towards learning from mistakes.
Quality: Placing a strong emphasis on the non-negotiable importance of quality in all aspects of software development.
Baby Steps: Advocate for making small, incremental changes to manage risk and facilitate easier integration and testing.
Accepted Responsibility: Responsibilities should be accepted voluntarily by team members, fostering ownership and commitment.
Core XP Practices
Sit Together: Promote team collaboration and communication by working in the same space.
Whole Team: Everyone who’s needed for the success of the project is a part of the team.
Informative Workspace: Create a work environment that visually communicates the team’s progress and status.
Energised Work: Encourage working only as many hours as you can be productive and no more.
Pair Programming: Two programmers work together at one computer, enhancing code quality and knowledge sharing (add mob or ensemble programming these days).
Stories: Use of customer-defined user stories to guide development and ensure the product meets needs.
Weekly Cycle: Planning, development, and delivery cycles on a weekly basis to adapt to changes quickly.
Quarterly Cycle: Long-term planning sessions that set the direction for the next three months.
Slack: Incorporating extra time into schedules to account for the unexpected and foster creativity.
Ten-Minute Build: Keeping the build process short to encourage frequent integration and testing.
Continuous Integration: Regularly merging all developers’ working copies to the shared mainline several times a day (add Continuous Delivery these days).
Test-First Programming: Writing tests before code to clarify the requirements and ensure correct behaviour.
Incremental Design: Evolving the design over time as the system grows and changes, instead of doing all design upfront.
