easy-button

Agile User Stories Are Easy (IIBA Fort Worth)

I had the pleasure of speaking to the IIBA chapter in Cowtown last night. That’s Fort Worth for those of you unfamiliar with the Great State of Texas.

Total attendance was 15 people and we had some good conversation. There were not many questions during the presentation, but enough to let me know they were listening. I was touched a few folks from the IIBA Dallas chapter drove over for the meeting, thanks.

Holly Millet, a guest at the event, was kind enough to run the camera and record my presentation. If you are interested in seeing this, then please let me know and I’ll put it online and provide a link.

This presentation is at an introductory level, aimed at Business Analysts who have not worked in an Agile or Scrum for a significant period of time. I do not by any means cover everything it means to be an Agile BA, but rather focus on the elements of good stories, including writing Acceptance Criteria in a Given – When – Then format. This latter section should provide some value for anyone not already involved in the format. Unfortunately, with only an hour, I include enough content to push out interactive activities.

In August I coined the term Behavior Based Requirements to describe Given-When-Then and some of the related concepts to BAs. If this is your first introduction to this format for capturing and communicating value, you can find much more information on my resource page here.

As usual, I am posting a version of the slide deck here for attendees who want to view a copy of the slides. I typically shift the slide order just a tad to make more sense for reading at your desk. This slide deck includes references and mentions the mighty shoulders I stand upon when presenting.

iStock_000014958717XSmall

Behavior-Based Requirements

I am excited more people are talking about Behavior Driven Development (BDD) for Business Analysts. I know of three different presentations about the topic in Wisconsin this year! I had no idea this state was such a hotbed for BAs.

I am giving two different versions of my presentation this coming month. The first presentation is titled Reducing Risk in Software Projects Using Behavior Based Requirements for the 6th Annual Project Management Symposium at Jindal School of Management, The University of Texas | Dallas. If you are in the Dallas area, then please come over and participate August 16, 2012.

The symposium theme is “Project Management in a Risky World.” This presentation is targeted directly at explaining BDD for the audience, Project Managers working in waterfall environments. This is the first conference I was asked to prepare a paper to accompany the slides. You can view the Abstract, or download both the Paper and accompanying Slides.

My second presentation this month is How to Build Better Requirements with Behavior Driven Development on Tuesday, August 21 as part of the IIBA Spotlight Series Webinar. This is my first ever Webinar and I’d love to have you participating no matter where you live. This presentation is a benefit of being an IIBA member. If you are not a member, please consider joining.

 


Update: In effort to get more feedback, I am including the text of the Reducing Risk paper here. If you appreciate my kindness (saving you an extra click), then please repay me with a comment below.

Reducing Risk in Software Projects Using Behavior-Based Requirements

Jeffrey S. Davidson

Abstract

Requirements are the key to implementing the vision of a business or client. Software project failures are a significant factor to lost capital and operational expenses, lost time, and eventually lost opportunity and revenue. While project failures have been well documented, less attention is paid to the similar costs from unused and underutilized features within software projects.

With upwards of 45% of software features never used and an additional 32% rarely used it is time to pay attention to the core needs and jettison the wasted effort, expense, and code that is bogging down project success.

A key methodology in correcting this problem is Behavior Driven Development (BDD). Originally developed to help developers understand the business needs, it has grown beyond its roots and is capable of making a significant impact on curbing excess demands, requests, and gold plating.

Often seen as solely an Agile software development technique, this toolset provides insight into the core functionality of a software product and can lead to significant improvements in user experiences by removing unnecessary functionality before it becomes embedded in modern and future systems.

Introduction
Understanding the goals and objectives should be the first step of every project. In traditional project delivery, the outcomes and quality of a project stems from a firm understanding of the basics, i.e. time, scope, and cost. While each of these three may be fixed outside of the project, the final deliverables depend on how well they are understood and implemented within the project.

When discussing the success and failure of software projects, there are more references to the CHAOS Report by the Standish Group than any other metric. I want you to look at the following table and understand software projects now, and apparently always have, do not deliver on their initial objectives. Compared to their objectives, 63% of projects are challenged or fail! This number would be shocking if it was a one-time event, but it’s not. It is just the latest number in a 20-year trend line.

Table 1: Standish project benchmarks over the years[1]

Year

Successful (%)

Challenged (%)

Failed (%)

1994 16 53 31
1996 27 22 40
1998 26 33 40
2000 28 49 23
2002 34 51 15
2004 29 53 18
2006 35 46 19
2009 32 44 24
2011 37 42 21

