Agile Coaching

BDD in a Nutshell

On Friday I was talking to Katie, she works in a department where teams are trying to apply Behaviour-Driven Development (BDD). She hasn't been on Matt Wynne's BDD training workshop yet and is looking for some background reading to explain what it's all about. So I've put together this blog to explain what BDD is and pull together some links for further reading.

What is BDD?

The B in BDD stands for Behaviour, the desired behaviour of the software to be developed. The DD part stands for Driven-Development. BDD is an approach for building a shared understanding on what software to build by working through examples.

I've drawn this basic sketch to illustrate the basic idea.

BDD is pretty simple, describe what you want the system to do by talking through example behaviour.Work from the outside-in to implement those behaviours using the examples to validate you're what you're building.

You don't have to bring the whole team together but it helps to get different perspectives to flesh out the examples. The customer (who may be a Scrum Product Owner) describes what they want and the developers ask questions to flesh out enough detail about the behaviour to be able to implement it. If you have business analyst or quality assurance specialists then they can help tease out details of different scenarios.

Like TDD but more

The examples are often turned into automated tests and BDD practice follows the same basic idea as Acceptance Test-Driven Development, where acceptance tests are elaborated for each user story and automated as the software is built. Matt Wynne says "BDD is basically TDD done properly."
 
BDD is more than TDD because it focuses on collaborating with business people. Dan North, who originated the BDD moniker, noticed that business people switched off in conversations about "tests" as these seem to be too technical. He hoped that framing conversations about "behaviours" would be a way to engage the whole team.

Ubiquitous Language

To make sure that the whole team understand what's wanted, we describe the behaviour in non-technical language. We're careful to use names that reflect the ubiquitous language used by business people, a basic principles of Domain-Driven Design as explained by Eric Evans and summarised in Domain-Driven Design Quickly.

Ultimately BDD is about building a shared understanding, you're doing BDD wrong if the only people who read the examples are the developers. I have seem this implementation in a few places, see pic below. BDD is much more than a way of automating tests and if that's all you have in mind then a unit-test framework might given you a faster suite of tests.

Inspirations of BDD

BDD was originated by practitioners of eXtreme Programming (XP) who were looking for a way to involve all perspectives (including BA and QA) in conversations about what to build.

Much credit has to go to Ward Cunningham, inventor of the wiki and many XP practices, who in 2003 developed a testing framework called FIT that enabled business people to specify tests in tables using spreadsheets. Around the same time, Brian Marick, was writing about expressing tests as examples.

Tooling to support BDD evolved initially in JBehave with Liz Keogh as an active contributor and later with Cucumber.

What BDD is not

BDD is about figuring out what to build that helps flesh out behaviour. BDD isn't an Agile framework or project management approach. Teams using Scrum or Kanban with BDD will need to figure out what to put in their backlogs and boards for planning purposes. You might want to measure the number of BDD scenarios delivered instead of velocity but often these scenarios are too fine-grain for release planning purposes.

Further Reading

Websites:

• Wikipedia

• http://behaviour-driven.org/

• http://dannorth.net/introducing-bdd/

Books:

• "The Cucumber Book:Behaviour-Driven Development for Testers and Developers" Matt Wynne and Aslak Hellesøy

• "Specification By Example: How Successful Teams Deliver the Right Software" by Gojko Adzic

• "Fit for Developing Software: Framework for Integrated Tests" by Rick Mugridge and Ward Cunningham

• "The RSpec Book: Behaviour-Driven Development with RSpec, Cucumber, and Friends" by David Chelimsky, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, Dan North

Articles:

• Virtual Panel: Specification by Example, Executable Specifications, Scenarios and Feature Injection
• The Three Amigos

Please add comments to point to further resources. Thanks!

When To Write Story Tests

Thanks to Paul Grenyer for asking me (and Allan Kelly) about when to write story tests. He's not the first person to ask me about this so thought I'd share my advice with you here.

I believe that part of the confusion about when to write tests for user stories comes because people tend to jump into talking about "tests" too quickly. There's a subtle difference between Acceptance Criteria and Acceptance Tests but often these terms are bandied about as meaning the same thing.

