How to manage long-term software quality requirements?

Question

As newly assigned manager on an already ongoing agile continuous delivery software development project, one of the objectives is the following.

Ensure that software quality meets long term requirements.

The project consist of 50+ software developers distributed on different sub-products. So far, the following issues has been identified, which can be possible indicators that improvement is needed of the software quality.

1. No big new features been released in recent time
2. Different UX across sub-products
3. Some software modules are barely maintained after ownership shifts
4. Architect team is not responsible for quality
5. Software developers started leaving project
6. Seem too much coordinating across teams for new initiatives
7. Often workarounds are used meet customer requirements

So far, the approach to quality has been implicit. Recently, the following has been added.

• A Definition of Done of epics

This seems not to capture the above 7 issues, as it has a more narrow focus.

Quality seems hard to measure in a purposeful way as suggested by this and this. Further, it seems hard to navigate after the above 7 issues. This leads to the following considerations. How to identify purposeful efforts? How to estimate the effect of the efforts? When is it enough?

Anyone with any experience on how to approach managing long-term software quality focus?

Answer 1

First, project management is one thing and product quality management is another thing. Most of the time you have feedback from the people who buy the software, especially when they are not satisfied. Sometimes it is too late to make changes to the software when it is already on the market.

Second, you can include quality circles all along the development of your software to get feedback from potential customers. So, you avoid surprises that arrive too late. It is one thing to develop a product and another thing to sell it.

Third. you have to set clear, measurable and achievable goals in the development of your product. Goals that are easy to verify regularly. In business administration we call that "quality control".

Finally, it is important to know from the very start who is septic with the success of the product and why. Sometimes, some members of a team prefer to cash on the process than to declare it dead from the start. How are you sure of a success in product management? It is all about the needs of the customers. Nobody is obliged to buy your product.

Answer 2

TL;DR

While quality can be measured objectively, defining the domain-specific elements of quality for your organization isn’t something where you can rely on a standard dictionary definition.

In fact, most of the issues you’ve identified aren’t intriniscally quality issues at all. They seem more like organizational issues. We’ll look at some of them in more detail, and then follow up with some development and project management practices that can help.

Your Examples, Analyzed

1. No big new features been released in recent time

   Continuous feature development isn’t a sign of quality. When a product is “good enough” to sell in the market, and fit for purpose, then featuritis is often a sign that the company lacks market vision or customer feedback. For example, people didn’t want Clippy or Microsoft Bob; they often just wanted fewer bugs, blue screens, and viruses.

2. Different UX across sub-products

   This is a process problem, not a quality problem per se. Who is driving the need for a unifying UX? If the customers aren’t demanding it, and your process doesn’t include cross-team integration, then this is a look-and-feel issue rather than an actual quality problem.

3. Some software modules are barely maintained after ownership shifts

   This is 100% an organizational problem. Without collective code ownership, a culture of continuous refactoring, or IT governance that enforces component or process ownership, brownfield code almost always become unloved legacy code. Your leadership needs to assign ownership of components throughout the product lifecycle, because hope and wishing aren’t actual strategies.

4. Architect team is not responsible for quality

   Should they be? Architecture is (often, but not always) responsible for high-level design. It’s the engineering and QA teams (or better yet, fully cross-functional teams) that actually implement the solutions and build in and test quality.

   Again, quality means whatever your organization decides it means. Define it, agree on it across the organization, and then continuously test for whatever quality metrics you’ve all collectively agreed to. Without that agreement and testing, “quality” is just a buzzword.

5. Software developers started leaving project

   Churn happens in all projects. However, rapid flights of talent often indicate a toxic work culture, dead-end projects, death marches, budget cuts, and other well-known organizational anti-patterns. While the team can certainly hold a retrospective to identify potential problems, the business leadership ultimately owns the responsibility to fix the culture and process problems leading to the loss of key talent.

6. Seem too much coordinating across teams for new initiatives

   “Analysis paralysis” is a known anti-pattern. Large initiatives, especially for brownfield projects, always require more collaboration than small greenfield projects. While the pace of change often slows or stalls as projects get larger, the larger problem may be that you need a framework that scales beyond a single team, and works across multiple teams. Nexus, LeSS, and SAFe are examples from the agile world.

7. Often workarounds are used meet customer requirements

   While this may represent some form of tech debt, it isn’t inherently a quality control issue. While tech debt can slow development, or represent a quick-and-dirty hack of less than ideal quality, the mere existence of workarounds need not indicate insufficient product quality.

How to Improve Quality

There are several approaches you can take to improve software quality, but they all generally involve baking quality into your development and organizational processes. Some examples include:

1. Practicing test-driven or behavior-driven development.
2. Integrating modern continuous integration practices into your development pipeline.
3. Ensuring that the team and the organization routinely take time to inspect and adapt their values and practices, and make continuous improvement a priority.
4. Consistently tracking technical debt, and routinely allocating resources to paying that debt down.
5. “Stopping the line” to address significant quality control issues.
6. Making sure that working software and “fitness for purpose” are more important to the organization than simply meeting specifications.
7. Taking the time to refactor and redesign any aspect of the system that is hard to extend or maintain.
8. Taking a methodical approach to change. Writing tests before code, or following the Mikado method to implement redesigns, are just two relevant examples.
9. Making sure that your software is always in a potentially-shippable state.
10. Leveraging feature toggles and other continuous delivery practices.

Many of these really fall into the camp of development practices, rather than project management per se. On that front, your best bets are really:

• effective communication (with the team, with stakeholders, and with customers),
• very tight feedback loops, and
• a relentless focus on continuously improving both your process and the product.

There’s no silver bullet. In the end, you must define what quality means to you, decide how you will measure it, and then inspect-and-adapt your quality controls and your actual outcomes throughout the project life cycle.

Answer 3

I could say something about each of your points, but will address one. If you address this one, then you will figure it all out (eventually).

“Software developers started leaving project”

Ask why? Ask them why? Ask the people that are remaining why?

Hold regular retrospectives, find out why, have the developers find and fix the problems. Give them as much support as they need/want. Be careful not to dump it on them, and be careful not to continue to control, if they want to fix it.

Do not blame. Do no punish. If they tell you that they/someone messed up, then do not react: this is new information, you would not have known if they had not told you. Ask what can we do to avoid this happening again (no blame). Ask them what they would do to improve things. Run experiments, short iterations. Improve one step at a time. Don't try to fix it all in one go (You will go bankrupt before you finish).

Also you team size is way to big (“No big new features been released in recent time”, “50+ people”). However you must not kick them out of the company. Find other independent work for them (another project). Get written assurance from the board of directors, that there will be no layoffs because of process improvement. The first layoff will destroy cooperation.

“adding human resources to a late software project makes it later”. — Fred Brooks in his 1975 book The Mythical Man-Month. Removing them may make it earlier. But don't focus on this aspect. Focus on why they are leaving (people may leave in the mean time, and you need to figure-out how to down-size without destroying motivation. You can move some of the team into testing, other support roles, or process improvement. Then eventually into other projects.

Answer 4

First question is: what quality goals do you have? Typical goals are listed here.

If you identify a limited number of goals, you could put them in your Definition of Done (DoD) in forms like: "Every commit must keep or improve (modularity/security/whatever)"

The next question is then: how to ensure and enforce? Do you use code metrics? Do code reviews? And does anyone actually use the DoD? :-)