Further, Standish goes on to claim 45% of features are never used. Jim Highsmith reports[2] this number is over 50%. Half of the functionality developed in software projects is wasted.

Forrester Research Report, “Corporate Software Development Fails to Satisfy on Speed or Quality,” (April 11, 2005) states,

Corporate development shops continue to disappoint: A fall 2004 Forrester survey of 692 technology influencers—those who hold the information technology (IT) purse strings—indicated that nearly one-third are dissatisfied with the time it takes their development shops to deliver custom applications, and the same proportion is disappointed by the quality of the apps that are ultimately delivered. One-fifth of respondents are unhappy on both counts. [Emphasis added]

The problem goes deeper though. Eveleens and Verhoef quote Standish,

“Standish defines a successful project solely by adherence to an initial forecast of cost, time, and functionality. The latter is defined only by the amount of features and functions, not functionality itself. Indeed, Standish discussed this in its report: ‘For challenged projects, more than a quarter were completed with only 25 percent to 49 percent of originally specified features and functions.’”[3] [Emphasis added]

Summarily, we have failed projects, we have significant portions of functionality sitting unused, we have unhappy executives, and we have challenged projects delivering less than half the functionality.

There are many ways to run a failed project, but only a few ways to run a successful one. Some of the recurring and significant contributors to these problems are centered on understanding the scope of the problem and solution, involvement of key personnel with the project team, and defining detailed requirements of what needs to be built.

Capers Jones, the pre-eminent expert on software quality stated,

“Although clear requirements are a laudable goal, they almost never occur for nominal 10,000 function point software applications. The only projects I have observed where the initial requirements were both clear and unchanging were for the specialized small applications below 500 function points in size.”[4]

This is the crux of why I propose the standard formats for eliciting and communicating requirements are deficient and need to be revisited. Software delivery project problems will not cease when we have a better understanding of software requirements, but we can start making radical improvements to the decrepit state of affairs in today’s projects.

 

Thinking like an investor
Chris Matts proposes there are only three reasons for developing software; making money (or expanding the organization’s mission), saving money, or protecting money, including risk avoidance or compliance dictated. Consequentially, every software development project is an investment.

Gene Kim and Mike Orzen “calculated the global impact of IT failure as being $3 trillion (US) annually.”[5] This includes $100 billion of waste just from S&P 500 companies and at least $250 billion in failed IT projects. Software delivery projects are failing.

A primary issue is many project failures is Project Managers, Business Analysts, and project teams understand the list of features to be delivered, but do not understand the project’s purpose. Many individuals are good at running calculations to determine Cost-Benefit Analysis and Return-on-Investment. Even more teams know where to find the list of features to be built and tested. What teams do not have a deep understanding of is why the business investment is being made and how the organization will benefit from it. They do not shepherd the project as if their own capital was at risk.

The truth of every software project, despite the thinking of so many of my peers, is the value of an IT system is entirely based on the expected outputs or outcomes. Systems are not built because they are esthetically pleasing or to meet the experiential design goals.[6] Rather, IT systems are built to make, save, and protect money.

Over the last decade a number of tools have been developed to assist development teams with grasping how to approach problems based on this mindset. The first of which is Feature Injection.[7]

There are three steps to feature injection:

  1. Hunt the value – Build a model based on your desired results
  2. Inject the features – Use the model to decide what features pull us toward the value
  3. Spot the examples – Use stories to find variants to the happy path and have a conversation

Step 1: Hunt the value
The value of a software project needs to be boiled down to a well-understood model. Models should be specific and targeted towards the desired business value. This value must be both clearly defined and communicated to the entire project team. Communicating specific goals and the delivery outcomes expected aligns the team with the organization.

Models require only a concise statement about the output or outcome and how this will be achieved. It does not require a significant document and can often be conveyed in a single paragraph.

Step 2: Inject the features
It is by looking at a project through the lens of what value needs to be created we can spot the features that must be added, or injected. This list of features should be only those items that pull us towards the greater value. This is not the same activity as recording a list of desirable or demanded features. Rather, this becomes a focused set of features, driving towards specific outputs defined within the model.

Step 3: Spot the examples
Examples are the real world test of what a system needs to be responsive towards. Using the steps above will find most paths to a positive output (value). This step is focused on both ensuring negative paths are understood and the system can be validated as successful. Examples become the communication tool to ensure the system is adequately built.

Of course, the unstated fourth step is to follow information smells. That is, look for gaps in understanding, particularly around the information and data being used. This step allows you to both confirm your models completeness and discover what may be missing. When you find something that may be missing, whether a feature or example not adequately covered by the existing set, repeat the above steps to fill in the hole.

 