Liz Keogh has an excellent blog post on Acceptance Criteria vs. Scenarios where she explains that acceptance criteria are general rules covering system behaviour from which executable examples (Scenarios) can be derived. In his book "Agile Estimating and Planning", Mike Cohn calls these rules "Conditions of Satisfaction", you can simply list these as bullet points on the back of story cards. As Liz points out, you can uncover acceptance criteria by having conversations with your stakeholders about example scenarios. So acceptance criteria and example scenarios are a bit like the chicken and the egg - it's not always clear which comes first so iterate!

In contrast, acceptance tests are basically scripts - manual or automated - that detail specific steps to check a feature behaves as expected. You don't need to write out all of these tests in order to plan the next iteration. Instead, you can use acceptance criteria to clarify the scope of each user story, so the team understands just enough detail to agree on what to work on in next iteration. You can also use acceptance criteria to split "epic" stories - optional or nice-to-have acceptance criteria may be bundled into later stories.

So when do we write the acceptance criteria? Well, the whole team can get together, to flesh out the user stories with acceptance criteria, as part of iteration planning but this can take a while. Larger or distributed teams may prefer to do this activity before the planning meeting - a trio of customer, developer, and tester is usually all you need.  If you work this way, remember to review the acceptance criteria with the whole team before committing to delivering a story in the next iteration.

Now we get to when to write the tests. Acceptance test scripts can be written in the same iteration as the code, before or in parallel with developing the code. If you're lucky your customer has time to sit down to do this with you or perhaps a developer and tester paired together can do this. Remember to check with your customer that you've captured the intent of the user story before going ahead and implementing the code.

Of course, I'm not suggesting that you write all of the acceptance tests for all the stories at the beginning of the iteration. Just that when work starts on a story, the first thing to do is to get really clear about what tests should pass - following an Acceptance Test-Driven Development approach - this can be done by writing one acceptance test at a time or the whole set for the story.

Summing up, explore acceptance criteria and example scenarios as part of planning and write the tests close to when you write the code. Please do post any further questions and suggestions as comments.

Defining What Done Means

Often I get called in to coach teams who have been trying to implement Scrum and are struggling to deliver on their commitments by the end of the sprint.They agree what features should be possible to get done but somehow things don't go to plan. It looks like the problem is testing but there's more to it than that. Well-known agile expert Jeff Patton illustrates the underlying reality using the following picture. He used this sketch in support of arguments people use for going to a Kanban style approach ( which also focuses teams on what Done means).

One source of the pain is that team members lack a shared agreement on what quality level they're aiming for. Some programmers may be writing automated unit tests, others may delivering code without checking it works. Some testers may talk to programmers as soon as they find problems, others may spend a lot of time filing length defect reports. Soon a blame game starts.

Instead, if we establish a shared "Definition of Done", we have a better chance of understanding what needs to happen during the sprint to get the features properly ready ("Done-Done").

That sounds fine and dandy but just how do we go about creating a such a definition of Done in our team? Here's some simple steps that you can try:

1. Surface the current practice (Always, Sometimes, Not Yet)
2. Discuss what Definition of Done what feels practical for the team
3. Resolve any puzzles and concerns before putting into action
4. After a couple of weeks, repeat from step 1.

I've posted some pictures below from a conversation with five developers in a small non-profit organisation to show you what this looks like.

Step one is to invite everyone in the team to write sticky notes about what they do now. Expect to get some duplicates. You'll also find that there is some discussion about which category the notes should go in. Most often these debates are resolved by putting the notes into the Sometimes category (if it really is Always or Not Doing then why the debate?). 

It's now clear to the team that they have a pretty minimal test strategy and also that people on the team have different assumptions on what needs to be done. No wonder there's confusion. Now it's time to turn the conversation to working out a basic definition of Done that they can start using starting tomorrow. Help the team get clear what each proposal means to them and whether they are really ready to do this yet? It best not to be too ambitious, remind them that they can improve it over time.

The team decided to explore this basic proposal for a new definition of Done.

Then we explored what this would actually mean for the team. We needed this become a shared working agreement that every team member was happy to implement. So you may be surprised to hear that we didn't vote on it. Instead, we worked towards consensus by checking for concerns.The pink notes represent each element of Done. The green notes are questions and concerns from the team. We put these in two columns "What we do.." elaborating detail about what this means (who/what/when) and "How we check it's being done" about making this activity visible.

