Agile can provide many benefits, but it has its pitfalls as well…
The most annoying part of Agile
Most annoying part of Agile architecture… reopening all decision, never ending alignment, too many meetings,
Are we missing the whole idea of Agile? We ideate, we decide, we prototype, we “fire it up”, and if we fail, we fail early…
So, are we missing the point of Agile?
Agile is about being fast, Agile is not about “avoiding” decisions… Yet too often we are lost in endless attempts to “please” everyone through endless alignments… Looks like an ideal place to hide from responsibility, right?
Should not be like that…
Agile Manifesto
Agile Manifesto values: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan.
What does this mean?
Without going into big and bulk definitions, I will try to explain what this means in the practical terms (my view):
- Individuals and interactions over processes and tools – we value individuals and its expertise; we do not "bound" them and “box” them to predefined processes and tools – we give them freedom to think and create.
- Working software over comprehensive documentation – what is the purpose of software building? The purpose is to have working solution – not to produce endless documentation artifacts, who in the end, nobody is going to read or reuse.
- Customer collaboration over contract negotiation – again, why do customers need working software? Then need it in order their problem is solved, their needs are met – we listen to customers and aim to provide working software which is solving their problem – we (and the customer) do not waste enormous time setting full & fix scope up-front (however, worth mentioning, this flexibility does have an additional cost).
- Responding to change over following a plan – we embrace the change, no project is without changes, so why avoiding it – if changes are expected, let’s use it to improve the overall delivery and build working software our customers need (of course, this flexibility also does have an additional cost)
The concept is really very good – putting people (individuals) and gain value from their ideas (e.g. ideation in the Design thinking); providing in the incremental way the working solutions (PoC, Pilot, MVP etc.), customers & their needs a the first place (fitting the customer needs); and be prepare to change the “route plan” in order to deliver the outcome (do not be “frozen” with changes, be fast in adopting it).
But this concept tends to be misinterpreted very often…
Agile does not mean (or should not mean) – no governance, no documentation, not envisioned scope (where we want to be) – and it’s not meant to be delivered without any plan…
- Ideation is great and individual must be encouraged to step-in and bring the ideas – but we cannot afford all this is done without any processes and tools.
- Having working solution is one think – being able to maintain it, enhance it, and reuse it is completely different dimension. We are documenting in order we can properly maintain the solution (without being locked to the developers who built it); we can build on top of in future; and above all, we can reuse it in other projects we deliver… For all that, we do need reasonable amount of functional and technical documentation – sorry to all Agile “evangelists”, but this is really needed…
- We should not “micro-manage”, and negotiate to the last letter, the path to the final solution, but we still need to have clear alignment & understanding where do we finally want to be. Strategy is not something customer is building “on the fly”.
- Embracing the change is okay – but this does not mean we continue working without any plan – we simple adjust and re-plan backlog items for the forthcoming Sprints…
Agile is not a synonym for the chaotical delivery – although, in Agile there is something called “cowboy coding”[1], in particular “cowboy coding” approach could not be consider as an Enterprise grade approach. Agile must have its “ceremony” as well – but general idea is not to have it too much.
Then, is it better not to be too Agile?
No, this is not about if e.g. Waterfall is better than Agile – this is overemphasized dilemma from the past. In fact, common sense would simply tell us – let's use both (or all) knowledge we can, to our advantage – let’s use the best from both… Maybe hybrid approach works best, as described in the article It’s Time to End the Battle Between Waterfall and Agile (hbr.org) by Antonio Nieto-Rodriguez…
Finally, Agile also requires decision making…
Agile does not mean – no responsibility…
Teamwork – we all work together, so we all make decision together?
Yes, we do participate in the decision making, but not necessarily all of us equally contribute in making the decisions. Sorry, but in every project (or part of the project) we must have those who lead and steer the team, formal or informal leaders – and responsibility for making decisions must be on the (formal) leaders. Simple as that!
Hiding from decision making in endless discussion – this is clear misuse of Agile. People are invited to participate in discussions, to provide ideas and opinions – but decisions must be reached in a reasonable time. Once the decisions are made, we must commit on them. Please note, even in Agile, once we commit on specific work items, we do not change it during the Sprint – the time for discussion is gone. We may (and maybe should) re-discuss it on the Sprint review.
We all have to agree?
Another common misuse of Agile: “we all have to align, we all have to agree”…
No, we do not have to agree on everything, people can have their different views – but somebody still must take a decision, and assume the responsibility.
No hiding behind the group – responsibility should be individual.
Decision can be good or bad. Not making decision is always bad!
Remember, in Agile if we need to fail, let’s fail early… In contrast to this, if we do not test any concept (as no decision has been made) we fail as well, but do not learn anything from that failure…
Acknowledgment
*) Intro photo by Patrick Perkins on Unsplash
**) This article uses SAP Business Technology Platform Solution Diagrams & Icons as per SAP Terms of Use governing the use of these SAP Materials (please note, newer version of the Solution Diagrams & Icons, as well as Terms of Use, might be in place after the publication of this article).
More guidelines on Solution Diagrams & Icons can be found in this article by Bertram Ganz.
References
- SAP Managed Tags:
