Pretending to Be Agile
Date: Mar 15, 2002
Article is provided courtesy of Addison Wesley.
In much the same way that everyone claimed they were object-oriented in the late 1980s and early 1990s, and like the Java bandwagon of the late 1990s, now, in the age of the Agile process, lots of people are claiming that their process and projects are Agile. But the reality is that most are just pretending to be Agile—what actually happens on the projects on a day-to-day basis hasn't actually changed.
This is sad because the Manifesto for Agile Software Development offers the promise of a new way of working, and having this message subverted by the old, traditional, rigorous methods could condemn more developers to wasting time on death march or waterfall projects.
Agile Software Development Stands for a New Way of Working
Rather than the traditional, mechanical view of software development, the Agile approach is collaborative and human scale. It steps away from the individualistic software engineering paradigm and instead considers software development as a collaborative team activity.
The difference is striking. Rather than having workers in specialized roles handing off documentation to workers in other specialized roles, the focus is instead on the conversations that occur and how these are supported by documentation. These conversations happened in the traditional approaches, but they weren't really supported and facilitated. Projects that were lucky to have a good informal network for sharing information did well; those that had less informal communication were nearly always stressed.
In contrast, the Agile approaches put a high value on frequent face-to-face communication. This enables Agile teams to learn how to work together and provides a mechanism for resolving the inevitable misunderstandings that occur during a project.
The other aspects of the Manifesto for Agile Software Development are just as revolutionary:
By focusing on working software, Agile teams are forced to get the software running early and evolve it from there—this makes the software habitable. (See Richard Gabriel's Patterns of Software: Tales from the Software Community [Oxford University Press, 1998].)
By focusing on customer collaboration, the team actively involves the customer in developing the software, ensuring a better fit with the customer's real needs.
By focusing on responding to change, the team is connecting itself to reality, ensuring that if things change, the team will adjust the software to suit.
Paying Lip Service to the Agile Principles Is a Mistake
Although it's always possible to fake our process, claiming to be Agile is different because it sets up expectations about a whole new way of working. The principles of Agile Software Development are well known, and although it might take a while for people to realize the mismatch between word and deed, everyone who is temporarily fooled will remember for a very long time having been fooled.
Customers and users have been fooled lots of times, but things are changing. They are much more aware these days about what's possible and how projects should feel. They will easily spot projects that are pretending to be Agile because, as Jim Highsmith has said, "It may say Agile on the box, but it doesn't feel Agile."
Agile Feels Different
The most noticeable feeling is the sense of making concrete progress. All of the Agile approaches have an anti-bureaucratic stance that encourages the removal of roadblocks that slow progress. Coupling this with the commitment to release or at least demonstrate the software to users every few weeks or so makes for a team environment in which everyone feels that progress is being made.
Agile also feels different because it really encourages collaborative development, making everyone an integral part of a team in which members actually help each other. Team members communicate a lot more because knowledge is shared around the team and there is a constant underlying conversation that binds the team together. Rather than feeling isolated and pressured, team members know that they're not alone.
Customers and users feel involved in the project. Instead of being a nuisance to be ignored whenever possible, in Agile projects suggestions and ideas from customers and users are welcomed with open arms. Agile teams realize that they don't have a monopoly on good ideas and hence welcome suggestions from users as an easy way of improving the software.
Top Ten Signs That Your Project Is Just Pretending to Be Agile
So, given all of the above, here are the signs that your project isn't Agile.
The project plan has just been published by the project manager and it shows the first release happening 18 months after the start of the project. If this happens, you know the project isn't Agile. In Agile projects, the focus is on the planning activity, not the resulting plan. Planning causes the team to make decisions and set priorities so that something valuable can be released in a few months, and first release after 10 months practically dooms a project to failure.
The project manager is talking about the deliverables that the systems analysts will hand off to the application architects. Warning: Waterfall ahead! The next thing you'll see is the architects handing off yet more deliverables to the designers.
The systems analysts and application architects are proud of the fact that they didn't write any code on their last project. Bragging about not having written any code is a clear sign that the analysts and architects think that writing the code is a trivial and easy part of the project. With that viewpoint, it's only a small step toward valuing working software less than they value their documentation, a clear contradiction of the manifesto. Whenever any member of an "agile" team brags about being "above" another team member's activities, the team is just pretending; it has forgotten that the real goal is to collaboratively deliver working software.
The project is structured so that the programmers and testers are definitely at the lower end of the food chain. Agile projects start coding and testing much earlier than more traditional approaches, typically within weeks of starting the project. Putting the programmers and testers at the end of a long food chain makes it impossible for the project to be Agile.
The systems analysts keep trying to get users to sign off on the requirements document. Freezing the requirements might be a good idea in some circumstances, but the Agile approach is to collaborate with the customer to deliver what's needed when the software is released, not what was thought to be necessary when the contract was signed.
The development team complains whenever a change request manages to sneak its way through the change-control process. An instant giveaway. Agile projects expect and embrace change.
You're more than two months into the project and the project team still hasn't demonstrated any useful functionality to the users. PowerPoint slides or screen mockups don't count—have the users seen a real part of the application yet? Agile projects let users get their hands on the software really early, so that the users can let the rest of the team know what to do to improve the software.
The project leads consider the documentation to be more important than communication. This happens when the project is producing a copious paper trail, recording all decisions made to ensure requirements traceability—but in spite of that, nobody on the team seems to understand what's really going on. This isn't to say that documentation is bad—just that it has to be kept in perspective. If information is important enough to be written down in project documentation, it's probably important enough to get the attention of a professional technical writer. If making the documentation easy to read isn't a priority, you can draw your own conclusions about the project, but it definitely isn't Agile.
Testing and quality assurance are not an integral, respected part of the development team. All Agile approaches rely on early testing and validation for feedback about the quality of the software. As such, the testing and quality assurance activities are recognized as a vital part of the development process that have to start on day 1 of the project. Deferring testing or quality assurance activities until later in the project is a sure sign that the process is not Agile.
And, finally, the number one sign that a project is pretending to be Agile:
Tasks are assigned to individuals who take their work away to a quiet place and treat it as a solo assignment. Whenever "team members" are always seeking a quiet place to work, or wear headphones to block out the distractions from the rest of the "team," you can bet that the team leads don't understand collaborative development. If they don't understand the basics of collaborative development, you can be certain that the project is definitely not Agile, regardless of the posters that might be up on the wall.
Agile Is Not a Silver Bullet
Personally, I like the Agile approach because it drastically changes the conversation about software development. It forces us to consider the craft of software development and how teams of skilled individuals can collaborate to deliver great software. By explicitly nominating a new set of values for software development teams, the Agile approach has the potential to drastically change things.
In spite of this preference, however, I'm also very open to alternative approaches because I don't want to see a monoculture develop. Right now Agile software development is in the limelight, but it's just one approach software development. There are lots of other, equally valid and useful approaches to software development out there. Rather than pretend to be Agile, these approaches should carve out their own niches. Sooner or later someone else will come up with a new approach to software development that will become just as hot as the Agile approaches are right now. Your challenge is to keep an open mind about every alternative and to select one that will work for your project, regardless of whether that process is labeled Agile.