Don't forget that step 4 is to review how the new definition of Done worked for the team. Agree a date when this will happen by, a natural point is the next retrospective but the team may prefer to wait longer to allow the new approach time to bed in.

Hopefully, you find these tips useful. Please do add your own suggestions for other ways of how to do this as blog comments below. And, yes, I know that there's more to a test strategy than establishing a definition of done :-)

Building a Transition Backlog

When we start work with a new team, we bring a fresh pair of eyes. We see many things that we'd like to improve and many problems to be addressed. Part of our job, as an agile coach, is to help the team to bring these opportunities and challenges into focus. Now we can work with the team to implement solutions that mesh well with the organization / context they find themselves in. In this blog, I want to share a technique that I use with teams to surface driving forces and barriers to an agile transition so together we can work out the most effective place to put our energy.

The basic technique is called "Force Field Analysis" and is derived from the work of social psychologist, Kurt Lewin. Though I learned about this technique from Esther Derby and Diana Larsen's book, "Agile Retrospectives." Where I've added a twist is that I use the information from a force-field chart mapped out with the team to generate an initial Transition Backlog of work items supporting an agile transition that coaches and teams can work through iteratively. Mike Cohn gives some excellent advice on how to work with Transition Backlogs in his new book "Succeeding with Agile" (see his blog for some basic pointers).

Mapping out a Force Field

Let's see how to assemble an force-field analysis chart with your team. To start, find a big surface to draw the chart upon such as a whiteboard or flipchart. Bring along plenty of markers and sticky notes so you can get the whole team involved in building the picture of forces in play.

As we encourage teams to tune up their practices, we understand that being Agile is usually not the real goal. Often there's an underlying improvement focus within the organisation that has lead the team to adopt an agile approach. Whilst we value the attitude of reflection on current practice and continuous improvement elements of agile approaches, we don't want to lose sight of the desired improvement.

Step one of drawing a force-field analysis chart is to identify the desired improvement and draw a big arrow at the top (from left to right) that represents the change from current state to desired state. Although this could be "Go Agile" it may be better framed as "Deliver Software More Frequently" or "Reduce Time Spent on Defects".

Now, divide the chart into two equal sized columns. The left-hand column is used to list out the driving forces for the change summarized in the big arrow at the top. For example, "Management support" or "Budget for training". The right-hand column is used to list out the restraining forces. For example, "Company hiring policy" and "Teams are too busy".

Encourage the team to contribute their ideas for forces at work on sticky notes. For each force identified, draw an arrow pointing to the dividing line between the columns. Use line thickness to indicate the strength of the force (see example from a training class below).

Generating a Transition Backlog

When the team is happy that the force-field chart adequately represents the forces in play, it's time to consider how you can amplify the driving forces and reduce the restraining forces. Each action that you can identify is a candidate for a "transition backlog" that the coach and the team can use to focus their efforts on changes that will move them toward their desired end state.

You can now use the chart to ratify your current coaching strategy by walking through it with key stakeholders and getting their take on the priorities of the items in your initial transition backlog. Senior stakeholders may add additional forces to the chart. Their buy-in is often crucial as you may need their support to help escalate impediments to the agile transition. 

Slicing and Dicing Epic User Stories

Today I ran a workshop ideas to explore how to slice epic-sized user stories at Redgate in Cambridge. I'm going to share some of what we covered with you in this blog.

In my work as an agile coach, I find many teams applying Scrum are puzzled about user stories. I guess one reason is that this technique is from XP and so these teams may be missing some of the background. In "Planning Extreme Programming" by Kent Beck and Martin Fowler stories are defined simply as,

"We demonstrate progress by delivering tested, integrated code that implements a story. A story should be understandable to customers and developers, testable, valuable to the customer and small enough so that the programmers can build half a dozen in an iteration."

So there's no perfect size for a user story, it depends on the length of your iteration, the speed at which you can get software built and tested, and what your customer considers valuable. It often takes a few iterations for a team starting on a new project to work some of these factors out. But it should be possible. When I hear teams claiming that they cannot identify any slices that can be built and tested in a couple weeks, I suspect that they may not be challenging assumptions about how stories can be sliced and diced. Although sometimes teams do experience this where they are working on a very fragile codebase.