Communicating through examples (Behavior-Based Requirements)
The second tool I want to introduce to you is a structured, natural language for learning, writing, and communicating requirements. I want to re-introduce you to storytelling.

“Storytelling is among the oldest forms of communication. Storytelling is the commonality of all human beings, in all places, in all times. ” Rives Collins, The Power of Story: Teaching Through Storytelling [8]

The oldest written story is The Epic of Gilgamesh[9], from the land of Ur. It was likely written about 2,700 BC. The actual history of storytelling is unknown. No one knows if the first stories were told to calm an upset tribal member about a sudden storm or why catastrophe occurred on the most recent hunt. No one can say the first time a story was told to explain someone else’s behavior. What we can say is storytelling evolved to give meaning and purpose.

Example: Storytelling
I want you to imagine being alive three millennia ago, when written language was rare. You live in a tribe with your family and friends. There is nothing anyone in the tribe can do to surprise you. You know everyone else too well. You have been through too much together to be very surprised by anyone. You were born into this tribe and if you had to, you would die for this tribe. You know and trust everyone else in the tribe. And they trust you.

Tonight your tribe is sitting around after a great hunt. You and your tribe have killed a bison and tonight you feast. After the feast, and the children have started to settle down, you sit around the fire. You get quiet and still, but you are excited. Expectant. Everyone knows what’s going to happen next, the tribal elder is going to start telling a story.

We use stories to communicate. We don’t communicate in facts. The tribal elder didn’t say, “Run. Many hills. No water. Throw. Parabolic arc. Dead. Eat now.”

No, the tribal said, “The winter was long and it has been many moons since our bellies were full. Yesterday we learned of a great beast, great enough to feed us all. Early this morning we woke and ran from when the sun came up until it was at it’s highest in the sky. We are so glad the beast was moving slower than Ugg runs! We were incredibly thirsty, but knew the right shot would bring us victory! Sam pulled back his arm and threw his best spear, the best throw of his life. It was amazing and now we eat like the gods.”

And the reason the tribal elder tells his stories with a setting, a sequence of events, and a conclusion, is because that is how we are wired. The human race has been telling stories around the campfire since time we first grunted at each other. The first record of telling stories may be the sons of Cheops entertained their father with stories, but we have been telling stories since time immemorial because it is what works best.

As part of a team, we need to understand and acknowledge the human species is wired to communicate using stories. To not tell stories is to deliberately hurt the chance of your teammates, your organization, and your customers understanding. It becomes simple, telling stories are good. Not telling stories is harmful.

The Wrong Focus
Our focus over the last twenty years has been to build correctly. Teams spend a great deal of money and effort to obtain and master the latest tools. Yet despite significant investments, despite significantly faster workstations, despite untold dollars spent on training, the products we deliver are barely beyond what they were in 1994.

Our focus on the building process is only part of the solution. The time has come to focus on building the right product. Gojko Adzic presents the following chart in his latest book, Specification by Example:

Chart 1: Specification by Example[10]

 

What I am proposing is stories are a key tool in a new focus, a focus on building the right product.

This is especially true when we deal with large, complex subjects. Rich Hickey recently presented “Simple Made Easy.”[11] His points are especially poignant for teams striving to make a difference with the software projects. They were:

  • We can only hope to make reliable those things that we can understand
  • We can only consider a few things at a time
  • Intertwined things must be considered together
  • Complexity undermines understanding

Building large software projects is a difficult endeavor. We needed to spend the last few decades ensuring we have the proper tools for the job. Success requires more than just tools. Success will come when we take the time and effort to enable greater understanding. Storytelling is the means to achieve this goal. Using behavior-based requirements uniformly promotes this across all types of projects. They are simply a means to capture the functionality of a system as described through fine grained, focused bits of behavior. These small behavioral examples are told in a story format, allowing easy access to readers of all kinds.

Structure of Stories
The structure for our behavior-based requirements is:

  1. Context – You and your condition
  2. Event – What action do you perform?
  3. Outcome – What is the observed response?

When writing these requirements, they should be captured using the following language:

  1. Given … (context)
  2. When … (event)
  3. Then … (outcome)

After using this technique for a couple years, I have specific recommendations for effectively writing behavioral requirements.  First, while the requirements need to be cover exact behaviors, they should be design agnostic. It is not appropriate to include language implying either user interfaces or system architectural decisions within the statements. This level of detail takes practice to master as it is typically less than included within traditional requirements, i.e., “The system shall….”

Second, the language used needs to be natural and not stilted, contrived, or technical. If you cannot get an executive, a data entry clerk, and your grandmother to understand the same sentence, you may not be writing clear enough. Read your statements out loud. If they sound more like a novel than the technical instructions for programming your electronic clock, then you are probably on the right path.

