In the software industry, professionals hold different views on processes. Some say processes are bureaucratic and rigid, making their lives difficult. "Why in the world does a simple software installation have to go through X number of approvals when I have such an urgent task at hand?" Others (mostly members of organizational process groups) relentlessly endorse standardized processes and talk about how the organization could be benefited by the data collected from following those processes. Project teams, though, are often unconvinced, since what the data says and what the customer says can differ.
Processes are in everything, but, to maintain focus, let's restrict our discussion here to software development processes.
Why do we need a development process?
The very basis of having a process or following a specific development methodology is to have a structured approach to planning and execution. What we're trying to achieve here is operational effectiveness and built-in quality. This is true for any development methodology, be it Waterfall, V-model, or Scrum. For example, we try to anticipate and resolve all the problems that our code could have through verification at different levels, before it reaches the user. In this respect all contemporary development processes are identical, with their underlying emphasis on quality. But then why it is said that, in today's dynamic business environment, projects may attain greater customer and team satisfaction when arrived at through Scrum (or other Agile methodologies) than through traditional methods of development? To understand this, we first need to define quality.
What is quality?
Usually quality is perceived of as "meeting requirements" or "performing to specification." But is quality's definition restricted to this? Quality is also about satisfaction. To illustrate: My flight has been delayed and the new flight time doesn't meet my requirements. However, the ground staff at the airport has made every effort to keep me informed about the reasons for the delay and the new estimated time of departure. They have also offered me a full refund, along with a discount on my next booking or a stay at their lounge with a complimentary lunch. The handling of this crisis meets my satisfaction and thus I will continue to travel with this airline in the future, even though today they haven't really met my basic requirement.
In software development, satisfaction could mean customer's satisfaction as well as team's satisfaction in its efforts. Thus total quality in software development might be described as "quality of code" (meeting requirements or performing to specification), "quality of effort" (for example, eliminating waste), and "customer satisfaction" (or even "customer delight"). But is achieving this the end of road? Not yet.
We need to understand that quality is not constant. Something that delights your customer, satisfies you in your efforts, and meets requirements today may not do so two months down the line, if it keeps happening the same way. We've all watched E.T. and been fascinated by it. But if Steven Spielberg kept on making E.T. (or a similar film using similar technology) time and again, would you still be delighted? I wouldn't be, nor would Spielberg be delighted by his own efforts. Thus quality has to keep evolving, and an important aspect of quality is continuous improvement. This translates into consistent inspect-and-adapt cycles. Quality has to keep improving and reinventing itself, which means total quality also includes continuous improvement in quality.
How Scrum fits into a total-quality paradigm
Anyone who has worked on a Scrum project or who is aware of Scrum methodology knows that Scrum prescribes four different inspect-and-adapt points during a cycle of execution. This is where the Scrum differs from other traditional development processes. Though the emphasis of any development process is to achieve quality (the narrower view: meeting requirements, or performing to specification), it is Scrum that really emphasizes not only achieving quality but also continuously improving quality and raising the bar — that is, achieving total quality.
The four inspect-and-adapt points in Scrum are meant to measure four different aspects of total quality and to take improvement initiatives on a consistent basis. These points are:
- Sprint planning: To corroborate the quality of requirements and design
- Daily Scrum: To check the quality of operations (eliminating waste, removing impediments, gaining satisfaction in efforts)
- Sprint review: To gauge quality of deliveries in terms of meeting requirements and satisfying the customer
- Sprint retrospective: To improve quality of life ("How I can make my life better during the next sprint?" or "What made my life miserable in the last sprint?")
Meeting all four points marks a consistent effort in continuous improvement. So, the next time you're trying to convince someone about the importance of Scrum, think total quality. A process like Scrum, which strives to achieve total quality, can sustain itself in the dynamic business environment of today and achieve success.