Friday, February 28, 2014

Agile Misconceptions



Everyone is doing Agile these days. Everyone. Not everyone understands the philosophy of Agile though. I come across many teams who profess that they are doing Agile, but some inspection often reveals that they are far from Agile, either philosophically, or operationally, or both. 

In this post, I want to share some of the popular misconceptions I see prevalent amongst the community that thinks they are Agile adherents, but in reality are not. These are in no particular order.

"If you are doing a daily standup, you are doing Agile"
Whilst a standup is an essential part of an Agile/Scrum framework, just doing a daily standup does not constitute following an Agile approach. Teams that do not follow the principles of team ownership, enhanced collaboration, pair programming, continuous integration, releasing a potentially shippable product every sprint etc, but do a daily standup religiously are far from being Agile. In fact, all the core essentials of an Agile framework are far more necessary than just the ceremonies themselves - as an example, some teams choose to skip standups, for instance, on Fridays.

"Agile means no design"
This one particularly pains me (yes I am a technologist). I come across this a lot. Some people assume that doing Agile means not doing any design. Software without design results in accidental architecture, which, as we all know, leads to brittle codebase that is hard to maintain and hard to grow. Of course we do not want to produce reams of documentation as part of our design documents, but 0 design is just not the right way to do software.

"Agile means no documentation"
Agile needs documentation. Not as much as waterfall, but without documenting anything, communication suffers and decision making loses focus. Agile teams should invest in diagrams and flowcharts et al versus too much verbiage. A picture is worth a thousand words, and is easy (and more fun) to grow and change as requirements and software evolve. No or desperately minimal documentation leaves too much to imagination, and since we all imagine differently, chaotic results often ensue.

"Adding resources will always increase velocity"
This misconception can often be high on the management favorite list. Throwing more bodies on a task is not a guarantee of faster execution. Good Agile teams go through a hardening process whereby team synergy and strong teamwork develop over time. They win together, and lose together. A high degree of synergistic maturity develops as team members build trust in each other, back each other up and support common team goals more than their personal goals. Addition of new members to established Agile teams will almost always result in decreased velocity for some time as team dynamics change, and the team needs to go through an adjustment phase. Not to say that training, personality or philosophy differences etc can also contribute towards a longer than expected adaptation period.

"A team with higher velocity is better than a team with a lower velocity"
Velocity is personal to a team. One team's velocity cannot be compared to that of another. The fundamental reason for this is that different teams estimate work differently. What is important is that a team use a consistently understood baseline or reference model in their estimation. Baselines for different teams are bound to be different, and hence their velocities will naturally be different as well. It is usually management that does not fully understand Agile that succumbs to inter-team velocity comparison to deduce relative team performance. A team's velocity should only be compared to its own from the past, and not to velocities of other teams.

"High Level Estimates need to be as accurate as possible"
Organizations that miss the core philosophy of Agile display belief in this one. Estimation is what the word means - estimation. It is not a promise or a guarantee of delivery. It is purely a tool to plan and start work. Once work starts, Agile teams more often than not learn new things which change their original estimates. What is important is that the team continues to become more and more productive as team synergy increases. Charting dates based on estimates that cannot be 100% accurate is a sure recipe for disaster.

"Agile involves no planning"
Many believe that Agile involves fast action without planning. Almost everyone used to do waterfall before they came over to Agile. People who felt burnt with extensive planning and documentation felt they could get away without any of those activities. Agile teams plan. The key difference is plan the verb versus plan the noun. Agile team "do plan" instead of following "the plan". In fact, Agile teams plan every day - course correction at daily standups being the most granular form of daily planning.

Stay away from these Agile misunderstandings and misconceptions, and power your Agile teams to hyperproductivity and success!