Do You Need a "Quality Program"?

My answer to this question would be: It depends.

It depends on what you mean by program. If you mean an elaborate and detailed plan it will be highly likely that by the time you get to start executing it the conditions have changed and many of the details are no longer valid in the changed context.

And here is a related question: Is Quality Improvement a one-off? Again, it depends. If it means that once you have rolled out the quality improvement - you ticked off all the items on the list - you are done then in all likelihood your organization will fall back in terms of quality again even if it doesn't degrade.

But if you understand Quality Improvement as a process, if you construct it as a set of guiding principles and values, then you are on the path towards a sustainable approach.

And here is how it might look in practice.

Option 1 might be: Create a detailed program so that you cover all aspects of what is going wrong. This may take weeks or even months just to get this plan set up. And it will take some more time to roll it out. And then it will take even some more time to show results.

Option 2 could be: Create a laundry list of things that may have an immediate impact. Your people know what's broken. Poll their views. Then make small, incremental changes. Observe. If it works, do more of it. All of this can be instigated, modified, or cancelled within days or weeks. Yes, you might be wrong. But with small items all of them suggestions from your people who are as close to the problems as possible you will get the majority right. And for the few that don't work, you can react extremely fast and can cancel it.

I personally would go for option 2 since it would help showing results very fast and very early. Each small item that is cleaned up will uncover or emphasize other items that are broken. And this could be a bug that you fix, or it could be a small change in the process that you apply. With small incremental steps you achieve short term results, you don't have to flush down major changes that go wrong, and you plant the seeds for a continuous improvement and learning process.

Let me give a very concrete example. And this one amazes me again and again because it is so blatantly obvious that it is surprising that there are still companies out there who don't do this. Let's assume you have a system of a significant size. This can be an in-house solution, a one-off, or a commercial off-the-shelf (COTS) product. Assume further that you have an issue with the bug level. There are just too many of them. Then here are the rules that you can put in place to address the problem, fix it, and prevent it from reappearing:

