Many Scrum practitioners don't realize that Scrum did not
invent the idea of User Stories - XP (eXtreme Programming) did. They are,
however, often familiar with Ron Jeffries' "3 C's of a
User Story", namely Card, Conversation, and Confirmation. The more I train
teams on User Stories, the more convinced I am that the Conversation aspect is
the most important of the three, and it is applicable to all things Agile, not
just User Stories.
I recently facilitated PSI Planning for my area's Agile Release Train (Potentially
Shippable Increment). I’ve noticed that, with each new PSI, the teams
become more concerned with extensive pre-planning. They try to get more out of the
meeting by doing as much of the actual planning before arriving at the meeting.
Unfortunately, they do not understand that the primary reason for PSI Planning
is not to generate a plan as much as it is to have conversations. Teams must
communicate and align with each other and their customers. They must examine
their work to determine what dependencies and risks are inherent in the work so
that they can communicate, manage, and mitigate them as much as possible. This
process happens to produce a better plan, which is why we do it. However, those
who come to the event with pre-determined plans often find they must be reworked
or scrapped altogether.
Rework manifests itself as delay, and delay indicates waste.
Agilists hate waste. In fact, an Agilist’s views on waste and rework can be
found in the 10th
principle that accompanies the Agile Manifesto:
“Simplicity – the art of maximizing the
amount of work not done – is essential.” How do conversations help prevent
rework? If we talk before acting then we get a better sense of the truth,
established in an environment of shared context. Conversations mean multiple
perspectives, which bring difficult questions and challenge our assumptions.
They force us to produce something as a group that is better than could ever be
produced in a silo. They reinforce the paradigm of “just enough, just in time”
instead of “big up-front”.
Once I realized that conversations are integral to Agile, I
began to review the tools and practices within Agile, specifically Scrum, for
conversations. All of the prescribed ceremonies – Daily Scrum, Sprint Review,
Sprint Retrospective, and Sprint Planning – center on team conversations. Pair
Programming and Test-Driven Development are XP practices that rely heavily on
communication, both within the development team as well as between the
developers, testers, and customers. A good Scrum Master helps the team most by
facilitating conversations, and the Product Owner’s backlog is meaningless if
they don’t ensure the team understands the work. There are conversations baked
into literally every aspect of Scrum!
Conversations are often overlooked because people do not
view simply having the conversation as an objective in most cases. They focus
on the stated outputs: plans; acceptance criteria; status updates; confirmation
of stories completed; etc. Consequently, it is not uncommon for teams to find
alternative means to deliver these results without the “overhead” of the
conversations. They rely heavily on tools and individual efforts to maximize
their time without hindering the team with human interaction. They may, at
first, feel an increase in productivity as the perceived burden is lifted. Yet,
inevitably, they find themselves struggling to deliver quality quickly and do
not understand how Agile could betray them so. Hopefully they have a good Scrum
Master or Agile Coach watching them adapt in the wrong direction that can have
them take a step back so they can see the error of their ways. If not, it
becomes easy to blame their frustration on Agile and revert back to their
comfort zone of more “traditional” methodologies.
As a safeguard, I recommend teams, and especially Scrum
Masters, go back to their roots frequently to make sure they’re staying true to
the founding principles that make Agile methodologies so great. Remember that “business
people and developers must work together daily throughout the project,” and
that “the most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.” Don’t just blindly
follow a framework or practice; instead, try to understand why you are asked to
do things a certain way. If the purpose that you perceive is not aligned with
the Agile manifesto and its accompanying principles, you’re probably wrong.
Acknowledge your failure, “Fail Fast”, and change your approach so that it fits
the Agile paradigm. It may seem counter-intuitive at first, but it will pay off
in the long run.
No comments:
Post a Comment