In the workshop, we split into groups of three people (which works well for conversations about use stories) and all worked through a prepared example with the aid of a cheat sheet I put together.

Rachel's Cheat Sheet for Splitting Epics

Remember you are looking to develop slices of the problem that produces valuable working software with the potential to generate feedback from users. Sometimes the story slices are not deliverable to end-users but they generate value from the learning gained in producing them. They should all result in testable and demonstrable software. Consider applying the XP principle DTSTTCPW (“Do The Simplest Thing That Could Possibly Work”)

Consider the following approaches:

What are the different ways that you can handle input/output data ?
•    You can make a story per input screen.
•    You can make a story per enabled elements of an input screen.
•    You can make a simple (not pretty) UI.
•    You can make a command line interface.

What scenarios are in scope for acceptance criteria?
•    You can work with a subset of the input data.
•    You can defer conditional steps to other stories.
•    You can defer data validation.
•    You can defer error handling.

What architecture decisions can be deferred?
•    You can defer optimisation of performance.
•    You can defer internationalisation
•    You can defer handling large volumes of data.
•    You can hard-code data rather than getting from the real source.
•    You can stub out components.

This is not an exhaustive list! Be creative in your story splitting approach.

More Slicing Ideas

In the workshop, we also added the following ideas for slicing (see photo).

I hope that some of you find these ideas useful. Please comment on this blog with alternative ideas for slicing and dicing epic stories.

Building Trust on Agile Teams

We explain some techniques for building trust on agile teams in our Agile Coaching book. However, I continue to explore this topic, as I believe it's essential for agile coaches to master.

