The Importance of Quality Engineering Practices in Agile Development

As I have working with a number of Agile development efforts I have noticed the importance of quality engineering practices in Agile adoptions.

Agile work management is about orienting people to make the right work at the right time. I sometimes think of it as the TIVOing of software development. We are timeshifting work. You wait and do things at the right time. Ward Cunningham, the inventor of the wiki, talks about only doing what you know. Don’t do what you don’t know. This is a critical quality in how we experience development in Agile.

A clear prerequisite to being able to do this is quality engineering practices. We have discovered that many organizations do not have a clear understanding of this. Now quality is a fairly broad term. It can be interpreted in many ways. People say, well, of course you need quality engineering. And I have a specific take on what I mean: a quality of correctness. It is correct.

It is little things like the code works and it continues to work. It does not have bugs in it. The code actually fulfills the purposes for which it is intended.

It is finished. Sometimes the code never seems to get done. There are always some bugs associated with it or the documentation did not quite get done.

And we have experience with this. It can be achieved. The project I mentioned in the post, Achieving Immediate and Continuous Bug Fixes in Agile Development, is an example. Because we wrote with sufficient unit tests, because we had good automated integration tests, because of a 100 regression test way of thinking, and because of continuous integration that ran these tests, when we finished a piece of code it was done and there were very few bugs, never more than 5 at one time for the entire project.

Now this does not mean that we had all the features you might ever think about. In my mind that is the trap we fall into. We say: ‘Oh, that feature should do X and Y should be done in a different way.’ That is not what I mean by done or quality. Quality means that the system does what you want it to do at that moment in time. We take small steps and make sure that each step is done in a quality manner.

Later, you might add some different features or change features to respond to market pressures, better ideas, customer input or other conditions. However, when the new stuff is put in, these additions also have the quality of correctness.

This requires good engineering practices. It is interesting to consider this because what happens is that the teams that achieve this way of thinking/acting with their code are very productive. They feel better. It is fun to be around them. They are always thinking about new things because they do not have to think about the old things any more.

The social side is that they are more willing to try new things. It means that there is more innovation in the products. They know that if something is done it will be quality or they will just take it out.

I see Agile being like the train running down a well laid set of tracks, constantly moving forward on a solid foundation. When the foundation is kept strong (the attitude and practice of quality) the train can easily move. As you go forward everything is working and you are just advancing. More alignment is naturally achieved.

In fact we use the term release train to refer to a particular way of deploying software on a regular basis. It is this feeling. You are on an engine that is running and you drop new requirements in as you go forward and working functionality comes out the other end.

This causes some other issues. At times, developers never feel they are done. So we need to address this human need for accomplishment and build in pauses, vision setting, and reflection to address this human need. You need to have the team take time to stop and look at their accomplishments.

This means that way down deep inside the team has good tools and a good sense of what testing is. The developers know what good design is and how to recognize it. They know how to change the design if the requirements change. Extreme programming really pointed the way to achieve this quality. If you do not do this then Agile becomes just another process that sort of works. The old ways come back: schedules slip, bugs proliferate, morale declines.

I wanted to discuss quality engineering because it is important for people to understand that Agile is not just about making short iterations. An attitude of quality is important. It is an old software adage to get the best people you can. Here we are suggesting that the best people as those who know quality engineering.

Comments

[proteinpulver]

As the popularity of agile development spreads, more and more companies are discovering that simply breaking down projects into small iterations is not sufficient. Agile methods require changes in management, analysis, architecture, design, testing, and quality assurance, as well as project management. Team-focused agile methods prove to be insufficient for many organisations when attempting to spread agile beyond a few pilot projects.