Agile methodologies have seen increasing adoption, and yet many organizations still fear it. Many of these fears are unfounded, based on misinformation and assumptions. At the same time, Agile is a shift away from the traditional command-and-control model that has been accepted as a “best practice” in project management. So let’s take a look at Agile, its core tenets, and how it challenges established practices. Then you can decide if it’s something to be feared or embraced.
Intro – Wouldn’t it be nice…
If you were to ask project stakeholders if they’d like satisfied end users, working software earlier, and the ability to alter requirements mid-project, they’d probably say ”yes” to all three; that is, until you tell them you want to run an Agile project.
Agile is at once simplistic and yet convoluted and complicated. If you ask 10 people what Agile is, you’re bound to get 10 different answers that range from varying interpretations and focus to blatant misinformation. Throw in different agile-based methodologies (like Scrum and Extreme Programming) and things become even foggier.
At its core though, Agile holds to a small list of principles and tenets. Understanding what these are and why they’re valued gives us a better understanding of what Agile is trying to achieve.
Over a weekend in Utah during February 2001, a group of 17 people who would become known as the Agile Alliance, gathered and produced The Agile Manifesto. Yes, it sounds like the start of some comic book-based movie, but this is how the formalized manifesto came to be. Part of this crowd included Martin Fowler, Ron Jeffries, Robert C. Martin, and others. In the same way those early forefathers formed the American constitution, these men formed the authoritative work that Agilists for years to come would reference in implementing Agile in their projects and organizations.
So what exactly *is* the Agile Manifesto? It’s a collection of guiding principles for running software development projects. At a high level, here is what is valued:
The Manifesto also lists 12 principles behind the Agile Manifesto, but you can refer to those via the link found at the end of this article. But let’s touch on the four value statements, as these get to the heart of why Agile can be so scary, confusing, and challenging to adopt.That is, while there is value in the items on the right, we value the items on the left more.
Individuals and Interactions over Processes and Tools
We like the comfort and familiarity that processes and tools provide. It gives us an abstraction of sorts within a software project – I hit these milestones and create these deliverables using these management tools and we should succeed! Right?
Well, no… I’m sure we’ve all been on projects where the best intentions of processes and productivity tools offered no real benefit or, at worst, a false sense of security. Software projects don’t involve a cast of robots, they involve people. Individuals who have a real stake in the success of the project, individuals who are human and have feelings, needs, wants, and emotions.
You might think that last sentence is overtly touchy-feely, but software development is not about a process or a particular technology – it’s about delivering something that someone finds valuable. Processes and tools have their place, but not at the expense of interacting with the individuals that make up the project team’s various roles.
Working Software over Comprehensive Documentation
I did a contract gig a number of years ago to do up-front analysis for a system. We created beautiful use case documents that filled a large binder! And years later those use cases are still in that binder and no system has ever been developed. Where is the value in the documentation? Where is the ROI for the money spent?
The only valuable output of a software project is working software. Comprehensive documentation is not a guarantee of a successful project. In fact, setting a goal of compiling comprehensive documentation encourages processes and tools over individuals and interaction, and enforces a plan that is resistant to change.
You may be asking how you can get working software without documentation. This is one of the fallacies of Agile: that there is no documentation on an Agile project. Of course there’s documentation, but remember we’re talking about what is valued more. I would suggest that a software project doesn’t require the amount of documentation typically required, and that more succinct documentation complementing working software is preferred. After all it’s the software that provides the value to the customer, not binders worth of documentation.
Customer Collaboration over Contract Negotiations
How I loathe the dreaded Change Request. Nothing is more adversarial and potentially more damaging to a customer/vendor relationship than enforcing formal approval processes to make changes to contractual agreements. It’s because of this that Agile values customer collaboration over contract negotiations. Note that all of these value statements relate to each other:
If I focus on the individuals and interactions, and collaborate with my customers regularly, then we’ll catch requirement issues earlier and we’ll deliver working software faster.
Compare that to…
If I focus on implementing processes and tools to manage the project, and create comprehensive documentation up front, then any changes required can be controlled through contract and change request negotiations.
Did you catch the big difference between those two statements? One is focussing on delivering working software. Everything is driving towards deployment of something the customer will find value in. The second statement has nothing to do with deploying software and everything to do with maintaining a defensive stance and ensuring the project team’s interests are protected.
Agile is not just a new way of managing software development projects; it’s a new way of viewing software development projects: clients are allies, not adversaries; matching what’s built to blueprints in requirement documentation isn’t as important as interfacing with the client stakeholders and ensuring they’re part of the development process. By adhering to the first three, the fourth value statement becomes easy.
Responding to Change over Following a Plan
In a traditional waterfall style of project management, everything is laid out ahead of time including a schedule. What has always plagued waterfall projects are changes that arise during development. Because the plan is typically “set in stone,” contract negotiations are required and change requests filled out to accommodate any deviance from “the plan.”
But in Agile projects, responding to change is a natural thing. While you expect to have an idea of what you’re building, Agile provides numerous opportunities for changes to be voiced and integrated into a solution. For that to happen you need interaction with project individuals, commitment around delivering software and not just updating/creating documentation, and collaboration instead of rigid change request processes.
You’re thinking one of two things after reading this.
The first is that you see the benefits, you understand the value proposition, and you get what Agile is trying to do.
The second is that Agilists are crazy and have no idea how real software projects work.
That’s OK, I’ve heard those statements before. Ultimately, Agile is not a one-size-fits-all solution. I heard recently about a company that tried to implement Agile at a client site, but the client hadn’t bought into the collaboration and interaction aspects. In that case, a non-Agile approach might have worked better for them.
But for the vast majority of software development projects that start up every day, Agile is a valid option. The fear, the reluctance, and angst that Agile creates in people are actually revealing how much we desire control and the level of trust that we have with our customers. And maybe that’s the real fear in running agile – that it puts more faith in humans than a process-heavy methodology does. Ultimately, I believe, it’s an unfounded fear.