Alan Skorks has an interesting post on different ways to look at software development: (emphasis in the original)
the majority of companies that build any kind of software are ‘software as a destination’ companies. […] On the other hand, most individuals who build software for those companies would instinctively like to be (and in many cases ARE) ‘software as a journey’ people. […] there is a fundamental disconnect between what a company wants to get out of building software and what the developers will try to extract from the experience. […]
There was a bunch of people [“the agile movement”] […] [who] decided to give a united voice to the message that as long as you take care and extract the maximum benefit along the way, the destination will take care of itself – you will arrive somewhere you want to be. It may not be exactly the same place where you thought you would end up, but it will be a nice place nevertheless and best of all, you will have a very good idea of precisely how you got where you are, despite not having a narrow focus on the final objective from the start. […]
But, it is so much easier to simply look towards the goals and on paper it seems like it SHOULD be more efficient. If you’re in management you want to seem more efficient and focused rather than being wishy-washy and touchy-feely, preaching self-awareness and a less-rapid pace just isn’t strategic enough. And so companies create artificial deadline pressures (like end of financial cycle of some sort), to make everything neater and make the people in charge look good and it feels like for every step the agile movement takes towards running software projects better, some company somewhere, takes two steps back.
This is right to some extent, but it also misreads the situation especially with respect to the Agile movement. What Alan writes is not only true for software companies, it is true for every company in the world. All organizations have goals and there is always a tendency towards meeting those goals as quickly as possible using as few resources as possible. This is true for car companies, schools, non-profits, financial firms, and so on. But in all these companies, you can also find people who want to bring the focus back on the process by which these goals are achieved.
And so there is a tension between these two sides (goals versus processes). But they are not mutually exclusive as different quality movements n the last century have shown us. Better processes ensure that goals, once achieved, can be sustained and that greater use of resources to maintain quality pays back in the long run. This is not a discovery of the Agile movement. Every quality initiative you can think of, including Six Sigma, CMMi, etc. are all attempts to bring the focus back on process.
The practical difficulty has been understanding how much you want to invest in quality (“time/money“) and how you go about implementing quality (“the approach”). And everyone (the CEO to the middle manager to the engineer) has different opinions. So a typical consensus has been to use a quality framework that is common in the industry and tailor it to meet the needs of the company. Every company that has more than one employee has some kind of policy or process (written or verbal) in place to maintain the quality standards that they think their customers expect from them.
But what tends to happen is that the company’s implementation of quality or discipline towards quality standards is not sufficient to meet the needs of their customers. Or conversely, it may be overkill resulting in wasted resources. While the former is more common or grabs more headlines (such as the recent Toyota fiasco), the latter situation can also be seen especially in critical industries as the military, healthcare and space exploration.
What is ironic is that the Agile movement is actually a response to more process. Agile values
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
Compare the left-hand side and right-hand side. It is very clear that Agile is trying to steer the software industry from being too focused on the journey and realize what is most important and that is (emphasis mine)
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Yup, Agile wants you to understand above all that the destination is pretty important. Of course, the rest of the principles do explain a better (easier/faster) way of meeting quality needs.
The importance of Agile is not that it helped create a better awareness of how useful quality is, but it provided a path to reduce the tension between meeting goals and ensuring quality. If you look at a heavy-duty process framework like CMMi, it is all about quality, but it is so cumbersome that companies either think that quality is too expensive or they implement way more process than they need and end up with expensive products that destroy business value. Agile offers a different way of thinking about quality that can be used by smaller teams thus enabling managers to make the right decisions about quality.