The Investment into Quality

If you're setting out to "become Agile", or "more Agile", I would like to say something in words as simple as I can:

Unless you're willing to invest heavily into quality, forget about "Agile".

Now, what I mean with "invest in quality" is not "throwing huge amounts of money into testing", because the investment you will make is actually free, and it doesn't involve hiring additional staff, either: If you're doing it right, you will spend a lot less money to get better results. What you need to invest is attitude, thinking, brainpower, capacity:

Now, let me elaborate:

The commitment to quality

I think that no sane person would say that "we like to produce garbage products." I have never met a  developer who would state on their CV, "I was producing crappy software." Likewise, I have never met a manager who would introduce their line of service as, "We deliver crappy software."

If nobody would say that - then why is it even something to talk about?

Most commitments to quality are just lip service.
You must act upon your commitment.

When I say, "commitment to quality", I mean that everyone, and that is, everyone, must continuously ask, "How do my decisions and actions contribute towards quality, both in a positive and a negative sense?" Any decision that leads to poor outcomes should be reverted, and any action that leads to poor outcomes should be stopped.

Nobody needs to justify themselves for not doing the wrong thing, or not doing something in the wrong way. It should go without saying that "if you see that it's going to end badly, don't do it."

Managers must commit to creating an environment where team members have the freedom to do the right thing. Reciprocally, developers must commit to resolving any problems within their own sphere of control and naming any organizational barrier towards high quality, even if that barrier has been set up by the CEO in person. This must be unpartisan, free from personal preferences or fear (and these three things are already massive barriers to overcome!)

Everyone, and that means absolutely everyone involved, from managers over developers all the way to side stakeholders, must commit to do their best to enable high quality.

Quality thinking

You must turn a commitment into action, and for that, you must understand how to achieve quality. Quality isn't a local thing happening somewhere between a finished product and its users. Quality begins as early as in the ideation, and it never ends as long as the product exists. Quality is everything. It concerns everyone of us, and each of our actions.

Let's start simple, with the choice to add a certain feature to our product: Will it make the product better, or worse? For whom? How? In what way? How does the very decision of adding it affect both the process and the outcome?

The new feature could be a boon for some, and a put-off for others. It could make the product inconsistent with its purpose. It could make it clunky. It could put stress on development. It could have effects that are difficult to discover until it's too late. Could ... now I don't want you to over-think. At least, I want you to ask the questions that need to be asked, instead of simply shoving another piece of work into the pipeline: Oftentimes, the product could be better by removing a feature instead of adding another!

So, who has to think about the quality?

Designers, in design. Developers, as they develop. Testers, as they test (of course). Operators, as they operate. And that's the simple part: "I must be mindful of quality in my work."

Developers have to collaborate with designers. Testers have to do that, too. And Ops. Logically, testers also need to collaborate with developers and Ops. And everyone with the customer. And with management: "We must be mindful of quality in our interactions."

All the time, everyone of us must constantly ask:

"What can I do, both in my own work, and to the work of others, to achieve higher quality outcomes?"

Quality practice

Move beyond words. Learn how to create quality: Design thinking. Behaviour-driven development. Test-Driven design. Clean Code. Stop the line. Data-driven decisions. Measure everything. Quality and Process management. Go-See. Standardization. Simplification. Candid feedback. 

Just to name a few.

If you want to be agile, quality isn't just for testers: It concerns everyone, even the most junior developer and the most senior manager. Even those outside IT. While, obviously, I'm not going to ask a VP of Sales to write Clean Code, I would daresay that if anyone within the organization makes a choice that results in someone else breaking with an essential quality practice, this is going to hurt the company's bottom line. Hence, everyone must have a sufficient grasp on quality practices to maximize the overall outcomes of the company.

Everyone must understand enough about quality practices to do what it takes to get best results.

Capacity for Quality

I'm not going to sugar-coat this: If you don't have processes, infrastructure and code that are designed for quality, you're not going anywhere unless you put some effort into that.

You must allocate a certain amount of capacity for improving and preserving quality.

If your company has been spending $100k on shoddy stuff and could live with it, what's so wrong with spending the same $100k on something of higher quality? Nothing! Never accept shoddy outcomes: "Do more" has lower priority than "do well." Capacity invested into low quality is lost. Capacity invested into high quality is gained.

"But," - I hear you murmur - "We will be slower, and the business / customer can't wait!" - not really. 

Stop thinking about what you deliver in a day or two. Set yourself a horizon of a month, half a year and then a year. Ponder how much effort you invest during that time into fixing bugs, into rework, into unused stuff and into rote work.

Set yourself a target to generate the same business results, without doing any of that wasted work. Then, ask yourself what you would need to get rid of this pointless work. If you manage to cut down on 10% of your current workload, you have gained 10% capacity for improvement. This capacity is now not "free for more poor quality work": It's free for improvement, so that you can do higher quality work that makes people more happy. 

True Story.

Is all of the above a figment of imagination, wishful thinking, idealism?

No. I'm talking about measurable, tangible business outcomes. 

Helping my clients engineer quality, we have significantly reduced defects, non-value adding activity and rework to cut down new feature development lead times by over 50% and expenses by as much as 30%, while reducing cost of failures on business end by seven-digit figures.

The "invest" we needed was about 50% of people's time initially - to change on their thinking, their practice and their environment, and 30% of their time subsequently.

If it was your money: Would you be willing to let people spend more of their time on quality, if the outcome was that you have to spend less money to get more things faster, while earning more money from happier customers, working with happier staff?

Yes, this question is purely rhethorical: "Time spent" is irrelevant if the outcome is "better business"!

Do it.