Third, the language needs to use business terms. This means the storytellers (users, executives, and subject matter experts), the people documenting the stories, and the team developing the stories will come to understand more about the business domain. This is a good thing and in keeping with delivering value over a list of features.

Fourth, amplify and reinforce the stories with testable data. For developmental and validation purposes, this proves the delivered code is correct. The story is correct. The understanding is correct.

Power of Stories
There is an underlying presumption we have both misunderstandings and unknown unknowns inherent in existing techniques. In seeking to both document those places and fill them with understanding, the practitioner asks about usage scenarios. These stories are filled with behavior and from this behavior design patterns emerge. The end result of using stories and examples correctly is a shift towards better elicitation techniques.

The simplicity of the grammatical structure belies the power this technique brings over the course of a project. Converting needs and actions to words is inherently messy. Our language is inexact and not designed to convey preciseness. Yet we need a level of precision and accuracy in our project communication. This technique allows us understand and validate finite behaviors in a large context.

This technique also encourages the discovery of what needs to be done to achieve project objectives. Using the discovered requirements throughout the project allows for the understanding project teams have been missing. No longer will one level of understanding be locked in a document team members do not read or have access.

 

Conclusion
Based on the rates of software delivery project success, your projects should already have a risk calculation around being challenged or outright failing. With a proper and universal understanding of the scope and goals, this risk will be reduced. I propose using behavior-based requirements as a key technique for achieving your common understanding, even it were to raise your project cost or timeline.

This technique is not meant as a direct challenge to the traditional requirements elicitation and documentation. Rather, this is a refinement of how requirements are drawn out and shared. This technique reduces requirements risk in a manner existing requirement structures cannot.

Using this technique we begin to literally capture conversations. And in capturing, we are sharing instead of merely interpreting. The need for business interpreters can be supplanted with understanding. The roll of interpreter and gatekeeper changes to one of communicator and bridge builder. Rather than attempting to push information uphill to a team, understanding can be shared and pulled as it is needed. Sponsors and project teams have concrete and comprehensible proof they are working towards the same ends.

 

BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.

Dan North @ Agile Specifications, 2009


[1] Standish Group, CHAOS Reports, http://blog.standishgroup.com/.

[2] Jim Highsmith, “Beyond Scope, Schedule, and Cost: The Agile Triangle,” http://jimhighsmith.com/2010/11/14/beyond-scope-schedule-and-cost-the-agile-triangle/.

[3] J. Laurenz Eveleens, and Chris Verhoef, “The Rise and Fall of the Chaos Report Figures,” 2010 IEEE SOFTWARE, Jan/Feb, pp. 30-36.

“Standish defines a project as a success based on how well it did with respect to its original estimates of the amount of cost, time, and functionality.” Eveleens and Verhoef argue CHAOS Reports measure software projects in comparison to their initial estimates and other factors. As such, they may not be accurate due to problems in the initial estimate.

This paper does not dispute problems with initial estimates, but rather presumes the sponsors of such projects expected them to deliver as promised, even if the estimates are poor.

[4] Capers Jones, Software Engineering: State of the Art in 2005, http://twin-spin.cs.umn.edu/sites/twin-spin.cs.umn.edu/files/STATEOFART2005.pdf.

Jones states large projects, “a size of 10,000 function points is roughly equal to about 1,250,000 statements in the C programming language.” Further information on estimating code based on function points may be found at: http://www.qsm.com/resources/function-point-languages-table.

[5] Michael Krigsman, “Worldwide cost of IT failure (revisited): $3 trillion” http://www.zdnet.com/blog/projectfailures/worldwide-cost-of-it-failure-revisited-3-trillion/15424.

Models require only a concise statement about the output or outcome and how this will be achieved. It does not require a significant document and can often be conveyed in a single paragraph.

Step 2: Inject the features
It is by looking at a project through the lens of what value needs to be created we can spot the features that must be added, or injected. This list of features should be only those items that pull us towards the greater value. This is not the same activity as recording a list of desirable or demanded features. Rather, this becomes a focused set of features, driving towards specific outputs defined within the model.

Step 3: Spot the examples
Examples are the real world test of what a system needs to be responsive towards. Using the steps above will find most paths to a positive output (value). This step is focused on both ensuring negative paths are understood and the system can be validated as successful. Examples become the communication tool to ensure the system is adequately built.

