Agile Has a Brand Problem

By Andrés Zapata \ August 2, 2018

I’ve never been a big fan of Agile Development. And for no good reason. It’s a fine ideology if you have the cultural and institutional support that will allow it to be successful. Couple that with the right type of projects and you’re set up success.

But, for some unknown reason, everyone who ever preached it was insistently annoying about it. It’s nothing against Agile per se, it’s something against all cults. I mean, how are we supposed to take anyone seriously when they call themselves the “Scrum Master”?

Since there are so many stakeholders with so many different priorities in higher education, the Waterfall Method works well for us — at least for the planning, research, and strategy phases of a web project.  Agile, or a form of Agile, tends to work best through UX, design, development, testing and deployment.

Just the same, however, I recently took another look at Agile and, even though it’s hard to admit, I began to appreciate the ideology in a renewed way.

So, to review, here is the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

And here is my current emotional take on it:

Individuals and interactions over processes and tools

Since the highest priority of Agile is to satisfy the customer, “Individuals and interactions over processes and tools” takes center-state in the ideology. Customers are people with needs and feelings; our focus should be on them, not processes or tools. This is important because indirectly, this forces everyone to practice a version of user-centric design. And you can’t really go wrong with that as long as you deliver a working product.

Working software over comprehensive documentation

The Agile Manifesto has a preference for working software over documentation. It argues that over-documentation is wasteful and counterproductive since we have to remain open to changing requirements anyway. Instead, it insists, leverage the time to deliver working software. This is critical because as the software takes shape, the business owners, designers, developers, customers, etc., can react and calibrate the software and feature priority in a near-real-time basis. Until Agile, tomes and tomes of documentation was the only way to write software. Agile turned that practice on its head and changed the way software companies compete. A company birthing software the old-fashioned way would release its first version in the same amount of time an Agile company had iterated two or three times with incremental releases and the user base to support further investment. It’s critical to convince clients that a high number of iterations and additive releases is not a measurement of failure; it’s simply a product of the methodology.

Customer collaboration over contract negotiation

Contracts are suffocating, collaboration is liberating. The Agile Manifesto prefers collaboration with customers over contract negotiations. Without this principle, developers and project managers would be locked to deliver against the contract and not what’s best for the user. In addition, changing requirements, even late in development, is expected.

Responding to change over following a plan

Similar to collaboration over contracts, Agile teams respond to change instead of rigidly following a plan. There are many observations in business and in life about what happens to a plan as soon as the project starts. But in the end, there are only three things you can count each project to have: start point, end point, and change. Being open to change preconditions the team for agility and collaboration. The alternative is a rigidity that can sour the team and bring the project to a screeching halt. Agile made it okay for minds (and requirements) to change and developers to adjust accordingly along the way.

When we at idfive take measure of how we practice, parts of the Agile ideology punch through loud and clear — specifically in how we practice User-Centered Design and Structured Flexibility. We’ve absolutely been practicing a version of Agile, I am just not ready to call it by its name just yet.

For all the good in Agile, it’s surprising that more people don’t subscribe to it. I wonder… am I the only person who rolls his eyes when they hear “scrum master”?

Perhaps Agile has a brand problem.