There are several bloggers on BA Times who have written about agile methods. They've compared them against more traditional methodologies and missed many of the central themes and mindsets within the methods. In particular, one of the often missed points relates to documentation...imagine that! Let me provide some additional context here.

From my perspective, traditional methodologies (Waterfall, Ad-hoc, RUP, etc.) try to capture the essence of a project in the documentation for the project. The thinking goes:

• We'll gather our best people together
• We'll put them in a room and they'll think deeply
• They'll architect and develop models
• They'll analyze and write requirements
• They'll design the system
• They'll pull together a detailed, end-to-end plan
• They'll plan for quality and risk and process
• They'll hand it off to someone else to execute...

All of the intellectual property - the experience, the skill, the decision-making, the nuance, virtually all of the creativity has been stuffed into the documents. Usually there's a view that now that all the hard work is done, all we have to do is find a team to simply execute the details. In fact, almost any team could deliver this "well crafted" project...couldn't they?

Then Voila! Our Work Here is Done!

The agile methods come at this situation from a different direction. Why? Because the above approach usually doesn't work. I contend it's why we're still failing in nearly 60% of our software projects to meet stakeholder expectations across one or more dimensions of our projects. (Chaos report data) We've forgotten an important point in the above strategy. It's not that the documentation is bad. In fact, we often need much of that work done. No, the thing we've missed is the people, the knowledge worker, the team. In other words us!

We've forgotten that plans don't execute projects - people do. Architectural models don't guarantee a sound architecture that scales well under adverse, real-world conditions - people do. We've forgotten that exhaustive requirements don't guarantee that we delight our customers and exceed their expectations - people do. We've forgotten that quality doesn't get tested in. Instead it gets built in - by the people. Let me characterize it in another way; here is the agile people mantra:

1. It's ALL about the People collaborating around real working code!
2. It's about writing some more code to verify our presumptions in writing about the code...
3. It's ALL about the People collaborating around the new, real working code!

You see you can't solve problems by trying to predict the future solely within documentation. Here's an agile-esque and potentially different/better approach to attacking a project:

• You find a wonderful, highly skilled team.
• They do "just enough" documentation to get started
• They include the customer in all decision-making; in fact, they're part of the team
• They start building pieces of the systems, gaining feedback
• They're transparent to the customer, management, and stakeholders about their discoveries along the way
• They make informed adjustments as a team and with the business where necessary
• They triangulate the project through all of the uncertainty and deliver the most meaningful set of features to the client when they need it

In agile, it's not about the pre-work or the documents. It's about the people. Included with the people is the customer. They work together, are inspired and motivated together and they deliver together. It's about self-direction and honest teamwork. It's about discussions and openness regarding project state, progress, and trade-offs.

I would characterize any project that elevates and engages their teams in a holistic manner as being agile. Likewise, any project that allows their teams to think and respond with common sense to each project's unique requirements and challenges as being agile. In the same way, projects that allow them to decide what needs to be documented and, heaven forbid, what doesn't...because it adds no value, as being agile. In other words, any project that truly trusts and engages its people, can be defined as being agile!

If this describes your project environment, then independent of your software development methodology...you are, gulp, Agile!

Don't forget to leave your comments below

Robert 'Bob' Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at bob@rgalen.com

Comments (8)