Shooting from the hip a little here, please to bear with me. Also, turned out a little lengthy. Sorry 'bout that.
I hear a lot about (and talk a lot about) the idea of a culture of quality. This is, arguably, where we would all like to be. But the relentless pursuit of continuous improvement that defines a culture of quality requires a few things to be in place beforehand. Quality at an organizational level (or team level, or personal level) doesn't just happen. It has to be sown into already fertile ground.
One of the bits that must be in place is a clear sense of responsibility at every level. If the members and teams within the organization are not prepared to be responsible for the successes and failures of the organization, there will be no necessary support for a continuous improvement practice. A culture of responsibility necessarily precedes a culture of quality.
In lean manufacturing, andon is a process in which the line worker has the ability to in some way stop production and alert supervisors and other line workers to a quality or process problem in production. Every line worker is given the responsibility of triggering the andon system (hitting the big red stop button) when they see a problem. The entire line is given this responsibility, and therefore, if a quality control issue makes it out the door, everyone from the design engineer to the guy putting the widget in the box is responsible for the failure.
Creating and fostering a culture where an employee will accept this mantle of responsibility and embrace it is not an easy task if you look at classic American management techniques. In fact, you will often find that the average American corporation is more than happy to foster a culture that eschews responsibility in favor of protectionism. Trying to buck this trend can get you in trouble; not everyone is open to change, even good change. As I have put forth the premise that a culture of responsibility is good, however, we're going to explore how to alter our management techniques to help bring one about. ;)
There are two primary enemies of the culture of responsibility: fear and lethargy. Fear I can help you with now, lethargy is a motivational concern (and not everyone can be motivated by means at your disposal).
The fear factor comes in many forms. Fear of making mistakes is a big one. Conflict aversion is another. People can be unwilling to go out on a limb because they don't want to be wrong. This can be personal pride or a desire to maintain some illusion of authority to others, or a combination of the two. These fears lead people down the road of abdicating as much personal responsibility as possible in favor of a CYA-focused strategy.
There are practices that we tend toward in American corporate culture that help engender these fears. What I'd like to do is explore a handful of them, and offer some alternative strategies. Then I would love to see this conversation continue in the comments, as I know many of you are managers or leaders of your own organizations. Keep in mind, this is a reflection of my experiences, I am not claiming in any way that any of the proposed alternatives is THE ONE TRUE WAY.
Measurement and Perceived Productivity/Quality
If you have ever been paid by lines of code, or heard of someone who has, you know where this is going. Now don't get me wrong. I am all for measurement and metrics. I am often heard to say "You can't improve what you can't measure." But you have to measure the right things, and I think we all know that KLOC is not the right thing. But there are other, more subtle, poor measurements being made.
Let's look at defects for instance. Can you appropriately assess a programmer by defect count? No. There are many more factors to consider. What is the nature of the defects? Are there repeated patterns? How do they relate in context of the code produced around them? Are they a result of sloppy coding, or of lack of context needed to write appropriate tests? These are all things that matter when you want to measure a developer using defects as a metric. These are all things that are not surfaced by a simple count, or, maybe worse, a ratio of defects to released features. A simplistic look at defects is no better a measure (and gives no more context) than counting lines of code produced.
Sort of the inverse of defect measurement is measuring productivity by numbers of tasks done or features implemented. Again, this cannot be boiled down and completely lacks context. Unless you have reached a point where you can define a standard unit of work for what the term "feature" means, a number of features is meaningless. Similarly you can't do a strict measure based on "stories" or "use cases" or any other amorphous bit of work.
As an alternative to these measurements, you can measure throughput at a larger, team-oriented scale. Establish a baseline for the amount of work that can be completed by a team in n time, where the amount of work is measured in terms of complexity rather than hours or items. This number will not come by magic, you need to build toward it and coax the team toward achieving their full capacity. But over the course of a relatively small window of time, you should see a leveling off of throughput. Once you have this baseline, you have a metric from which you can make assessments. Estimate complexity for new work only, do not assign complexity to rework (defects). In this way, defects that creep into a development cycle will naturally decrease the throughput on new work, and you use this deviation as an indicator of either quality downtrends or productivity downtrends. Conversely, you may see positive deviations from this baseline that will indicate a throughput, capacity, or quality increase from the established norm. At the end of the day, the importance to the business is predictability of outcomes, in terms of throughput, cost, and quality, at a level more macro than an individual developer (in teams greater than one of course). You can further use this new understanding of team throughput to properly assess when work will be completed, when it's time to add capacity (more developers or testers), and what sacrifices to make when priorities change.
This of course doesn't absolve you of the responsibility of managing an individual's performance. It does, however, give you the ability to spot problems when they are happening, and then look at the surrounding context. You learn from measurement that defects are causing throughput to suffer inordinately, then you investigate the defects to determine the proper course of remediation. It may turn out that a defect is caused by the developer needing some help with programming-related skills, or that there was a communications issue and that more than one party is at fault. A defect can be caused by improper specification or lack of appropriate tests. But there will always be defects, so it's important to know how they are affecting throughput before chasing every one down. The same is true for number of features implemented. If throughput drops because a developer has failed to deliver the expected amount of functionality, then you start to delve into the cause at an individual level. But first you have to have established a baseline so that you actually know that a reasonable expectation was in place.
Anti-collaborative Tendencies
The gold standard in corporate IT development is one person, one task. The idea that a team of people could better perform a task that is traditionally seen as an individual exercise is anathema to many. One business analyst talks to one customer. One programmer writes the code for one feature. One tester tests that feature. This is the mindset that leads to the thinking that adding headcount increases throughput by a correlating amount. Anyone in software for any amount of time knows that this is patently false.
Furthermore, this anti-collaborative environment is detrimental to both throughput and quality. It encourages the CYA silo-building that we see so often, because when the responsibility of a task is shouldered entirely by one individual, it triggers our human defense mechanisms that cause us to play the blame game, find scapegoats, and make excuses for poor performance.
As an alternative to this, I encourage the adoption of the One Team philosophy (possibly the most valuable SCRUM principle I've encountered). Collaboration and open communication, to the point of transparency sometimes, is necessary to ensure that people feel safe taking responsibility. It may sound paradoxical, but spreading responsibility among many increases the willingness of the individual to accept more personal responsibility. This is because shared responsibility allows us to lower our bulwarks and concern ourselves with the success of the team rather instead of focusing on our personal protection only.
Practicing the One Team principle takes many forms. At minimum the planning processes need to involve the line workers (coders and testers) to get accurate estimations of complexity. I am an advocate of pair-programming on the line to increase collective code ownership and encourage collaboration, as well as having the side effect of great potential gains in quality and completeness of code. Code reviews have a similar effect when done appropriately, without the benefit of in-the-moment interaction. In fact, anything that increases collective code ownership will serve to reinforce a culture of responsibility. When many people see the code, not only is there more of a chance that quality problems will be caught before going to production, but the incentive is higher for an individual to take responsibility for the code because he knows that he shares the blame for defects, even if the defect wasn't introduced by him. Collective code ownership is one of the most important things to have in place before expecting that quality issues can be handled in the vein of an andon system.
Mistakes, Experimentation, and Learning
It is typical in corporate culture that experiments and mistakes are to be avoided in favor of known paths and rote repetition. The aversion to making a mistake is a strong motivator in the abdication of personal responsibility for quality. Mistakes and experiments are seen as costly at varying degrees, and learning is seen as something you should have done prior to submitting your resume. People live with the fear that a mistake could cost them their job, and particularly in a down economy, there's a lot of that fear to go around. Unfortunately this means that there is no room for a person to take responsibility for improving a process, learning or teaching a new technique that may be on the cutting edge, or accepting and fixing a quality issue.
Toyota embraces mistakes and experimentation as learning and growth opportunities, and encourages a system where people are safe to experiment and make mistakes. Not haphazardly of course, there is a process required to prove the value of an experiment, but once the experiment is underway a mistake is not seen as a failure but as a necessary step toward a successful outcome. Similarly, Google has the much-vaunted 20% Time which is an extreme example of an experimentation culture, where justification is not requisite, but many Google features and apps have been born of this policy. In both of these companies, employees are empowered to experiment, and empowered to make, own, and improve because of mistakes. By most measures, these companies are both wildly successful and offer high-quality products (though GMail is suspect at times...). There are lessons to be learned here.
Now don't for a minute think I'm advocating the wasting of company resources for self-entitled experimentation. I have been guilty of this and so have you, but it is most certainly not appropriate. I am however advocating creating an environment where justifiable experiments are encouraged, and where mistakes are treated as learning opportunities (openly) rather than collected as annual review fodder. Encourage team members to spike ideas for a couple of days before hard decisions are made. In the long run this will at the very least have a net zero effect on productivity. Encourage team members to objectively analyze mistakes and quality issues and come to conclusions about their causes and solutions. Make sure there is a safe environment for reflection on failures to ensure that employees will take care to prevent failures from making it to the customer.
Conflict Aversion
Many people will hesitate to point out quality issues that may not have been their own out of fear of conflict with a team member or other collaborator. Many people will hesitate to suggest process or product improvements because they fear an argument with a manager, or a hierarchical structure prevents them from crossing boundaries. This is obviously a major impediment to continuous improvement, as nobody is willing to step on toes to take the responsibility of improvement on.
When we talked about One Team, we talked about putting in place methods that will create an environment more conducive to the open collaboration required for people to feel safe expressing concerns of quality or process. However, organizational issues beyond the immediate team can cause more potential conflicts that people are just unwilling to deal with.
Solving this problem requires a multi-headed approach. First, the development team needs to know that they are a part of, not separate from, the organization as a whole. We/They attitudes toward the larger organization prevent the team from putting the needs of the organization above their own sense of entitlement. Only by adopting the mindset that the team is a cog in the larger machine will the team be able to think organizationally. As a leader, it is your job to make sure the us/them wall gets broken down.
Secondly, you must become the advocate for the team to the rest of the organization. If you create an atmosphere where your team takes responsibility for the whole organization and brings you a quality concern or process improvement idea, it is incumbent on you to take that as far as you can in the rest of the organization. You remove the conflict from the shoulders of your employee and put it where it belongs, with you. If a developer thinks he is going to have to fight a losing battle with sales to get something changed, or worse, thinks that there is no conduit for communication across these boundaries, then he simply won't care about anything beyond his IDE, and that is not going to lead your team toward adopting a culture of responsibility.
I think I've carried on long enough about this for one blog post, but I'm interested to hear what you think. As a final note, it's not easy to change some of these long-engendered attitudes in a corporate culture, nor is it always possible. However, if your goal is to be a change agent and create a culture of quality, you must first put into place the changes that will allow a culture of responsibility to evolve.