Note: this is taken from something I wrote to encourage discussion and thought around quality process within my team. In the end, I thought it was worth making public, but readability without context may vary.
Quality
Quality can feel like an intangible thing at times, we are more likely to see and feel lack of quality than its presence. Sometimes we see it as things crumble underneath of us, sometimes it sneaks up on us as lots of not quite perfect things build into a fractured whole.
Harder still is understanding how we arrive at ensuring quality. Is that even a thing we can do?
Quality for me is like productivity, it is one of those problems that acts like a bar of soap - the harder you try to hold on to it - the more likely it is to fly out of your control.
One of my favourite product development productivity wisdoms is from the book The Principles of Product Development Flow by Reinersten.
…the dominant paradigm for managing product development is wrong. Not just a little wrong, but wrong to its very core. Today’s product development orthodoxy is broken. What’s wrong? Companies are pursuing the wrong goals. They maximize capacity utilization, and wonder why cycle times are so long. They strive to conform to plan, and wonder why new obstacles constantly emerge. They try to eliminate variability, and wonder why innovation disappears. They carefully break processes into phases and gates, and wonder why things slow down instead of speeding up. Ironically, each of these actions actually hurts more than it helps.
My take on software and product quality follows a very similar path, people want to stop others from making mistakes so they remove their responsibility and ability to make decisions. They want to remove variability in outputs, preventing better more appropriate practices and checks for a given situation. They want to force quality on others, preventing anyone from contributing to it. Every gate put up in the name of quality eliminates far more opportunity for quality than it ensures.
Over the past 12 months, I have made 1000s of commits, is it actually possible for me to outsource the quality to someone else? or something else in the form of some fixed process? It feels naive to the point of absurdity that anyone but myself could possibly be responsible for the quality of what I do - yet in most product development spaces there is an inordinate amount of effort and misguided process put to take that responsibility away. It just doesn’t make sense, doesn’t work, and I think it is debilitating to actual attempts to improve the quality of outputs. So what is the alternative?
Quality as a Personal Responsibility
Let me start with the position that I think doing the best that you can do is everyone’s default, then there are things that degrade it: conflicting constraints (time etc…); poor incentives to balance those constraints; lack of skills or abilities to execute; lack of knowledge and tools to help improve what you have produced. And, I don’t think this is an optimistic position, it is far harder to believe that people are actively looking for ways to do poor work.
So the question isn’t one of how do we make it a personal responsibility, it is how do we support it as a personal responsibility. How do we provide the space and support required? How do we put the right incentives and goals in place that allow good decisions and the right balance on dealing with competing needs? How do we remove constraints? What tools do we provide to make it easier to achieve, to increase skill and individual potential?
The Role of Process
Does that mean process has no place in quality? Well, no. But the role is very distinct to how it is normally presented. The role of process should clearly be one of assistance and support for individuals rather than as a force for removing variability or forcing quality on others. Process should be seen as a tool that individuals can lean on for working through unfamiliar waters, helping them understand and work to team norms, helping teams discuss and contribute to improving norms. But process can’t be seen as the goal, if someone genuinely thinks that a team process helps them in a given situation, they should do it (obviously). If someone genuinely thinks that it is something that definitely does not help in a particular situation, they should not do it just for the sake of it (probably not so obviously) - but should use that as a trigger to let people know to expect a variation in norms. Note well that people should treat these variations with trust and respect, rather than fear and distrust, as it means people are making decisions and the upside is that they will apply that in the positive as well - doing more than the norms - when the situation demands it. When someone doesn’t have a particularly strong opinion, or is in unsure, then normal processes should be the default.
This is a long winded way to say do things that make sense, don’t do things that don’t (just because you normally do them), and always be looking for opportunities to do more and improve - don’t just slump over process lines like you just climbed Mount Everest and couldn’t possibly go higher - treat it like a minimal standard for interacting with the rest of your team.
The important thing here is the perspective on what process is, and how it should be thought about. Process is neither inherently good nor bad, it can often help but thinking of it as a control mechanism is almost certainly bad.
Simple Tools Go Further
What tools or processes can support quality the most? The word support here is not an accident. Repeating stuff must make it important I guess.
For me, the simplest and most effective tool has always been having a second perspective to analyse my work from. Depending on the change I am making, that might mean one person, or it might mean a bunch of different people for different aspects of the change, or in some cases it is just a matter of me stepping back from the problem to really think it through. More formally this can take the form of reviews: code reviews; design reviews, product reviews etc… but informally it is just about getting others involved in my outputs.
How can you get people involved in your work? I think the first thing is that it has to happen at the start of your work, not at the end. You need to take people on a journey, from start to finish, give them some context, get them invested in helping you, give them the tools to help you. I constantly refer to this as bookend-ing, you want to bookend your work with different perspectives, getting different people involved. If you think there is someone who could help you do a code review at the end, get them involved in a whiteboard session before you start.
One problem that often pops up with the more formal side of this (for example in code reviews) is that the same tools are more often used for what I refer to the bad side of process, for control/gate-keeping etc… and it taints the thinking around these tools, and how they are useful. Some things that might help you think about review in a different way.
Responsibilities in asking for help in the form of a review:
You are asking for help. Think about it like that.
You are asking for their time, focus, and probably for some skill or knowledge that you don’t have. Be respectful of that.
Be clear on what you want from them. Be honest about it with yourself, and be explicit about it with them.
Be respectful of peoples time. Always being prepared.
Don’t dump crap on people with the expectation of them telling you how to fix it. Always review your own work first.
While they may have some skill you don’t, they almost certainly don’t have the context of the task at hand. No matter who it is, don’t expect them to jump in cold, or to ever be as deep into a problem as you are.
Help them out in return as much as you can, this may be in the form of time, explaining the context, getting them involved at the start.
Respect their feedback, but don’t take it as a given. You may have more context, or awareness. It is not fair to put the responsibility of being right about everything on them. Incorporate what they say into what you know. Evaluate it, use it, don’t assume it.
Listen carefully for ways to incorporate their perspective into your own, so next time you can spot the things they do, and then they can help spot even harder things. Ratchet up your skill level.
Responsibilities in responding to a request for help:
You are being asked for help. Respect that.
Make sure you understand what they want. Don’t assume. If they aren’t explicit, feel free to ask/clarify.
Be generous in feedback they ask for.
Be reserved in feedback they didn’t ask for. You can always let them know, “I have some other questions”, or “I made a note of other things that we hadn’t discussed”, so they can opt-in to it. But be prepared for them not to go in for it. They may not be ready, they may be engaging with others, they may want to do their own review of it first.
Be OK with saying no and explaining why, rather than saying yes and doing a poor job of it. More generally, set expectations of what help you can and can’t offer.
Don’t expect or assume that your advice will be actioned. They will be getting multiple inputs, have much more context than you, or may not agree and be in a position to make a call. This doesn’t mean your feedback wasn’t useful, it will have made them think about things harder, it might even make them more sure of how they have done it. Giving the feedback is the win, not having it actioned.
Give people enough information, or even concrete steps to work it out themselves next time. “Fix X” is not that helpful. “X is a bit off here, how I spotted that is I work through this list in my head, and the rule is _" is really really helpful.
So yeah, feedback, review, communication around it. These are good things.
Completing work
Finish things. Everything else is irrelevant when things do not reach a state of completion. That doesn’t mean that everything that could possibly be done is done, but for the things that are attempted there should be a done state, that is good and speaks to the quality that you want if nothing else happens after.
Getting to that point where you can put it down is critical. If you (or someone else) has a list of things that makes the current work “not done”, you can never move on, there will be friction with how it interacts with other work - are we talking about what is there - or are we talking about what is there plus the “stuff to fix list”. It creates a fractured jigsaw, that no matter how good things are, they will never fit together.
Incomplete work is also baggage that will weigh you down. If you pick up some maintenance/fix list from every piece of work - over enough time - that maintenance list will be all you have.
Finding ways to complete things is a team exercise. It requires thought, flexibility and clear communication on all sides. But it is something that people find very challenging. I am not sure what to really suggest here, but try… talk to people.
Some good ways to have those conversations:
Should we remove X until we can revisit with a more complete perspective?
Could we split this into X and Y, so we can ship X as done, and allow Y to be re-prioritised with everything else?
I feel like this is a never ending rabbit hole, can I get some help with breaking this up into something deliverable?
Hey, you have been working on that for a while, want a hand to see if we can get something shippable out of it this afternoon?
I don’t think this really fits with the current state of these other features, how do we make it work without them?
Some bad ways to have those conversations:
X is hard. Do I have to do it? (me: So?)
Oh, it interacts with Y and Z, you better do X, Y and Z at the same time. (me: Noooooo! not being able to do one thing isn’t likely be to solved by trying to do 3 things)
I am just going to write down this is bad, so that I don’t have to make it good. (me: shakes head)
Broken windows
The completing work discussion dovetails nicely with the idea of broken windows. This is an old trope/idea, and I have no idea whether the actual broken window theory is a thing or just some nice sounding pop-psychology, but there are some practical outcomes of being aware of broken windows and not letting them get out of control.
This short story is if you don’t have time to sort it now, why would you think there is time to solve it later when you will have this and something else to do.
Leaving broken/low-quality work, will lead to broken/low-quality work being more acceptable in the future. It gives you less time to do future work. Every bit of work needs to be better than the norm, or it is most likely making all future work worse off.
Looking back
Another important, but very under utilised tool for ensuring the quality of my own work is to look further back than what I am working on right now. Often we want to complete work, check it off our list and move on never to think about it. And completing work is critical, but that doesn’t have to mean never thinking about it again. A little bit of baggage is a good thing. Something as simple as setting a reminder to review a big change 1, 3 and 6 months after is was “done” is a very effective tool.
Looking back you will personally have more perspective, but there will also (hopefully) be someone using or being impacted by that change to learn from. Is their experience good/bad/indifferent? It gives you an opportunity to make an explicit decision to keep a change, not have things exist just because they were done.
From a technical perspective, time away will remove a bit of the completion anxiety and personal attachment to the work. It will allow you to evaluate how it was done, how well it was documented, how much it makes sense. Can you even revisit it easily? If you struggle to get back up to speed with the change after 3 months, how could someone else. It is an opportunity to spend some time retroactively improving the documentation, the code, the tests, things that really help.
Acknowledgement over Blame
Ok, this all sounds fun when things are going well, but what happens when they don’t?
Firstly, blame is not helpful. Blame, particularly in the form of negative language shifts responsibility to address things to the people least likely to be able to do anything about it. Again, it isn’t likely that they wanted to do poorly.
For a different, non-technical perspective (but a relevant reminder), something I read some time ago: “The language of blame, responsibility and accountability” that really hits this issue home (in my opinion).
Teams have the ability to provide tools to help individuals in that team. If the tool/process/whatever doesn’t help, the default position should be that it is the tools problem not the individuals. So when things don’t go well, we ship a regression, something isn’t polished well enough, a customer finds a bug before we do. We need to address it as a team, not blame an individual who probably won’t be able to do anything different next time unless the team can provide them with different tools/skills/perspectives.
Instead of blame, the thing we want to have is acknowledgement. Ignoring problems isn’t any better than blame, neither are likely to stop it from happening again. So we need to have ways of acknowledgement without blame.
I don’t have anything as concrete as I would like here, but I think it starts with being mindful of how you respond to failure:
Be respectful of those who are working with you to try and build things with quality.
Acknowledge failures, something as simple as logging and tallying certain bug patterns or quality slips as a group can be effective.
Focus areas, when we pick up on common areas we let ourselves down with, call them out for focus. Even if it is just that intent, lets be extra careful with “X” things this month. Keep a short focus area list to rally around. Keep it to a few areas, so it is meaningful, trying to fix everything at once is likely to result in nothing changing.
There is more that can be done here, things like error budgets are interesting, but I don’t think they scale down to small teams well. Perhaps there is something to be adapted here into personal or other types of error budgets as drivers for a change to personal priorities/incentives?
The Point
There are too many words above to have an actual point to this article. I guess I feel like I think about quality differently to others, this captures some of it. Maybe it will make you think about it some. Thinking is good.