As an agile coach, you want to build trust with the people on the team you are coaching. You also want to improve trust between individuals on the team (which is hard to do if the team doesn't trust you yet). This blog shares my latest thinking on how you can help encourage trust to grow in different situations.

Since our book was published, I ran two workshops on "Trust & Project Culture" at XPDay and XP2010 conferences with Sallyann Freudenberg. Our focus in these workshops is how can we boost factors that improve trust and dampen those forces working against trust. Here are a couple of force-field charts from our workshops so you can get an idea of what those factors might be.

The Trust Equation

In preparing for our workshops on trust, I dug out a copy of "The Trusted Advisor" from my bookshelf.  This is an excellent book by David Maister, Charles Green, and Robert Galford. It contains a useful formula that neatly captures aspects of our interactions relating to whether we are seen as Trustworthy:

T = C + R + I / S

The letters in this formula stands for,

Trustworthiness = Credibility + Reliability + Intimacy all divided by Self-orientation, where:-

• Credibility relates to expertise. An essential element in trust is having faith that the person I am placing my trust in has the skills and knowledge to meet their commitments. We lose credibility when we stretch the truth and claim to be capable in areas that we don’t have experience.
• Reliability relates to organizational skill to get the work done. I need to be confident that I can depend on a person doing what they say in a timely fashion to a proper standard. Essentially, we lose damage trust if we don’t meet our promises.
• Intimacy seems to be an odd factor to weave into an equation. Clearly, this doesn’t refer to physical intimacy, it represents the degree to which another person cares about the others needs. Where we appear aloof and detached from the situation and our team mates, we find a lack of openness and trust.
• Self-orientation detracts from trust because we’re more cautious about people who put themselves first. We fear they may not be committed to shared goals and may sabotage our efforts in favor of their hidden agenda.

Remember these, when you're introduced to a new team. Take care to build credibility by relating your experience with other teams without exaggerating. Make commitments that you can keep and follow up on them. And take time to get to know the team and their goals, explaining that you are there to support them.

We can also help the teams that we coach to improve trust by working on these same aspects. First, let's look at how these factors relate to teamwork.

Factors Blocking Trust

As an agile coach, you already know agile software development is a co-operative game, teamwork is essential. But when thrown together, people often hang back from working closely together as a team; they're reluctant to depend on their team mates and to allow time to share work with others. In this situation, if we try to apply the trust equation, we have low C, R, and I with high S, no trust exists between team mates or managers. People actively minimise interactions preferring to follow the adage "If you want a job doing then do it yourself!"

Watch an team of amateurs playing soccer and you'll see something similar. Players won't pass the ball to those who they don't believe have the skill to handle it. You'll also notice players who hog the ball, retaining possession rather than pass to a team mate who's better placed to score. The team may win a game because of their star player but if he gets injured then the team struggle to play their usual game. What's going on here? Simple, where there are mixed abilities on the team that affects how they collaborate. People also like recognition for their unique skills. The same is true with software teams.

What's going on when people avoid close team work? Well, I'm sure you notice that developers often find it natural to divide up the work to suit each persons skills and then work independently. As we each develop deeper knowledge of our chosen specialist area, we become comfortable with that kind of work and tend to look for more of the same. Why? We like this because we feel safe when we know what we are doing. We also don't have the overhead of explaining what we are doing to anyone else working on the same thing, which feels more efficient. We may even kid ourselves that it would compromise the team's chance of success by allowing team members with less experience to try their hand at something new. And we nicely side-step the risk of exposing our competence at the task in hand to anyone else.

However, there's a downside to specialising in this way. Work does not arrive at an even rate for each skill area and this causes bottlenecks. I'm sure you'll have seen teams where the UI guy is overloaded while the DBA is waiting around for work. The Agile antidote to this situation is the "cross-functional" team. Basically, we have to step outside our comfort zones and expand our skills so we can handle whatever is thrown at our team. Of course, it's unlikely that everyone can become an expert in all the different types of work the team takes on, some specialisation will continue. What's usually required is each team member expands the range of tasks that they can complete proficiently enough to ease skill bottlenecks.

There's a big wrench to let go and pitch into other types of work, to allow team members with less experience to try their hand at something new. People tend to be nervous, as doing so can slow the whole team down while people learn new skills (the team may lose trust from management as their 'R' factor appears to drop). To speed up this learning, everyone must be ready to ask for help. Often, reluctance to admit that we don't have all the answers (as we might lose face) is what blocks this is lack of trust in teams.

In his book "Overcoming The Five Dysfunctions Of A Team" Patrick Lencioni explains that trust is all about vulnerability, 'Team members need to be comfortable being exposed to one another, so that they will be unafraid to honestly say things like “I was wrong,”  “I made a mistake,” “I need help,”  “I’m not sure,” “you’re better than I am at that,” and “I’m sorry."'

Getting over this may be difficult in low-safety situations, such as where people risk losing their jobs or have individual performance targets rather than shared team goals. One way you can coach teams in this is to be the first to ask the dumb questions. You act as a role model, demonstrating that it is safe to expose your ignorance in order to learn better. You can also support the team's learning by organising study sessions, such as Coding Dojos.

Techniques for Building Trust

So, as agile coaches, what other techniques can we use to build trust on software development teams? Do physical exercises where we practice falling backwards into the arm's of the team or put on a blindfold help? Can we really develop trust though exercises of forced reliance where we let go and trust the team will take care that we don't get hurt?  I don't know but Lencioni suggests that the answer lies in taking time to get to know each other better (improving the 'I' factor in the Trust Equation). This can be accelerated by exercises, such as sharing personal histories and comparing personality profiles (like MBTI, Belbin, etc). You can also work on this by creating more opportunities for team members to get to know each other more naturally through regular social time, such as team lunch on Wednesdays.

We can also work on the 'R' factor from the Trust Equation. Early steps in building a relationship of trust with new suppliers is drawing up contracts to make explicit the responsibilities of each party. You can try the same approach on software teams. Facilitate the creation of team working agreements or a team charter to make team norms and values explicit. If you create team working agreements in a workshop near the start of the project take time to document them somewhere (on a wiki page or flipchart in the team workspace) so that the team keeps them in mind. Notice where working agreements are broken and revise them through retrospectives, as the project goes along.

More on Building Trust

Sallyann and I will be running our "Building a Culture of Trust" workshop again at Agile Business Conference in October. We hope to see you there. I'll also be giving a keynote on "Building Trust in Agile Teams" at Agile Cambridge the following week. If you can't come to those events, you can listen to a talk I gave "Improve Collaboration, Build Trust" via video from Skills Matter and look out for my upcoming article on building trust for Cutter Consortium.