One of
the most contentious items for an Agile team can be the requirements. Yes, I
said it - REQUIREMENTS. Because how you set up your communication with the
Business partner matters a lot. It really can set you up to succeed or fail,
especially if you have an immature organization, or an ambiguous process to
work with.
Requirements can take on many
forms, and each form has its strengths and weakness. The most
common requirement form in most agile organizations is the User Story. And if
you research it a bit, you can see why "requirements" and "user
story" do have some significant and important differences. The one thing
they have in common is that it is a vehicle that allows a development team to
work towards delivering something of value to the business. Less common forms
include use cases, Technical Specs, Functional and Non-Functional Requirements
or just plain wish lists. Each form has it's particular nuances, and I wish to
write about this because if you work with an organization that is familiar with
the less common forms, I find that the easiest way to "become
agile" is to use the old process and re-name the new items "User
Stories". This can lead to failure even before you get started.
I am NOT bashing the use of the
less common forms of communication, indeed I think that communication needs to
be well defined for any process to work. And I have seen Agile work with use
cases very successfully. But I do have some experience with the misuse of user
stories that makes it necessary for me to spend some time in explanations. In
looking at this specific type of requirement, I can see how it is extremely
valuable in a culture of openness and user centered focus.
User Stories were first brought
about with XP - one of the more technically heavy forms of agile. It
was intended to be a format that allowed software engineers to keep the user in
mind, and allow for development of a software that could be used by a
non-technical person. The system included three steps, the three C's. These are
CARD, CONVERSATION and CONFIRMATION. Each of the C's is critical for
getting the full benefit of a User Story. And at this time, many organizations
are losing this value due to several factors, including automation, lack of
focus, or just plain laziness. Let's explore those C's to see why they are
necessary.
CARD - this is the simplest of
the three C's. Because basically, it is the "template" of the user
story. Now, everyone takes it for granted, and can almost recite it. "As a
___ I want a ___ so that I can ___" or a version of that theme. But the
reason for the format is a useful one. The "card format" is made this
way so that we can focus on one simple thing - how the USER will see (and
utilize) the code that the team develops. Most tools now have this template
built in. They allow the team or client to "fill in the blanks" with
minimal thought. So minimal in fact, that we now have "technical user
stories" that have nothing to do with the user at all. We
have middle-ware or back end projects that use "user
stories" because the teams are "agile" - but the stories make no
sense. And my personal pet peeve, we have some product owners that fill in the
blank without so much of a thought as far as what the user wants (or who the
user is) but have a direction from a sponsor to do the system as they envision
it. This last bit completely undoes all three C's, but specifically, by looking
for convenience we have lost the value of the tool. The
"Card" portion is important, if you cannot model what you need in
terms of a user, consider utilizing some of the alternative requirement
methods in order to get a better result, regardless of the process you are
trying to follow.
CONVERSATION - this is a doozie!
This is the BIG thing that differentiates User Stories from all other
requirements. You see, by definition User Stories are not "set in
stone". They are designed to be not ready on purpose, to drive a
conversation between the business (user focused) and the development team (tech
guys). They are supposed to be annoying and obtuse on purpose, making the tech guys
talk to the business guys about what the user wants, how the user expects it,
what it means to build it and what best way to get it done within an iteration
is. This is normal, expected behavior from developing with User Stories. It is
time consuming. It is tedious. And it can be frustrating. And it is so on
purpose, that is the whole point of using User Stories correctly. In today's
environment, EVERYONE wants to completely skip this step. The business has no
time, and most tech teams have no patience. The need for
"conversation" is side stepped in most organizations now in favor of
expediency and "simplicity". The use of skilled BA's with automated
templates effectively does away with most of the need for conversation, and
with a push from devs to have "less meetings" or "use more
common sense" and from the business to "save time" or "have
a more complete backlog" or "get expert assistance" you have
BOTH SIDES wanting not to talk to each other. If your organization is there, do
yourself a favor - try using Use Cases instead of user stories. You will save
money, time and return to a slightly more command and control model that you
are more comfortable with. If you work with me, and say you are using
User Stories - prepare for this extremely awkward conversation. If you hire me,
you get the three C's, especially this one.
CONFIRMATION - This one is
easier. This is basically the last step in a process, really. This is how we
determine, based on the card and conversation, whether the code meets what the
user expects. Nowadays, with tools and processes in place to get this
"written down" using a template, many teams can generate
"Acceptance Criteria" to meet almost any requirement. Again, it is so
convenient, instead of a process of communication, it becomes an exercise in
filling the blanks. When I started helping teams, it was a difficult thing to
come up with adequate acceptance criteria, because this itself prevented scope
creep. But as automation has taken over, people can easily regress to
"wiggle" within the automated tools to bake in scope creep. It seems
that if you take the second C out of the equation, the "user
story" concept becomes nothing but a meme, while the requirements process
easily regresses to a "use case" type of system. Once you are there,
command and control mentality makes it easy to circumvent everything else.
I guess, in an odd way this could
be taken as a bit of a rant. Because with convenience and tools, we have
sidestepped one of the most powerful tools in the Agile tool set And
we have suffered for it - but it is so difficult to overcome convenience!! More
on this in a future blog. But if your organization and your team truly want
to achieve an agile mindset, you have got to know the why as well as
the how - and a skilled coach should help you get there without losing your
way. Maybe it is easy to see how human nature pulls us towards convenience. But
as an Agile Coach, it pains me to see so many coaches NOT saying much about
this, going on as if the technical side is the only one to look at in an Agile
Transformation. We have given up so much - and I am taking a stand against
giving up on user stories. I guess this leads me to two last things - yes,
readership is small. But please think of this in your organization. And lastly,
there are plenty of resources available out there for these thoughts to
reference. And many may be miffed at the fact that I will provide no sources.
But, I am a revolutionary after all, and I really don't want you to trust me. I
want you to THINK and make your own mind up. So, read on, make a stand and
research what you read. This keeps you and I honest, and hopefully moves us all
forward in our quest for agility.
ARRIBA la SCRUMVOLUCION!!
No comments:
Post a Comment