Of course, the unstated fourth step is to follow information smells. That is, look for gaps in understanding, particularly around the information and data being used. This step allows you to both confirm your models completeness and discover what may be missing. When you find something that may be missing, whether a feature or example not adequately covered by the existing set, repeat the above steps to fill in the hole.

 

Communicating through examples (Behavior-Based Requirements)
The second tool I want to introduce to you is a structured, natural language for learning, writing, and communicating requirements. I want to re-introduce you to storytelling.

“Storytelling is among the oldest forms of communication. Storytelling is the commonality of all human beings, in all places, in all times. ” Rives Collins, The Power of Story: Teaching Through Storytelling [8]

The oldest written story is The Epic of Gilgamesh[9], from the land of Ur. It was likely written about 2,700 BC. The actual history of storytelling is unknown. No one knows if the first stories were told to calm an upset tribal member about a sudden storm or why catastrophe occurred on the most recent hunt. No one can say the first time a story was told to explain someone else’s behavior. What we can say is storytelling evolved to give meaning and purpose.

Example: Storytelling
I want you to imagine being alive three millennia ago, when written language was rare. You live in a tribe with your family and friends. There is nothing anyone in the tribe can do to surprise you. You know everyone else too well. You have been through too much together to be very surprised by anyone. You were born into this tribe and if you had to, you would die for this tribe. You know and trust everyone else in the tribe. And they trust you.

Tonight your tribe is sitting around after a great hunt. You and your tribe have killed a bison and tonight you feast. After the feast, and the children have started to settle down, you sit around the fire. You get quiet and still, but you are excited. Expectant. Everyone knows what’s going to happen next, the tribal elder is going to start telling a story.

We use stories to communicate. We don’t communicate in facts. The tribal elder didn’t say, “Run. Many hills. No water. Throw. Parabolic arc. Dead. Eat now.”

No, the tribal said, “The winter was long and it has been many moons since our bellies were full. Yesterday we learned of a great beast, great enough to feed us all. Early this morning we woke and ran from when the sun came up until it was at it’s highest in the sky. We are so glad the beast was moving slower than Ugg runs! We were incredibly thirsty, but knew the right shot would bring us victory! Sam pulled back his arm and threw his best spear, the best throw of his life. It was amazing and now we eat like the gods.”

And the reason the tribal elder tells his stories with a setting, a sequence of events, and a conclusion, is because that is how we are wired. The human race has been telling stories around the campfire since time we first grunted at each other. The first record of telling stories may be the sons of Cheops entertained their father with stories, but we have been telling stories since time immemorial because it is what works best.

As part of a team, we need to understand and acknowledge the human species is wired to communicate using stories. To not tell stories is to deliberately hurt the chance of your teammates, your organization, and your customers understanding. It becomes simple, telling stories are good. Not telling stories is harmful.

The Wrong Focus
Our focus over the last twenty years has been to build correctly. Teams spend a great deal of money and effort to obtain and master the latest tools. Yet despite significant investments, despite significantly faster workstations, despite untold dollars spent on training, the products we deliver are barely beyond what they were in 1994.

Our focus on the building process is only part of the solution. The time has come to focus on building the right product. Gojko Adzic presents the following chart in his latest book, Specification by Example:

Chart 1: Specification by Example[10]

 

What I am proposing is stories are a key tool in a new focus, a focus on building the right product.

This is especially true when we deal with large, complex subjects. Rich Hickey recently presented “Simple Made Easy.”[11] His points are especially poignant for teams striving to make a difference with the software projects. They were:

  • We can only hope to make reliable those things that we can understand
  • We can only consider a few things at a time
  • Intertwined things must be considered together
  • Complexity undermines understanding

Building large software projects is a difficult endeavor. We needed to spend the last few decades ensuring we have the proper tools for the job. Success requires more than just tools. Success will come when we take the time and effort to enable greater understanding. Storytelling is the means to achieve this goal. Using behavior-based requirements uniformly promotes this across all types of projects. They are simply a means to capture the functionality of a system as described through fine grained, focused bits of behavior. These small behavioral examples are told in a story format, allowing easy access to readers of all kinds.

Structure of Stories
The structure for our behavior-based requirements is:

  1. Context – You and your condition
  2. Event – What action do you perform?
  3. Outcome – What is the observed response?

When writing these requirements, they should be captured using the following language:

  1. Given … (context)
  2. When … (event)
  3. Then … (outcome)

After using this technique for a couple years, I have specific recommendations for effectively writing behavioral requirements.  First, while the requirements need to be cover exact behaviors, they should be design agnostic. It is not appropriate to include language implying either user interfaces or system architectural decisions within the statements. This level of detail takes practice to master as it is typically less than included within traditional requirements, i.e., “The system shall….”

