Manifesto vs. Process: Avoiding the Agile Ritual and Maximizing Customer Return Pt. 1

DZone 's Guide to

Manifesto vs. Process: Avoiding the Agile Ritual and Maximizing Customer Return Pt. 1

The Agile Manifesto aids software development and developers. Essentially, to offer timely, quality software. Here's a look at why the process exists, and pitfalls of the rulebook approach.

· Agile Zone ·
Free Resource

Simply put, the Agile Manifesto was written in 2001 to help people with software development. In February that year - the start of the 21st century and during the heart of the tech boom - 17 people met to “talk, ski, relax and find common ground.” They desired and envisioned a way of doing things better and constantly delivering value to customers.

When we say better, in its simplest form it means to deliver software on time and budget that’s written code that is maintainable at the very least – something that previously seemed near impossible and certainly unmanageable.

However, the software development community seems to have lost sight of the original objectives, blinded by secondary procedures. This two part series will examine some of the procedural pitfalls we have fallen into in and suggestions on how we can climb out of them.

The Agile Manifesto holds true in its core spirits. It is a simple list, “The Twelve Principles of Agile Software,” that starts with its most important idea: “Our highest priority it to satisfy the customer through early and continuous delivery of valuable software.”

It was built as a guide that people should keep in mind while building software applications so that they ensure focus remains on the customer without sacrificing quality. The nature of software development is very dynamic, hence the creators almost certainly intended it to serve as a guidebook verses a rulebook. That way, people can adapt the core principles in the best possible way, for their specific situation – Remember, these were 17 friends in a ski lodge, they were not trying to write laws.

Fortunately segments of the software community, mostly startup teams and grass root groups, were quick to “adopt Agile.” Unfortunately, as the software community is famed for doing, static processes were built around the original principles and then applied as unbreakable rules to development teams. The highest priority is no longer “to satisfy the customer,” but to follow the script.

Image title

From the very beginning, a core reason behind creating the Agile Manifesto was because its founding creators valued, “individuals and interactions over processes and tools,” and “responding to change over following a plan.”

So, why did we create processes?

A very direct answer to this is that processes demonstrate business opportunity and are mapable to ROI. Our brains are wired to operate on certainty, it will almost always make decisions in favor of maximum certainty – especially in business scenario.

Our mind is wired to look for a rulebook to success. Think of the most popular blog headline formats, or self-help books and what their titles look like:

  1. Learn English in 21 days
  2. Lose weight in 3 weeks
  3. Start your business in 7 days

They all promise assured success, in a timely manner for the objective an individual has previously assigned as their goal.

This happens because our mind is hardwired to work in the past. This is an important concept. Understand that our mind makes predictions based on our past experiences. We become uncomfortable when we don’t know what to expect. You have felt this already when you trip over something while walking and you see it when you start to sweat and become overly alert. Your mind is baffled. Because of how our mind is constructed, it needs a rulebook to follow.

However, a rulebook for software development does not work because every project is dynamic in nature, each has different priorities - some need to be budget focused, some are time focused, some projects may require engineering to get certain qualities into the mix, and so on. The biggest factor remains the team, which constitutes of different kinds of people at different skill levels- both of which need to be considered before building your project roadmap.

The biggest pitfall to rulebook approach is that there is no such thing.

You can learn from other team’s experiences, but you must focus on creating your own practices with every project. Lessons learned from others are a good starting point, but don’t try to reenact their exact experience. Grasp their stories and develop qualities like foresight, determination and resiliency before adapting and evolving your own project specific plan.

The next edition of this article series examines a series of specific “Agile” procedures that have become entirely rigid, such as Sprint Planning, Daily Standups and Retrospectives.

agile, agile manifesto

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}