PDF Version: “When agile fails, a hotfix is not enough”

It is incredibly confusing how sometimes companies try to apply Agile Development and how they terribly fail to do so. There is no comprehension of what they define as their “own agile development” and certainly the chosen structure is at best unstable. This article analyses the situation with a pure engineering insight, leaving out of the picture all the micro and macro management processes. Finally,it challenges the fixed model that exists in most of the companies, which sets: “Agile development as the one and only panacea for everybody to follow”. In that attempt, it proposes the Manager, Architect and Developers (MAD) model, purely inspired from different aspects of real life examples.

Introduction

When in June 2001, a group of developers came up with a lightweight development method, they were just trying to solve their own problems in the area of software development. They defined some very basic and important principles that should be followed during development and they published the so called:

Manifesto for Agile Software Development

---

Individuals & Interactions
over
Processes & Tools

---

Working Software
over
Comprehensive Documentation

---

Customer Collaborations
over
Contract Negotiation

---

Responding to Change
over
Following a Plan

---

The manifesto states that while there is value in the items appear on the bottom of the above list, the items that appear on the top are considered to be more valuable. There is no doubt that the agile principles amplify a more flexible culture around software lifecycle and prioritize business reasons against time consuming processes. But a quote from the past, wisely recalls:

“In theory, there is no difference between theory and practice. In practice there is.”

Unfortunately, the agile model a decade after its first appearance, became another heavy industry. Expensive commercial tools, strict unnecessary processes, companies offering consultancy to a model that paradoxically enough, was targeting to simplify things. Victims of a system that is hard to change, in a period that software engineering explodes. Unfortunately, billion dollar companies are left with no time to reconsider their approaches from inside out and adjust a productive bottom-up development model based on their needs. Creating extremely frustrating environments that they are desperately trying to be agile, like there is no tomorrow if they choose not to be.