The Explanation of Agile You Probably Never Heard

Do you like Agile? Me too. Do you hate Agile? You rebel you. Just hearing the word Agile probably increases your pulse by 10 bpm and raises your blood pressure regardless of which camp you're in. Well, I’m here to relax you, to sooth your consciousness with alleviating words of perspective. So, settle in for a short, but helpful little post that will hopefully put your mind at ease. I’ll do that by giving you the simplest, most distilled, and practical interpretation you’ve probably ever heard about Agile. Then you can all go back to your raging arguments later.

The true meaning

Let’s get straight to the point; Agile is just a Product Mindset. This means if you can just remain focused on the product you’re building and not on the project for building it, you will have much more success being agile. It’s that simple.

Now, dear reader, you may be asking “what is a product mindset”? Put simply, a product mindset is a focus on creating a product that fulfills a customer need and elimination of all other effort that doesn’t work towards that end.

The Agile values as stated, are actually a juxtaposition between a product mindset and a project mindset. On the left side of each value is a statement that applies to the product, while the right side is a statement that applies to cost, time, and scope which are the primary constraints of projects.

Let’s break down each value independently to see why this is true.

1st Value

Individuals and interactions over processes and tools.

At first you may be scratching your head over how individuals and interactions could possibly be related to product, but in fact it’s fundamental to software design. We know this because of what Conway’s Law says, “organizations design systems that copy their communication structures”. So, in order to design a product where its systems interact well with one another then the individuals who design the product must also interact well with one another.

Organizations that emphasize processes and tools are a project-based organization because processes and tools focus on cost and time. We attempt to use automation tools like CI/CD pipelines to speed up the development process. We implement code reviews and change approval boards to limit exposure to defects which result in larger scope, higher cost, and more time. You can find the root of any need to implement a tool or process within your organization from its effect on cost, time, or scope.

2nd Value

Working software over comprehensive documentation.

It should be fairly obvious that working software is indeed about the product, that’s pretty straight-forward. However, comprehensive documentation is not about the product.

Documentation isn’t a bad thing; in fact, it can be very helpful. What we must keep in mind is to try and not make it wasteful. Documentation that helps the customer understand the product is good. Documentation that helps developers understand the product is good. Documentation about the time, cost, and scope is generally quite wasteful. Ticketing systems like Jira, or GitHub projects can help convey a problem with the product, or a feature of the product to build. But when they become about tracking progress, scope or time, they become anti-agile.

We should also realize that trying to make documentation so comprehensive that we can somehow answer every future customer or developer question is wasteful. Trying to be that meticulous is a project mindset that is trying to limit all future time requirements. In some ways it’s an attempt to halt the individuals and interactions from happening. The moment the documentation is no longer is about providing a better product you should stop.

The 3rd Value

Customer collaboration over contract negotiation.

Collaboration with the customer is how you know if your product is meeting the needs of the customer. At its heart, a product mindset is about designing a product to fit a need. If you are not fitting a need then there is no use for the product. The only way you can ensure the product is fitting the need is to remain in constant communication with the customer and ensuring that their needs are being fulfilled by the product.

Contract negotiation on the other hand is entirely about scope, time, and cost. In fact, a contract is a codification of those 3 factors. How could it be anything else but an expression of the project?

The 4th Value

Responding to change over following a plan

Similar to the previous Agile value, being able to respond to change means your product is able to continue to fulfill a customers need. The customers' needs are constantly changing and as such your product must be capable of changing with them.

A plan on the other hand is again all about determining time, cost, and scope. Ideally the time, cost, and scope all match the contract with the customer but rarely is that ever the case. We must plan for how much time a project will take, how many people must be put to work on the project, and that is partially determined by how big the project is. A plan is about as quintessentially project minded as one can get.

Conclusion

I’ll try to sum all this up this way; focus on the fact you’re building a product to suit a need rather than trying to minimize cost, scope, and time. This will make a lot of Agile concepts simply fall into place. That doesn’t mean you don’t do some of those things to manage cost, scope, and time. It just means you pay more attention to the product you're building and less on managing the way it’s being built.