Today I dare to take an in-depth look at the Agile Manifesto values, their intended meaning, some misconceptions about them, and our observations how they are sometimes implemented in real life development teams that claim they follow the Agile framework.
Let’s first take a look at the original Agile principles outline in 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
The original Agile Manifesto has been analyzed, explained, and questioned by many. While we won’t dive too deep into those waters, we find it essential to provide a refresher, dispel common misconceptions, and share our perspective on these matters. OK, let’s do it:
Individuals and interactions over processes and tools
True Intended Meaning: The face-to-face interactions and collaboration are more important but processes and tools are still helpful and should server the team success.
Common Misconception: Processes and Tools don’t matter.
Our observation: The Agile framework is named agile for a reason—it’s essentially a suggestion on how to approach the development process, not a rigid directive. How often have you witnessed the methodology being treated as an immutable set of rules, implemented in a company without any alterations, as if even the slightest deviation could jeopardize the team’s success entirely? Alternatively, consider the scenario where an authoritative manager establishes or “suggests” a specific process to a group of introverted developers, especially if they are contractors or represent a hired agency expected to comply with client demands. If they do comply, and retrospectives reveal discomfort with the process, but they remain silent to avoid stirring the pot too much or because they are deemed “just the contractors,” that is not Agile either.
Our Understanding: Each team has its own dynamics, and consequently, its process should be unique. Every specific team should be free to construct its own (key word) development process and use tools that work for them without exceptions or enforced tools or processes. Granted, some organizations have specific ways of doing things related to compliance and audit, and teams may need to comply with procedures such as logging their time in a particular manner or using specific trusted tools utilized across the company. However, if other tools could help the team achieve success, they should be allowed to use them as well.
On the flip side, in cases of too strict adherence to every single written guideline on Agile, we must note that while structure is certainly needed, that structure must be defined by the team and never suggested by anyone. It should be carefully discovered through patient surveying, a series of trials and reflections, and by providing servant-only leadership to the team.
Working software over comprehensive documentation
True Intended Meaning: An actually working piece of quality software that is delivered as soon as it is possible is more important completing absolutely all possible documentation before the start of development.
Common Misconception: We may (or even should) start development without any or with only minimum documentation that gives us an idea of what we need to develop.
Our Observation: We have observed, that most of the times, products only have the following: list of epics, list of stories within each epic, maybe some mockups, and if the team is lucky, process flow charts. If the product is a simple couple page website without any submissions, it may be enough. But if there is at least one form, it may be insufficient. We have all seen the image below. I truly believe that the lack of necessary documentation, is exactly the reason why Mona Lisa is suffering here:
Our Understanding: Documentation may not be limited to Epics, stories and mockups. In the article The Fry that Shorted Agile Manifesto we have gone over how this value, having being misinterpreted, may impact the product and what should be considered as “enough” documentation for the product. We are not saying that all that documentation must be developed before the development starts. It may be developed, as the product development is in progress, but all MVP documentation should be completed by the time when the product moves to the development stage.
Customer collaboration over contract negotiation
True Intended Meaning: It is may be the most misunderstood value of Agile. It really truly means – regardless on what you have planned and signed agreements for, if the customer needs change (or if you did not properly understand them), you should change, too.
Common Misconception: Yes, you have got to change. This does not at all imply that directd by customer needs, you have to pivot as much as needed without any consideration of agreements or finalized contracts. This only implies that customer rules the way your product should work. However, contracts, agreements and finalized cope still matters.
Our Observation: Here’s what is the most common situation that happens so often; it has become the major pain point for those who are intimately involved in the implementation itself. Business does their due diligence, watches the market change, and requests updates to the scope without any consideration for the impact it may have on the product’s quality and release date. See Winning Developers’ Hearts – The Art of Respectful Collaboration.
Our Understanding: Always keep an eye on the market. Never stop asking customers what they need. If the needs change, adjust the scope. However, it’s crucial to manage these changes in a way that doesn’t break your agreements and doesn’t create significant impediments to the timely launch of your high-quality product
Responding to change over following a plan
True Intended Meaning: Be flexible. Be adaptive. Planning helps, but make it flexible, too. Learn and change based on your findings. Strive to improve.
Common Misconception: Have no plans. Just go with the flow. Yuck!
Our Observation: Unfortunately, we often witness two diametrically opposite interpretations of the value, and neither is truly beneficial: either excessive planning and preparation that undergo constant changes, causing stress for the team, or almost no planning, which is equally unhealthy.
Our Understanding: Have outlined plans and roadmaps, with room for adaptation within your chosen framework. Ensure flexibility that’s easy to follow when adjustments are needed.
The Agile Manifesto, like many guiding principles in life, often falls victim to misinterpretations. It’s not uncommon for these misconceptions to lead to a fundamental misunderstanding of the entire methodology. This misalignment, unfortunately, can overshadow the genuine benefits Agile brings compared to traditional waterfall frameworks.
In essence, Agile, while not flawless, is a valuable methodology when correctly understood and applied, offering a dynamic and responsive approach to software development.
No responses yet