Second, the language used needs to be natural and not stilted, contrived, or technical. If you cannot get an executive, a data entry clerk, and your grandmother to understand the same sentence, you may not be writing clear enough. Read your statements out loud. If they sound more like a novel than the technical instructions for programming your electronic clock, then you are probably on the right path.

Third, the language needs to use business terms. This means the storytellers (users, executives, and subject matter experts), the people documenting the stories, and the team developing the stories will come to understa

Drawing Hands by M. C. Escher

Greatness Comes from Showing Pictures

As far as I’m concerned there are three skills a BA must learn to be great.

  1. How to ask questions
  2. How to explain concepts graphically
  3. How to tell stories

Everything else, and there is a lot to the everything else, takes second place to these three things. The first item is vital because it’s how you learn. The second two are vital because it’s how you should share what you have learned.

We deal in complex ideas. They are not simple. I regularly quote from Rich Hickey’s presentation to StrangeLoop 2011, Simple Made Easy. Rich discusses how difficult it is for us to really grasp multiple, interrelated concepts at the same time. As Business Analysts, this is exactly our job; to communicate multiple, difficult, interrelated concepts (MDIC).

And communicating MDIC needs more than just another document. It’s not that we don’t write a lot of documents, we do. (Yes, story cards are a document.) More important than the document is the understanding. And understanding MDIC doesn’t come best or easiest via the written word. If you want to build understanding, then you need to communicate based on how your audience will best understand. Being human, the best ways to get through to your audience is by pictures and stories.

With pictures (graphics) I see and understand relationships, order, hierarchy, proportion, and all kinds of other things. If the picture is good, I can do this is less than 10% of the time it would take me to read words describing the same thing. If it’s really good, I can do this in less than 5% of the time.

Now, it sometimes takes me 10-20 times longer to develop the right picture, so there are tradeoffs depending on the role and size of your audience, but never underestimate the importance of a good image. If you work with MDIC, you probably need a picture, or twenty.

 

If you are ready to improve your skills in this area, I suggest looking at the following resources:

  1. Visual Models for Software Requirements. Much of what I know about requirements gathering I learned while working with authors, Joy Beatty and Anthony Chen.* Find excerpts here and here.
  2. The Back of the Napkin: Solving Problems and Selling Ideas with Pictures and Unfolding the Napkin: The Hands-On Method for Solving Complex Problems with Simple Pictures, by Dan Roam. His first book was an instant hit because it was provided thought-provoking concepts about why to use drawings and how determine what type you need.  I have not read his follow-up book, but some reviewers like even more.
  3. Anything by Edward Tufte. Seriously, I love all his work. I hesitate going to his website because I can easily loose a day there.
  4. More infographics than explanatory, but I also like Show Me the Numbers: Designing Tables and Graphs to Enlighten by Stephen Few.
  5. Visual.ly. Hundreds of great infographic examples. A good resource when you need a leaping off point for your idea.

* Author’s Note: I heartily recommend their book even though I do not yet own a copy. One, I have that much faith in them. Two, I am waiting to get a signed copy of the book.  

 

What books and resources would you add to my list? Please let me know below!

dealwithit

Is Agile Just for Developers?

Are you a scrum master, coordinating with another team? You might be told, “Why isn’t that done? It should be ready by now.” 

Are you a business analyst, talking about a change that doesn’t impact today’s stories? You might be told, “Don’t mention it during the stand-up meeting.” 

Are you QA, trying to determine if this is a bug or not? You might be told, “Don’t you see the developers are busy? Why did you interrupt them while they were coding?”

And so on.

It’s an epidemic. Agile developers treat their non-dev teammates as part of their personal fiefdom, there to serve. Preferably quietly, so you don’t interrupt their thinking while they are developing. And woe unto those who are not present when called upon.

Developers are the gravitational center of the team. Everyone and everything revolves around them. For the last 5 years I’ve been saying, “Agile is methodology by developers, for developers.” I’ve been watching this behavior for years. It’s irritated me for years. But is it wrong? Should developers be the center of a team’s universe?

Picture of Andromeda Galaxy taken by Hubble Telescope

 

Where’s the value? 

First, we need to agree on a basic metric. The only time software is valuable is after it has been delivered to the users. Software sitting in on personal workstation doesn’t add value to a business or consumer. Software waiting for the next release cycle isn’t providing anyone any value. It might be “done,” but it’s not giving anyone any benefits until it’s used.

I’m a business analyst. It’s incredibly important to understand the business goals when you’re building software. A good scope document doesn’t add value. Detailed specifications don’t add value. Designs and tests and servers do not add value, either. Only working software—working in the hands of users—has a chance to deliver value.

 