1. Each bug must be reproduced by an automated test.
2. The automated test is to be included in the automated (regression) test suite
3. The code is modified until all tests pass.
4. A new version, e.g. a patch, can be sent out only if all tests pass.
5. If the bug is fixed on a support branch it also has to be fixed on the main development stream (potentially other streams as well but I think that's a business decision)

With this set of rules in place, meticulously followed, you can expect the bug rate to fall noticeably within a short time frame. In one case that I'm aware of the bug rate reduced by 30% within 12 months (starting with zero tests!). I'm sure that some improvement was already visible after 3 and 6 months.

Bugs are not the only type of lack of quality. You can equally find lack of quality around processes, requirements, tools, etc. The approach would still be the same. Instead of a sledgehammer or Ben Hur sized quality program, try a continuous stream of small incremental changes. It's slow at the beginning since there is so much to clean up. But then it will gain momentum, and when it has become a habit your organization has changed it's behavior. Quality has been established as a process, as a part of the culture.

So, no, I don't think you need an elaborate program. Small, incremental changes, observation, then adapt, are extremely lightweight and can be introduced today. But you need certainly guiding principles that help your team understand that you mean business when you talk quality.

Quality!

What is the important bit about quality?

Just calling for it doesn't do the job. You've got to put your money where your mouth is!

So when you ask for improving the quality it might pay also off to think about W. Edwards Deming's "Red Beads Experiment" (description for example here). Why is this relevant?

In essence the experiment describes how you limit the quality any process can achieve by not allowing the employees to improve the tools and processes to do their work. In fact allowing for continuously improving tools and processes is one of the most powerful mechanisms to improve quality. And as Deming points out, the decision to empower or prevent employees from doing this improvement comes from management. So, if you ask for quality improvements and at the same time deny your team tool or process improvements you shouldn't be surprised if the quality level doesn't go up at all or not as quickly as you'd like to.

Zero Defects

Agile concepts are not as new as you might think. In fact some concepts have been around for quite some time.

For instance look at Test-Driven Development (TDD). It is a technique that among other things uses prevention instead of inspection to achieve high quality code. And in all cases the objective must be zero known defect. It is not about "good enough" quality. What is "good enough" in this case? Is it 2 bugs, or 5, or 10? It doesn't really matter. "Good enough" is not specific enough when it comes to quality. Zero defects is the objective. That's specific. Is it achievable? Well, apparently sites like Flickr release new versions of their system up to every 30 minutes. Is this doable if you have low quality? Very unlikely. Without automated comprehensive, fast (= cheap) testing Flickr would be able to do this.

Another technique that is popular with agile approaches are reflection workshops. These are basically opportunities for taking a step back and think about improving the way we work. And if (major) issues are identified in the process then the solution is not only to fix it but to prevent it.

All of these thoughts are not new. Philipp B. Crosby coined the term Zero Defects several decades ago. His book with the title "Quality is Free" is an excellent read. I just finished the sequel "Quality Without Tears" which was published in 1984, long before "Agile" became a hype. When you read the book you will notice that although some terms are different there are a huge amount of commonalities.

Get Quality Without Tears: The Art of Hassle-Free Management

Recognition: How do you share Fame and Blame?

A while ago I wrote about Staff Turnover (here and here). In this post I'd like to look at something that you can do for the people on your team. And maybe with this you can help to provide a better environment, a better place to work at.

In some cultures not complaining is equivalent to praising someones performance. The Southwest of Germany is such a place (For those who are familiar with it: "Net g'motzt isch scho g'nug g'lobt").

In other cultures rewarding has take on almost the shape of an avalanche. New Zealand is such a place (Remember all the awards, prices, etc. that you got at school? In some schools there are more awards than students!).

In other cultures appraising each other can become a group decease. The United States appear to me sometimes like that (Ever heard of the group cheering at Wal-Mart?).

So regardless where you live there are cultural differences in terms of how recognition is used to motivate people. And as a leader you can make the difference by sharing the fame with your team, and keeping the blame away from your team (unless they really screwed up in which case you'll probably have a private session with them that you don't want to share outside of your team).

So is recognition about affection? I think these are two different things. People certainly want to be liked. And if they can choose they will work in a place where they and their work is appreciated.

Recognition, in my view, is not about expression affection. Expecting being recognized for a good performance or result is not seeking to be liked. I think people can even "survive" for a while if they are not given recognition explicitly. If that's your style, so be it. Maybe you express your recognition in other ways, e.g. by giving your people a day off, or by giving them stock options, or by asking them taking on tasks that are critical and important for the company and come with more responsibilities.

There are many different ways to express recognition without having to express affection. Some of them are even free. Or how expensive is it to say "Thank you"? How expensive is it to mention people who over years showed persistent high performance despite all obstacles, hung on to the project and the team, and in the end made it happen?

All of this depends a lot of your style. Expressing recognition is important to keep your team motivated. It is certainly not the only means and it certainly is not sufficient. And if you use low-cost tools like saying "Thank you!" you must ensure that you really mean it. If you don't have the credibility of your team, just don't.

An entirely different question is if you give recognition, e.g. by company wide announcement, but don't include the people who had critical roles for the success. If you include only the ones that you interact with most frequently, or if you reduce other people's contribution, don't be surprised if people won't be as motivated next time round. Again this has nothing to do with the need to be liked. It's about ensuring that recognition goes to the right people. And it's not about what you intended to say. It is about what actually did say.

So the questions are: How do you share fame and blame? How do you give recognition to your team and the people on your team?

Update on Bureaucracy and Constraints

This is an update to my previous post on the subject.

Indeed I was able to find an option to reduce some overhead in my area. By using shared files instead of duplicated information I was able to reduce some bureaucratic overhead with reporting.

And here is another example: The PMO (Project Mangement Office) in our organization has decided to define a new charter for themselves in order to clarify their role and responsibilities. We started with a draft that had about 6 or 8 pages. We ended up with a net amount of about 1 page when we finished refactoring. That way we reduced waste.

And the biggest fun was from my perspective that the entire group participated and contributed to simplifying the document. It's now really lean and mean!

I'm sure we are able to do the same thing for other items again. We have the opportunity to become a really lean organization. It seems important to me to alway be on the lookout for opportunities to reduce waste, to try to find simpler solutions, to remove barriers.

If you build too many fences you will be surrounded by sheep. I think that in the age of internet communities like Facebook or Twitter people are looking for flatter hierarchies, more self-organization, and more freedoms. Everything else equal, people will choose to work for a company that comes close to the ideologies that is underlying the new online communities.

Managers that continue to use a management approach that might have worked 10 years ago will eventually loose out. Instead of administrative management, we need inspiring leadership that unleashes the creativity of the people in a learning organization. And in my view one important ingredient is collaborative decision making.

Constraints and Bureaucracy: Do you slow down your organization?

Most people I talk to will say that they want to keep bureaucracy at the minimum. At the same time they will say that a minimum set of policies, rules, and procedures need to be in place so that an organization can exhibit discipline and consistency across the board.

Agreed.


But then think of this: Your team interacts with lots of different other teams and individuals in order to work on projects. In addition there are cross cutting concerns such as administrative things (e.g. access to the building), HR (e.g. papers you need to hand in), Accounting (e.g. your last expense report), and so forth.


From each department's perspective they impose only a small little item (or two or three). And each item is just a very small thing by itself. And from that departments perspective each of the items is required and reasonable so they can do an excellent job.

The problems start when you pile the all the items up that come from different departments. Then progress in your organization may slow down significantly and may even come to a grinding halt.

So what to do? I have friends who have simply given up on some of these items. If they are given a spreadsheet to fill in they may decide to just throw in some (almost) random data (except if it is financial data). (Sorry, but I won't reveal names here to protect the individuals.)

Let's take an example: If asked to assess your team members and fill in 50 or 60 items in a skill matrix and given a team size of 15 or 20, we are talking about between 225 and 1,200 items to fill in. You probably need to think about each item for at least 10 seconds (this is a wild guess). But maybe you want to do a good job and do justice to the people in your team. Or maybe you want a realistic and true picture so you can be better at managing your project. So you spend 30 seconds on each item (Too much? Too little?). Then just this "simple" exercise amounts to 2 to 10 solid hours of your working time spent on a single spread sheet! Doesn't sound like much? Well, don't forget those other spreadsheets, reports, presentations, etc. that are waiting in your inbox!

So whoever thinks they are at the low end of bureaucracy, please think again! From a person's perspective who is affected by your actions the world may look entirely different, and your "small" request may amount to just that tipping thing that may keep those people from being successful. You may achieve quite the opposite of what you really wanted.

My recommendation would therefore be to consider for all your actions: How could you do less and still get a good enough outcome? (Or Google this: TSTTCPW. It applies to non-software engineering items, too.)

BTW: I will do the same myself and see whether I can't find an item where I might be causing avoidable overhead myself. I'm probably as guilty of this as anyone else....