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.
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!