Monday, January 28, 2013

How do we know what to do?

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.


No comments:

Post a Comment