Quality-Driven Development (QDD) is an emergent property of Agile/Xtreme practices synthesized with high-energy proactive QA thought leadership and just-in-time testing.
Modern proactive QA procedures to encourage defect prevention in Agile software development include singular techniques such as test-driven development (TDD) and formal templates to structure requirements, user stories, and acceptance criteria. Software solutions such as Thoughtworks’ Mingle, Rally, and Pivotal Tracker offer a variety of tools for the trade but are vague and indirect when it comes to advising on the most effective procedures to use them. Time and again, key stakeholders and internal staff alike seem to be left out in the cold on how the project is going; how do project managers, product managers, portfolio managers, support staff, and CIOs integrate into the software development process?
Sound like your team? It’s okay if it does. The real question here is, why hasn’t anyone stepped up to offer a firm instruction manual of what Quality-Driven Development truly is? And the natural follow-on: okay big fella, lay this out for me like I’m a 4-year old. You have 5 minutes of my attention.
Consider this: If Agile Scrum had all the answers, there wouldn’t be so many companies hiring consultants to help them figure it out. Period. BOOM. A solid software development lifecycle (SDLC) is able to stand on its own two feet and provide clear roles and responsibilities to the team playing so that the game can be designed, implemented, and won.
Agile Scrum, Agile methods, and Xtreme all put the software developer first. They don’t come out and say it, but that’s what they are doing. That entire paradigm of thinking fails to create an opportunity for proactive problem solving — Agile pundits argue that it does, but the success data just isn’t there. You can’t take a team role and prioritize that role over another by awarding decision-making power. The product and the user must come first.
Perhaps it’s because software development lifecycles were largely designed by… software developers. Perhaps it’s because software developers are the ones writing the code?
Chew on this: a car assembly factory is not be designed for the workers who create the cars — it should be designed with creating quality cars quickly for the user. This means awarding decision-making power to someone with a more holistic experience of the entire lifecycle of automobile manufacture — someone who has earned respect through doing.
Why then is there a hesitancy to have QA probing the process and ultimately engaged to spearhead software development? Aren’t they the ones responsible for sign-off, auditing the incoming code, questioning the requirements, and engaging the time given to box each activity? Am I missing something, or is this an easy win?
For too long, QA has been seen as the caboose of the software delivery freight train. And to be fair, that’s where much of testing belonged, not because testing wasn’t important, but it’s because it’s the only place testing could go. If boxcars and coal cars and locomotives are all too busy worrying what is going on around them to see the health and status of the entire cargo haul, the caboose will have no other role to play than the end tester and the train engineer will be stressed out and providing middle-of-the-road status reporting to boot. QA has rarely been set up for success to run the entire train; yet, it is the QA team that is uniquely qualified to do just that.
QA fights for the users, they dig into the technology, they use metrics to measure where the team is versus where they think they are, they push back on estimates, participate in status meetings, advise the decision-makers on go/no-go decisions, and are looked to as subject matter experts. Sort of sounds like they’re pretty qualified to advise on the entire process, doesn’t it?
If the very nature of a proactive QA team is to get in everybody’s business to shake out badness in both process and product, then why wouldn’t you want those same people giving the signals on the entire development lifecycle? Unless you have an ego somewhere on the team that won’t budge (or if you’re the problem,) the answer is that you’d be silly not to.
To be fair, software development and IT management have taken a number of steps toward driving Quality into software development earlier. Efforts such as the Agile manifesto and Test-Driven Development are steps in the right direction.
However, by themselves they lack a couple key elements: a critical mass adoption and a cohesive integration recipe prevent these techniques from being the life saver resulting in mass goodness blossoming from the industry.
The process of building software to run on (usually custom) hardware to create value for a company requires a process that by necessity creates Quality events (My Pirsigesque definition of Quality being the event during which software delivery meets assumptions.)
Creating a formal QA team with a top dog leading it will reveal these defects faster than asking developers to test themselves. Developers are often motivated to demonstrate success events to make their boss happy instead of failure events to create great software. Developers often follow the lead of their manager in this respect.
Managers who are motivated to demonstrate success events to their managers to make their boss happy instead of failure events to create great teams will avoid creating QA teams and argue that developers can find their own defects. Management leading by example begets transparency begets developers behaving like owners.
If your goal is transparency in failure, then your driving motivation is to build greatness. Your day to day tasks will reflect this. If your motivation is to demonstrate success, then your motivation is to receive a reward. Your day to day tasks will reflect this.
Moving forward with generating success points to look good is little more than a dog looking for a treat no matter the consequences. (If this statement bothers you, check yo-self… you’re probably doing it.)
This latter model is flawed, because building greatness is in itself its own reward and carries with it both wealth in experiential knowledge and wealth in capability as an emergent property. Emergent properties are always more powerful than short-term gain, they just take longer.
If you’re going for the reward, instead of the principle, you’ve got it backwards. This is why network marketing companies fail to produce well-rounded businesspeople — when money and enrollment for money is your primary motivator, you’re going for the effect instead of the cause. Get your motivation in check and ask yourself if your motivators are for causes or effects.
Quality events are caused by testing. Testing reveals defects and QA teams are the teams trained to light these events up by creating tests designed to root them out. QC, or Quality Control, teams can be employed to robotically search out aesthetic defects in a production-line style checklist evaluation. QC is a valuable testing approach but is not to be confused with Quality Assurance (QA) teams. QA teams actively engage to probe, understand, audit badness out, and inspire goodness. QA work inspires the process, product, and the entire team culture’s thought process. This holistic QA-driven system of evaluation, decision-making, and feedback loops together make up quality driven development (QDD).
QDD is a meta-concept I implement to be the approach that embraces the parent principles of Agile, Xtreme, and specific approaches such as TDD. I do not believe QDD is formally described or prescribed anywhere else in our industry or on the internet today, so I will take special care in describing its components.
As I mentioned early in this article, QDD is not anything I went off and invented. QDD is a natural phenomenon, an emergent property of the momentum of Agile/Xtreme best practices combined with the proactive, high-energy engagement of technical QA teams that use mindful evaluation, checklists, and multi-dimensional metrics to audit development practices and make product badness ferociously transparent.
Why isn’t everyone doing QDD? It sounds great, right? Well, it looks good on paper. With anything great, there is some discomfort involved in order to build this process into a real team. It doesn’t come without a price tag.
There is a lemma buried in holistic systems theory that says that a system can be only as strong as the weakest link within it. The downfall of every software team I’ve ever been on has not been technical ability — it has been pride.
It takes only one person with something to prove, a title to uphold, an image to defend, or a botched decision to cover up to create weeks or months of cumulative delay to a software product (to say nothing of damaged morale and employee turnover.) A specific developer with a chip on her shoulder can be relatively contained and possibly coached, but a manager exhibiting this sickness (and it is indeed a sickness) can spread throughout the entire team and kill morale for months. For QDD to work, everyone needs to leave their titles and self-image at the door and engage in a constant feedback, hugely transparent, punishment-free work environment.
Test-driven development is a technique within the framework of Quality-Driven Development. TDD is one of the most misunderstood concepts in software delivery, so let’s remind ourselves of what it is. TDD is when developers code methods in their code that test unwritten code before writing a line of implementation. Then, they code just enough implementation to make the test pass. They write unit tests to check variable values under certain conditions. They then change the test to make it more complex to take it a degree further toward solving the user story or requirement. They write just enough code to make the test pass, and write further unit tests to validate logic conditions that become more and more complex. At the end of this process, they have a complex test that demonstrates the coder’s understanding of the acceptance criteria of the user story or requirement, they have a suite of unit tests that must also pass in order for the build to get green-lighted to QA, and they have through this process gone through a thought process that challenges their assumptions and greatly reduces the number of possible defects that gets through to QA. QA can ask for the unit test pass/fail and ask to see the test written to express the understanding of the user story. The time and effort that this costs is lower than the time and effort needed to fix problems by developers not using TDD. A developer who insists that TDD is a waste of time is defending their ego and inability to effectively engage using TDD — all in the name of saving the project time. Erroneous! Erroneous! Erroneous on all accounts of every developer that has taken on this battle cry (in my experience anyway.)
QDD is the active engagement and empowerment of QA to facilitate a continuous active audit of development practices, build scheduling, story estimation and acceptance criteria auditing, in addition to testing scoping, authoring, execution, and reporting work.
This is in stark contract to software development approaches such as waterfall, RUP, iterative development, and even to a certain extent SCRUM. Each of these approaches shares an assumption in common that the prime directive of QA is to test. This is short-sighted and limits the potential of the entire delivery team.
Let’s discuss the anatomy of QDD per actual human role — software development processes get caught up in ROI calculations and workflow diagrams and forget that the basis of all software development is human dynamics.
Business Champions & Prioritizers
These people by their very nature are doers and organizers. They sort information quickly and need to be able to steer their potential pipeline of work by ever-changing business priorities coming down from on-high. Their word is only as believable as their track record of delivering good software when they say they will — at this level, they need to be able to demonstrate clear goodness and be able to communicate what is going wrong and what they are doing about it. These are artifacts of the QDD process because QA is already working in lockstep with developers to ensure that bugs are discussed and fixed. QA drives simple dashboard-style metrics up to business champions as per their need so that people in this role always have what they want the way they want it. Other software methodologies tell business prioritizers what they should be using — this is backwards. The software development process should serve the business, not redirect their questions to take the form of a deliverable that comes pre-canned with the template archive.
Software development leadership is almost always asked to take on too much. They’re asked to be visionaries, strategic thinkers, and also provide the tactics, and also track how their team is doing, and also provide coaching to developers, and also track development status and provide root cause analysis for problems. And attend every meeting. And remember architectural decisions and be able to talk to them at a moments notice. Some of these are fair expectations, sure, but it’s the context-switching that kills the application lead here. 6pm will roll around and they’ll wonder what happened to their day — they’ve been reacting to situations and in meetings all day, and they have 8 hours of work to do but the 8 hours has already passed. QDD is meant to take workload off of the development manager and distribute it more evenly to the people who should be taking notes and making decisions that are backed up in the pipeline to the application manager. Architectural tenets can be audited with the application developer’s input, they do not need to be actually facilitated by the application lead. Status should be centrally integrated in one place, not managed by developers and then fed to the application manager to sort through and explain to others. Root cause analysis shouldn’t wait until there is a problem, but be a part of daily inquiry into the underlying concepts and assumptions built into the very requirements or user stories under development — QDD provides this because QA is estimating, sizing, and probing these stories before any code is even written.
Business System Analysts / Technical Writers
BSAs and tech writers take the unfiltered comments and input from users and craft well-formed communications from them to hand over to developers. This is the primary assumption that makes their lives a living misery. In QDD, BSAs and Tech Writers are constantly engaged as a natural part of the auditing and probing process of “what is it exactly we think we are doing and why.” BSAs must be given direct access to these artifacts in the same central location they are pulled from. User Stories in Mingle, Requirement Types in Quality Center, cards in Tracker, or elements in Rally must be maintained in real time. If there are extraneous fields or element types, hide them from the user. Strive to use the minimum set of information necessary to get the job done. There should be no “dry spell” where BSAs or tech writers fail to engage or be engaged within QDD — they are an integral part of the information architecture and flow of the project. QA defers to them whenever probing the business user perspective of a feature under development or defect discovered that traces to a BSA/tech writer artifact.
I don’t need to tell you what developers do or that they are the heartbeat of any software delivery system. Developers tend to want to focus on writing code, period. Most developers — and technologists in general — despise administrivia and have a short fuse when it comes to tolerating meetings for the sake of meetings or generating metrics or reports that don’t really deliver any value but serve to put a check mark on someone’s checklist. QDD serves the developer by removing the nature of the obstacles that cause the usual set of context switching the developer experiences with other software development lifecycles. In other words, QDD gets at the problem and attempts to redirect or solve the issue before the developer has to be interrupted. There are times when the developer absolutely needs to be involved in decision making, absolutely, but those mandatory times are usually for about 30 minutes in the morning, casual remarks over lunch, and perhaps casual remarks over afternoon coffee and cookies. Centralized quality tools facilitated by QA and pushed to other stakeholders and integrated with the development’s tool of choice (such as Mingle) provides a very light overhead for developers. Their incoming work stream and end results are easily categorized and processed with little explanation needed from them. Their work is completely transparent in their code check-ins and the information needed from them is represented in mandatory fields in the defects they finish. BSAs, Tech Writers, users, and QA know exactly how to batch incoming requests to triage new bugs based on estimated priority and the technical backlog. QDD allows developers to develop.
Project / Product / Portfolio Managers
You may be tempted to think that I’m making QA sound like they’re doing the job of the Project Manager. Nothing could be farther from the truth. QDD is designed to hone the accuracy and uphold a consistent process for pushing information to PMs when, or preferably before, they need it. PMs need to be able to do resource allocation, capability modeling, predictive estimation, limited design work, occasional comps, and engage with business visionaries on a variety of topics in addition to ensuring that current project health remains green. PMs engage actively with QA to describe what they need to know about in order to do their calculations — QA arranges their centralized quality tools to provide the metrics data that feeds this transparency (in addition to any metrics QA pushes back on or suggests may accomplish the overall goal better than what the PM sees.) This back and forth conversation elicits the overall principles being upheld and naturally adjusts to the unique personalities that are always at the top of business units. QDD ensures that the entire delivery team is delivering not just for the users, but doing so in a process that provides the business unit champions the unique view into progress and status that they themselves feel is optimal. QDD respects differences in management flavor while focusing on the most valuable tasks needed to reach the goals.
QA Managers / Leads
QDD is a dream come true for QA Leads. Truly, it’s what most of them want to do anyway but couldn’t because the business championing for QDD either didn’t exist or because there was an ego in the chain along the way that was blocking the flow. QA Leads are in the best position to rate and rank the egos they experience, because they more than any other team member tend to experience the entire gamut of personalities from top to bottom. Like the scene in Liar Liar where Jim Carrey’s character can’t lie and is forced to give embarrassing feedback to each member of his company’s executive board to their face, a good QA lead will be able to mix humor with the announcement of badness or conditions that cannot be explained outside of a self-image problem with a particular person. The QA Lead does not wait for permission to be a project lead, they just strive to digest the entire picture of what is going on with the team and engage on each level of the team to probe for conditions that are slowing down progress or hindering understanding. The QA Lead is always asking the question “Why” when QDD is being applied. Driving to the principle or goal that underlies every development and management task is vital to be transparent and agreed upon. This is the most important job of the QA Lead — testing the product and raising defects is an important, but secondary, responsibility for a QA Lead in QDD. The spirit of QDD is to get every team member into this mindset by setting an example; the example begins with QA.
In QDD, the prime directive of QA is to holistically evaluate the process of creation and to connect to the final product a value-rich quality assessment by means of testing directly to the root cause of why the defect originated. Further, QDD presumes a leadership role of QA facilitating the change in development and management process by means of development metrics supporting a synthesized hypothesis of how to better structure the immediate process of delivery.
When all management and technical layers participate in this process, constantly reconnecting and checking assumptions with one another and focusing on building a team first and product second that is sustainable, this is QDD in action. QDD requires no additional work than traditional development paradigms, it’s just that the work is proactive instead of reactive and front-loaded instead of piled up at the end of the project.
QDD as both a conceptual approach and as a pragmatic planning and delivery tool encourages sustainable quality outputs and an enriched team over a longer term. People are happier, because they know more and have to figure out less on their own. You see less of people feeling left out, more people pulling in the same direction. In my opinion, QDD is key to building a delivery machine — not just a QA team — that is built to last.
End of line.