In the previous installment, we looked at what the business wants: a product of high value, and one for which costs of development and will be low. This time we’ll look from a slightly different angle: how does the business get what it wants?
There is a kind of universal development cycle. No matter what your development model might be, it probably looks something like this:
Since it’s a cycle, it starts at the top, and goes around until we stop; maybe only once (unlikely), or maybe a zillion times, or somewhere in between. As an instance of something in between, there is a kind of straw man version of a development model that goes something like this:
The development cycle starts when we discover something worth building. Because errors tend to be time-consuming and otherwise expensive, we want to build the product virtuously by making development ponderous, moving very slowly and very carefully, endeavouring to get everything right the first time. After identifying something worth building, we go about analyzing, planning, designing, and coding it, completing each of these processes before moving on the the next. After design is done, we start building the product in earnest, and we build almost all of it over a period of months or even years.
We don’t want errors as we’re testing, either, so we do extensive and ponderous planning of testing, too, focusing on documents and artifacts. We don’t want testers’ minds to be corrupted by knowing too much about what the developers are up to, so we keep them “independent”, essentially by segregating testers and test planning from the developers. (This is a straw man model, remember.)
Then, once almost all of the product has been built, testers begin to examine it — but because testing has been left to a “testing phase” after the “programming phase” is done, we’re surprised and shocked by lots of problems on our first real engagement with the product.
First, we discover that the testing artifacts, test plans and test scripts, based on development planning artifacts, are out of sync with what has actually happened in development work. The product that people imagined at the outset isn’t the product we’ve got. This is actually unsurprising and reasonable, since learning, epiphanies, adaptation, innovation happen as we try to build the product.
Having recognized problems or obstacles in the planned development, the development team has worked around them. The workarounds have taken priority over maintaining and updating the builders’ planning, design, and support documents.
Second, and just as quickly, when testers try to do some actual testing, we find lots of bugs, even though everybody tried to get everything right the first time. After that first cycle of a months-long “development phase” and a much shorter “testing phase”, there are a bunch of much shorter, more panicky loops as the developers try to fix bugs while working under a deadline.
All this is a typical — albeit somewhat cartoonish — story of development that came to be know as the “Waterfall” model. Interestingly, Winston’s Royce‘s paper (“Managing the Development of Large Software Systems”) that first described the Waterfall model doesn’t mention the word “waterfall”, and the Royce pointed out that development never really happens that way. But apparently, someone saw a legible diagram and thought, “Marvelous, marvelous!”; and lo! the Waterfall model was born.
In 2001, the Manifesto for Agile Software Development offered an alternative approach, identifying four sets of values:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The values were explicated in terms of twelve principles:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
In practise, there were two core ideas that contrasted with the Waterfall. One was to replace “build almost all of it” with “build almost none of it”. The other was to express “build it virtuously” in terms of building cleanly and simply, with change in mind. (Indeed, one of the earliest books associated with Agile software development, Kent Beck’s Extreme Programming Explained, bore the subtitle “Embrace Change”.)
It seems to me that — at least on the surface — these are all pretty good and reasonable things. The Manifesto and the Principles touted a far more pragmatic and humanist approach than the models of software development that were prevailing at the time.
We can summarize the Principles and make some inferences to cover some ideas that are common to all of the aspects of development:
- Deliver a built product frequently. When we do that, the product can be efficiently evaluated by the team and the customers, and reliably deployed.
- Cultivate craftsmanship. As the Principles note, “continuous attention to technical excellence and good design enhances agility.”
- Avoid excessive formalization. The Manifesto values “working software over comprehensive documentation”. Formality is expensive and often unnecessary — but when it’s truly necessary, we apply it. After all, the Manifesto acknowledged that there is value in the things “on the right”.
- Apply appropriate heuristics. This isn’t explicitly stated in the Manifesto or the Principles, but the idea pervades them.
- Maintain a sustainable pace. If there’s too much work for the team — or for anyone on the team — the pace isn’t sustainable.
- Develop and apply tools. Again, this isn’t explicitly stated in the in the Manifesto and the Principles, but tool use and tool making are normal and routine parts of development and testing.
- Collaborate across roles. That allows us to take advantage of the range of expertise across the team. As the Manifesto suggests, value “individuals and interactions over processes and tools”.
So here’s the development loop, with the overall principles in the centre.
We could agree that this looks like a pretty good way of organizing the business gets what it wants and how we might get it from the perspective of Agile software development.
And yet, the Agilists seem to have left something out…
Where’s The Testing Part?
Alas, neither the Manifesto nor the Principles mention testing at all; nor do they mention errors, nor critical thinking, nor the possibility of trouble nor of failures. The material refers to valuable software, to working software: “Working software is the primary measure of progress.” But what’s the measure of working software? That is, how do we assess that the software is working? It’s a fine thing to get the software to the customer as soon as we can, but might there be problems that we could usefully identify before we deliver something to the customer? So as not to waste the customer’s time?
The inattention to testing in the Manifesto and the Principles reflects the fact that their authors and the earliest proponents of Agility were programmers, developers. To be a programmer requires an enormous degree of optimism; faith that we can be successful in making things to solve problems. As I’ve said in another post from a while back:
Developers have great skill, expertise, and tacit knowledge in linking the world of people and the world of machines. What they tend not to have—and almost everyone is like this, not just programmers—is an inclination to seek and find problems. The developer is interested in making people’s troubles go away.
A responsible development organization needs to be aware of problems and risks so they can be addressed and managed. That awareness begins with the recognition that we can be fooled, and that problems can elude us.
Testing — the process of evaluating a product by learning about it through experiencing, exploring and experimenting — is how we discover the actual status of a product, and how we discover problems about it.
So. now that we’ve sorted out what the business wants — and how it might get what it wants — from development, we’ll look next time at what the business might want from testing.