Catching a glimpse of a snake charmer on a busy Indian metropolis, is a big myth that many foreigners visiting India still cherish (wishful thinking you might say!). But the reality is that snake charming is illegal in India (India Wildlife Act) and has been for a number of years, although snake charmers do still exist and are now an ‘elusive’ sight. But the myth still exists and something similar is the case with the agile projects and the myths surrounding them.
If you take a look at the the annual state of agile surveys for last few years, they have been throwing similar results wrt ‘Concerns’ about Agile (read as Myths – see below Reference1), reflecting the dismal failure of the agile enthusiasts to be unable to bust the folk tales surrounding the agile projects delivery. This post hopes to therefore Smash the Top 5 agile project myths (popular faolke tales), with a pinch of sugar/salt (take your pick) for added flavour.
Source: Reference 1
Myth1– Agile projects do No Planning
The traditional projects have a Big plan upfront, and planning is highly visible, with a complete plethora of activities, draining the energy for a couple of weeksmonths, and resulting in a sometimes scary GANTT chart.
But Agile projects instead focus on Continuous planning, and planning is therefore invisible!
Well you may ask how exactly that is achieved. The answer lies in the 5 levels of agile planning (at multiple levels) which includes the following –
1. Product vision plan
2. Product roadmap plan
3. Release plan
4. Iteration (Sprint) plan
5. Daily plan
Source: Reference 2
These 5 levels of continuous planning allows the agile projects to do continuous risk identification, assessment, and risk burn down via the daily scrum / scrum of scrums among others. The agile project teams are able to visualize these risks using the risk burn down charts, and able to highlight to the stakeholders about the potential upcoming pitfalls.
Myth 2 – Agile projects are Not Predictable and lack Transparency
The traditional projects typically provide an amazingly detailed Big GREEN cover report, with deep RED inside (aka. The Watermelon Report) for those who dare to dig deeper into a project health and find the darker side of reality.
But Agile projects provide Big Visible Dashboards on a real-time basis, which are visible to anyone who cares to look. The charts could include BIG Visible Burn Down charts, Release Burn up charts – showing possibilities of current state and the future trends, allowing trade off decisions to be made early in the project lifecycle. For teams looking at continuous improvements, the CFD (cumulative flow diagram) and other technical metrics indicating the project health and quality indicators complete the project dashboard, thus providing complete transparency and predictability.
Myth 3 – Agile projects have No Architecture and lack design
The traditional projects typically follow a Big Design Upfront model (BDUF) resulting in the creation of Big Balls of Mud (BBM) and extremely high maintainability costs, primarily due to the high cost of change inherent in the muddy architecture.
But Agile projects tend to let the architecture evolve and follow the emergent design model. Since architecture is indeed the ‘hard to change stuff’, agile projects tend to have as little of that stuff, and take guidance from the enterprise architecture policies and the application architecture constraints. The design spectrum diagram below highlights the BDUF to cowboy hacking approach and the agile projects fall in the middle.
Source: Reference3
The Ambysoft surveys indicate that 77% agile projects did perform high level initial architecture envisioning and are focussed on reducing technical debt more mercilessly, using the engineering practices like TDD, continuous refactoring and harvesting patterns for reuse.
Myth 4 – Agile projects have No Documentation
The traditional projects produce Big Bulky Documentation (BBD) for every stage in the software life cycle, most of which is internal and tends to get stale quickly, smelling of wasted time and efforts.
But Agile projects tend to write just enough documentation which is fit for the purpose for the team/project needs. The agile documentation could take many forms and occur at multiple stages in the project lifecycle. The collaborative approach of the agile teams includes using – wiki’s /word doc / simple sticky notes/ big physical boards – to communicate and document lightly the project story including the technical design and requirements elicitation discussions.
Source: Reference 4
Myth 5 – Agile projects have No engineering discipline
The traditional projects, which produce big balls of mud, have a tendency to end up forcing the technical excellence as a post release activity (“let’s clean up the code now that we have released to production” – is a common pattern).
But Agile projects always pay continuous attention to technical excellence, since agile teams know that a good design enhances agility and helps in the longer term maintenance. The agile teams accept change and have much simpler design thanks to the engineering practices, like following team coding standards, having collective code ownership, writing unit tests, practising continuous Integration and doing pair programming, while following test driven development.
Source: Reference 5
The Ambysoft surveys clearly indicate that the agile teams follow high engineering discipline, since – 72 % – write unit tests, 55% have coding standards, 58% do CI, 47% do refactoring, 38% do TDD
….and so the search continues for the elusive snake charmer. Let me know if you have seen one recently…
References: