Quality Needs to be Managed
Quality involves not only delivering automated product deployments but also ensuring the software is maintainable. Delivering software on time is not enough, and delivering value to the customer is not enough either because people and software are expensive. We need to do better.
Quality needs to be built-in, a strong, solid lean principle. However, we don't have as many incentives to built-in quality as we do for finishing projects on time. Projects are always associated with direct value to the company, and quality is often optional and mismanaged. Quality does not mean QA, and it's way beyond just testing. Quality is not a department or a role; it must be every engineer's job. At scale, it's easier to say that the systems are never down, and there is way too much pressure and, therefore, no time to improve; well, these ideas are wrong and will only make everything worse. Let's first take a closer look at projects. Usually, the main goal is to ship features, but other goals could be fixing bugs, migrations, modernization, etc.
Project Incentives
Projects usually are at the heart of everything. PMO indeed exists in almost all companies. Projects are often planned in a multi-faced, dimensional way. From Portfolio, going over workstreams, to teams, and up to the individual. There are lots of ceremonies and controls around projects. For instance, there are usually multiple layers of managers checking the status of a given project. Critical projects often have even more eyes on them and could be from the C-level all the way up to the CEO. Projects usually work hand in hand with estimates (which I'm not saying I agree, neither saying is the best way of working). The fact is that there is a lot of scrutiny in projects. Often, projects are a mechanism to ensure a group of features gets delivered. Engineers can even lose their jobs for lack of delivery(and I agree), but my point is that projects and features are serious business. Why is quality not given the same level of importance and scrutiny?
Quality Incentives
The reality is that the incentives for projects(resulting in features) are very different from the reality of quality. Let's take a look at this simple comparison I've made here:
As you can see, Features have a lot of planning ceremonies and a lot of reinforcing mechanisms. I'm not defending planning (I'm not saying they are the best), but in reality, good or bad - projects get done. You probably read about the iron triangle, where there are classical tradeoffs between scope, cost, and time, where the quality is in the middle. Quality is easily the one who pays the most significant penalty. But it does not need to be this way.
Believing in people like I do, I think if you ask any manager, they will never say, "Let's sacrifice quality." Often, this is an unconscious side effect. Some people consciously ignore quality, specifically tests, but that is a terrible decision. IF we want quality, we need to make sure quality is there. Regardless of whether the incentives exist or not.
Leaders, directors, managers, and engineers must ensure that quality is always present, no matter how critical, how much pressure, or how far behind the team is. Being underwater is not an excuse to sacrifice quality. If you hire a constructor to build a house for you, you don't tell him to cut corners; you expect quality. We need to have exact expectations when we build software; we need to deliver software with quality even if no one asks. In other words, we need to make time for quality, and we need to make quality a priority.
Managing Quality
Quality needs to be managed. When I say managed, I do not mean "create a Jira ticket." That's how you make sure something will never be fixed. What needs to happen is that we need to create 2 loops. The first loop is a learning loop. We need mechanisms so people can learn how to do better. Often, it could be simple things like Reading books, doing book clubs, posting about books, and doing presentations about books. POCs, coding outside of work, is one of the most important things, as is training. You also want to do Coding Dojos, Hackathons, and Hack sessions. Training is not super popular nowadays, but it can be very effective if executed well. Finally, people need output, and the most simple and scalable way is to have a Slack group chat to discuss some solutions, designs, tradeoffs, and ideas about a book, share some POC, and ask for feedback. All sound learning activities, but they do not work without reinforcement. Which is the second loop.
Reinforcement is where, first of all, you need to have mechanisms to catch that something is not going well, which could:
- People are not learning (not reading books or not doing pocs, maybe)
- People are not taking lessons learned (there is a bug in prod, and people learned nothing)
- People don't have output (perhaps they have questions or learn it wrong)
- Relationship issues (sometimes the issue is not on learning but on the team dynamics; retrospectives are essential to catch this kind of thing, and 1:1s as well)
- As a leader (lead, manager, director, or even VP), you must act if you see something wrong. This means you act to reinforce quality, you demand refactoring, and you create space and time for people to learn and do better.
Reinforcement is how we correct the system. Without reinforcements, nothing happens. We can use different practices to catch other things - like, for instance:
1:1s: These are great for grasping personal learning and if the quality is applied daily in pull requests. 1:1s should happen every week and are a tool for reinforcement where the leader can help drive quality back to the rails if necessary.
Retrospectives: Usually good for sporting bad decisions, which people often will complain about and see if there are blockers for quality, frustrations are a signal as much as silence; also, it's a signal.
Leadership Acts: Another lean concept is that leaders must hold people accountable and not endorse bad quality behaviors. Leadership also motivates people to perform complex refactorings and improve quality even when no one is looking.
Unless your talent density is exceptionally high, you must create learning and reinforcement mechanisms. Otherwise, raising the quality bar will be difficult. Delivering projects on time and adding value are not enough. Keep refactoring and keep improving the quality of the systems. Complexity and technical debt never stop, so we should not surrender (never).
Principles of Software Architecture Modernization is full of examples, principles, and techniques on how to deal with monoliths and distributed monoliths at Scale. Continuous Modernization covers the mindset, practices, and shift to better work data with teams dealing with such systems.
Cheers,
Diego Pacheco