Theory of Constraints (link)

If working software is the primary measure of how we add value (See Agile Manifesto Principles), then we need to organize the software development process to get more software out the door. How do we do that?

Eliyahu Goldratt, a physicist who became a management guru, noticed manufacturing lines were organized to maximize the use of all the machines. This was making accountants happy, but it caused problems with extra work, waste, and a growing warehouse full of partially completed products. Goldratt determined manufacturers can make more money by organizing their production lines for consistent throughput around the bottlenecks (constraints).

The same problems, and solution, affect software development. Agile provides a set of tools for software projects, optimizing for the bottleneck, developers. Keeping developers focused leads to a more productive team. Optimizing for developer throughput (for example, having BAs and QAs nearby to answer their questions) means working software is delivered sooner. Optimizing for developers means you increase the chance real value will be delivered. Because the real value of software comes only after it’s delivered, it makes sense to be organized around developers.

 

What about other bottlenecks? 

The truth is, processes have more than one bottleneck. After you optimize for the first bottleneck, you need to be ready to discover the next one. It takes diligent focus to watch the process and work on the next bottleneck. You cannot stop at the first one; bottlenecks are everywhere and you need to continue to watch and optimize.

Developers, because of their role, have a huge number of bottlenecks. They need the right level of requirements, properly configured workstations, the right tools, a good environment for checking in their code, time to understand the technology stack, available test systems and data bases, automated tests, and so on. If you are on a project long enough, you may find this list whittled down. I have never seen it eradicated, but I have seen it get pretty small.

 

What’s right?

Unfortunately, and I think this was part of my ongoing frustration, teams are not good at optimizing for other parts of the process. I’ve been parts of teams where the biggest bottleneck isn’t with supporting the developers, it’s with the testing or requirements supporting development. It’s not that teams cannot say, “I see you need help over there.” Rather, they seem to acknowledge the problem and then think it will go away.

Agile is right. Organizing your team for consistent throughput of working software provides the most value to customers. Supporting developers leads to better software, quicker. It’s the teams that are failing the process. When your team has a problem, discuss it. Work on it. Eliminate it.

Agile isn’t just for developers, but it will be if you don’t pay attention.

 

Do you agree, is this the right way to develop software?
Do you think it’s a problem? Why? Please leave your comment below.

Measuring Requirements May Reinforce Bad Behavior

Have you ever heard this phrase?

“What gets measured, gets done.”

It contains huge truths about human nature, or at least my nature. I pay more attention to something when someone else is paying attention to it. I didn’t have to study the Hawthorne Effect to know this. Looking at my own life, there are lots of examples where if the boss was looking, I did my stuff. Where they didn’t care to look, I soon learned it was safe to ignore this area. And I often did.

More relevant to being a Business Analyst, I was brought into one company to train their new BAs. We spent lots of time covering the basics and then we started working on projects. The documentation was very uneven between the BAs (including me), so I said “Everything has to be peer reviewed before it goes out of the team.” And within a couple months everyone was writing great requirements. Really great. A couple months later, after we had stopped our internal reviews, the clarity and readability of our documentation was in the toilet. We had fallen back to our old habits. Just knowing a peer was going to review our work led everyone to do better work. There is no doubt in my mind, measurement and feedback can and do improve performance.

Unfortunately, most requirement metrics don’t help a BA, a project, or a team. They hurt it.

Typical Requirement Metrics

Measuring requirements can be difficult. Here’s a list of easy-to-gather requirement metrics:

  • Quantity (of use cases, requirements, user stories, process flow diagrams, etc.)
  • Volatility due to scope changes
  • Volatility due to technical & design changes
  • Volatility due to missed requirements
  • Volatility due to changes to existing requirements
  • Volatility due to clarification required
  • Defects due to requirements
  • Schedule variance due to poor or missing requirements
  • Tool compliance
  • Process compliance
  • Comparisons of the above versus:
    • initial estimates or baseline
    • time
    • project phase
    • project size
    • scope

These metrics have a couple elements in common. First, they are relatively easy to measure and calculate, presuming you have the right tools in place. I think many requirement management systems have been sold because for the first time companies will have metrics about requirements! Second, they all help ensure a team is builds correctly and in accordance to the original vision of the product.

Value?

I think it is important to ask, “How do these measurements benefit a team or project?” When I look at the above metrics, the focus seems to be on comparing requirements from one phase to the next, from how well did we understand the needs at the beginning of the project to how what was built at the end, to ensuring the process was followed. These all help teams “build right.” Which is important, but I think it is significantly more important to ask if the team is building the “right product.” Take a look at Gojko Adzic‘s chart from Specification by Example:

