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.

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....

Agile and Free Flow of Information

In his February 07 blog post ManagePro's CEO Rodney Brim discusses the relationship between being fast and managing information.

I like his post very much. However, ... in my post I'd like to discuss one particular aspect that I think needs some further discussion.

Rodney writes: "...the relationship between being fast or Agile and how..." - I think that being fast is not the same as being agile. I think that agile is about adaptability while being fast is about efficiency. Agile is about the ability to adapt for keeping the business fit in an fast-changing environment. Learning about changing environments and learning from past experiences requires the storage, retrieval, and distribution of information.

A lot of companies use paper or it's electronic equivalent for storing and transmitting information. While this has it's benefits for long-term storage - with proper backups it lasts forever - it has also it's drawbacks.

For instance, if I need a piece of information and I can easily recall it from my memory then this is the fastest to obtain it. If I have a colleague sitting next to me who I can ask and he has the information available then that's probably the next best solution. If I have to sit in front of a computer and enter a query I might get pages and pages of search results, even if I am fortunate enough to have a specialized search engine or even if the body of knowledge is stored in a good intra-corporate wiki. So this type of search tends to be very slow.

So depending where information is stored and what kind of access path I have, information is easy or harder to obtain.

But there is at least one more aspect. When two or more people communicate they again can choose different media to exchange information. After all, whatever one person is saying to a different person is nothing more than sending a small piece of information even if the content might be very simplistic. "How are you?" might carry the information about me caring about the other person. Saying "How are you?" in a face-to-face situation has a different effect than saying the same words on the phone, writing the same sentence in a hand written letter, or writing them in an email.

When I work with my people from my team or people from other teams, e.g. stakeholders, suppliers, customers, I am always on the lookout for difference in understanding of different people. When I spot such a difference I try to organize a face-to-face meeting of those people. I try to get them into one room and make them talk to each other.

I also share with my team as much information as I can. Although this certainly has it's limitations where privacy reasons of individuals or confidentiality of company information gets into the game, but it is an important factor for establishing trust.

Here is another way to describe my approach: In order to make my team more agile I try to "grease" the free flow of information. Only if the important information gets to every team member as quickly as possible the team can react in a timely fashion.

The same applies to reporting. I create reports on a weekly basis for the projects I'm responsible for. The stakeholders are informed at the earliest possible time of opportunities and challenges. Giving enough heads-up time with accurate information is probably one of the best things you can do to support your manager and other stakeholders.

So in that sense a lot of the information we circulate in my teams becomes tacit knowledge in the brains of the people.

As that is not always the best way to store information we also employ a wiki for information that we believe is valuable for long-term storage. And there are other media that we use as well such as spreadsheets, pion-boards, white-boards, etc.

So to become an agile organization it is important to use the most appropriate medium and channel for distributing and sharing information. As a collateral it is interesting to see that an organization that is very adaptible - that is agile - is at the same time also very lean and as a consequence very efficient and fast. In contrast a fast organization might be highly efficient and might be able to process service requests, product manufacturing, or software development tasks extremely fast. But if the environment changes that very same organization might have tremendous difficulties to adapt to the new conditions.

There is (at least) one more way of looking at this: Being fast is about optimizing towards efficiency while being agile is about optimizing towards adaptability. Both can be competing objectives at times.

In summary: I believe that an agile organization is very likely to be fast. But a fast organization is not necessarily agile. The other item I learned from practice: Free Flow of Information improves an organizations adaptability.

Cards Or Planning Tools?

In one of the newsgroups I monitor there was recently a discussion on Project Planning and Tracking Tools. I'd like to add another experience to this.

In a project for which I started coaching earlier last year, I introduced index cards for stories initially. People looked at it as something very "unprofessional". Paper and pen? How could that possibly work?

Well after a while the team decided that they wanted to introduce XPlanner. After yet a while some customers on the team decided that they were not exactly getting what they were asking for. As a consequence they started to put more details into the tool. Sometimes there were a lot of details even for how to lay out widgets on a screen and what colors to use. Screenshots of mock-ups were eventually added.

Yet another while later the team discovered that this didn't really help. Now the stories were very big and therefore hard to put into a short iteration. And the bigger they were the higher the likelyhood that they were underestimated. An extreme case was a story that was estimated at 47 units but which took 228 units in the end to implement. It actually consisted of a sequence of four stories.

It was clear to them that they had a problem. Now they have reverted back to using index cards. Writing or even drawing on an index card limits the amount of information you put on it. The team decided that the best and most important information on a card was the business value that the completed story tries to provide.

Having less details on the cards themselves has triggered more and better conversations or negotiations between the customer and the engineers. More options are discussed and it is much easier to move storie around. Estimation is better, and the geam gained more flexibility with regards to how to implement a story.

Bottom line: You might have an excellent justification to introduce a software based planning and tracking tool. But sometimes it is better to just go using simpler tools. If your team is co-located you certainly have more options, but even for distributed teams it is worthwhile to look for alternatives. Simple tools may lead to simpler and better solutions.