Generally, in a project, you want to effectively manage scope, quality and cost. These are not independent; if you broaden the scope, cost will go up or quality will go down, or both. Your team is agile because they manage these three parameters over time. I won’t explain the word “agile” here in much detail. The basics of agile organizations were outlined by Tom Peters and Robert Waterman in their “In Search of Excellence” in 1982. They said “Innovative companies are especially adroit at continually responding to change of any sort in their environments”. Ikujiro Nonaka and Hirotaka Takeuchi elaborated on agile teams in agile organizations in their “The Knowledge Creating Company”, introducing a rugby metaphore in the process.
Quality has many dimensions, like reliability, maintainability, security, efficiency, etc. Google for “ISO/IEC 9126” and you’ll find an overview of aspects of software quality. I will pick the one aspect that benefits most from an agile approach: usability. I’ll use an example.
In my kitchen, I have an induction stove. It’s made by Bosch. It has controls that look nice but are horribly awkward to use. It has an on/off touch button. It has plus and minus buttons to increase or decrease the power for a station. It has a station selecton control. You need to press this once to activate it, then one or more times to select a station. After that, within two seconds, you have to press the plus button one to 18 times to select the amount of power (heat). When I’m cooking dinner, and one pot gets too hot and overflows, I cannot switch it off because pressing the minus button 12 times simply takes to long. So I take the pot off the stove, ignoring the little pan on another station with a delicate sauce that gets totally ruined while I’m paying attention to the pot I took off the stove. It is obvious: the person or team that designed this stove had no experience whatsoever in cooking dinner.
Now, take the stove my sister has. It is identical to mine, except it was made by Siemens, and it has different controls. It has four sliders, with which you can set any station to any level by one movement of your finger. You can switch off any station with the tip of your finger: no more overflowing pots or ruined sauces. I am certain that, contrary to Bosch, Siemens did have a chef on their team. Having expert users in your design team is essential for designing products with high usability. However, you can’t rely on users (expert or other) alone.
When Henry Ford created his first car, he didn’t do market research, he didn’t start from user requirements. Because, think what would have happened if he’d asked a random group of future customers to write user stories. User stories would be “I want the horse to be fast” or “I want two horses in front of the carriage”. You cannot rely on engineers and designers alone, because they don’t know how users use the product. You cannot rely on users alone, because they are not aware of all potential innovations in the product.
This is why you need a team of engineers, designers and domain experts (expert users, or “chefs”) to properly design a high quality product. Or, better still, make sure that your engineers and designers acquire the domain knowledge that is needed to make the product. Nonaka and Takeuchi provide a number of examples in their book.
“Agile” doesn’t mean “we can deliver a new release every two weeks”. Agile means “we can deliver new or updated features fast, whenever they are needed”. This is the dynamic aspect of quality: in a changing environment, the product adapts easily. This dynamic aspect has two dimensions:
- product itself should be easy to adapt
- the team should be capable to adapt the product promptly
How to make software easy to change has been subject of software development books since they exist. In agile times, you can ask yourself if you want to change software, or you want to replace parts of it. You do whichever is easier. You do need to decide in advance: do we make maintainable software, or should we modularize it in a way that we can easily replace parts of the software.
An agile team can adapt software to a changing environment at any time. This means, the team does not work off a “backlog” of specifications that have been created months ago. Rather, the team creates the specifications on the fly. This requires a chef on the project, to work with designers and engineers first on the specifications, then on the making or updating of the product. Please note that the “chef” is not the same as the “product owner”. According to Schwaber and Beedle, the product owner is “the person who is officially responsible for the project”. The product owner is not usually the person with the most domain knowledge. The product owner would be the restaurant owner, rather than the chef. What you need in your team is people with deep knowledge of the domain as well as sufficient experience working in the domain. They should be expert users of your current and future applications. They should know the organization well. They should also have a clear vision on where the organization is heading, or should be heading.
For agile quality management, you don’t need a product owner, nor a project manager. What you need is a boss who is an enabler and a leader. You need a boss who didn’t hire you to tell you what to do, but rather, who hired you so you can tell them what to do.
Also, you don’t need a scrum master because you know all members of your team to be familiar with agile team work. There are always team members who take charge and who make things happen. What’s most important for all team members is that they listen. They listen to what other team members say, and judge what they say based on their knowledge of and experience with the subject. What you don’t need is egos.
Summarizing, agile quality management is adapting your project and your product continuously, in an empowered, collaborative team, where decisions are made based on knowledge, experience and mutual respect.
“In search of excellence”, Tom Peters and Robert H. Waterman Jr, 1982
“The knowledge creating company”, Ikujiro Nonaka and Hirotaka Takeuchi, 1995
“Agile Development with Scrum”, Ken Schwaber and Mike Beedle, 2001