This chart describes my very real concern about requirement metrics. They help us build right. They help us ensure everything is checked-off the list, but none of the metrics push us to break the mold and build something great. They help us build something we planned months ago. I want to reinforce BA behaviors that push us to ask hard questions, pushing us up the value stream. I want us willing to take a new direction because we can see a project could be better. We should love killing projects because the value has already been reached, or never will be.

Behavior Reinforcement

If you want to improve teamwork, you need to reinforce behaviors that support acting like a good team member. If you reward people based on individual behavior, you are undermining the goal of improving teamwork. Similarly, it’s not uncommon to find metrics being misused. Sometimes the problem is minor, metrics are unused and the only impact is the wasted effort to gather and analyze them. Other issues include inappropriately punishing a team because of metrics and unintentionally focusing more on metrics than on delivering business value. None of these are part of the initial goal when a company or team decides to track information, but they are pretty easy to find.

Better choices

When you have to measure requirements, the first thing I want measured is their quality. First, define what a quality requirement ( or use case, or user story, or . . .) looks like. Then audit everyone against the standard. This ensures the quality of what BAs produce stays high. If your team is currently using a different style, template, or process for every project, this step will also push for more process compliance.

In a similar vein, I encourage teams to ensure everything goes through a peer review. I’m not sure metrics around this are especially valuable, but it might help with enforcement.

Lastly, think about the dimensions in Gojko’s chart above. Think about what’s really makes a difference. Fellow ThoughtWorker and Agile Manifesto signatory, Jim Highsmith has a great talk on this and often discusses with executives interested in enterprise agility. You should read his post and learn more about the most important metric of all, delivered value.

 

iStock_000014958717XSmall

Presenting this week!

Our speaker at this week’s IIBA Dallas Chapter meeting is very ill. With only 48-hours, it’s not much time to get a new speaker, so I will be presenting! Please come on over this Thursday to hear me present on Feature Injection and Behavior Driven Development (BDD).

 

Unleashing the Power of Behavior Driven Development

Thursday, March 15, 2012 6PM
IIBA Dallas Chapter; Hosted at BravoTech
4835 LBJ Freeway, Suite 1000, Dallas
(NW corner of Dallas North Tollway and I-635)
Cost: $10  Includes food

There is a special place where the hidden treasure of great requirements are found. It’s not that what we have today is bad, but it’s time to move beyond writing stodgy requirements no one else is willing to read. Diagrams are great for communicating, but most of the time you need more than just pictures. And user stories a really good step forward, but many of us find they are still missing something.

The secret may lie in Behavior Driven Development (BDD). The fabulous thing, besides the cool name, is this is easy to learn, easy to use, and produces better stories, requirements, tests, and code!

This presentation is for analysts who already know how to right requirements, but want to move to something more productive. This is an introduction to a new technique, using natural language to describe both the value and features of a system and each interaction.

Come learn about writing requirements and acceptance criteria in business language (for your customers) that are clear and complete (for your developers) and super-duper easy to double-check (for the testers)!

Learning Objectives:

  1. Understand the fundamentals and benefits of Behavior Driven Development
  2. Learn how to write better requirements & acceptance criteria using natural language and business terms
  3. Tap into the power of permutations to ensure test cases are complete.

BABOK Alignment:

  • This talk aligns with the Agile Extension to the Business Analysis Book of Knowledge (BABOK).
  • See: Chapter 4: Techniques / Get Real Using Examples (pp. 81-84)

About the Speaker:

Jeffrey DavidsonJeffrey Davidson, Certified Scrum Product Owner (CSPO), Certified Product Manager (PMC)
Principal Consultant, ThoughtWorks
President, IIBA Dallas Chapter

Jeffrey Davidson is a Principal Consultant with ThoughtWorks, a leading Agile development firm with a passion to improve how businesses design, build and evolve software. He also serves as President of IIBA Dallas Chapter.

Jeffrey is a consulting Business Analyst, Mentor, Coach, and Trainer. An engaging and entertaining speaker, Jeffrey speaks with passion to audiences across the country on business analysis and agile development.

Jeffrey has had many titles, including Director of Business Analysis & Quality Assurance for UTI, Business Analyst for Dell, Systems Engineer for Raytheon, and Product Manager for Ebay. He is a Certified Product Manager (PMC) and a Certified Scrum Product Owner (CSPO).

Jeffrey’s focus is helping organizations and Business Analysts transition to Agile, delivering great requirements, and building world-class analyst teams.