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 a methodology, 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/

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.

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.

Building an Agile Environment

My favourite Agile Manifesto principle is "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

As coaches, we naturally work with people helping them form cross-functional teams and install agile practices that drive iterative product development. How many of us throw our energy into improving the environment that people work in? Yes, most agile coaches know how important it is to setup a visual workspace, with cards on a board in the team space, as Xavier illustrates so well on his Visual Management blog. What more can we do?

In the first edition of "Extreme Programming Explained", Kent Beck exhorts us to "rearrange the furniture" to make team working and pair programming possible. Keith Braithwaite reminds us at QCon that larger monitors for programmers should be a no-brainer to improve programmer productivity. I'm particularly sensitive to inappropriate space for team meetings. No new kit needs to be acquired to shuffle the furniture and enable the team to stand comfortably standing around their board or to remove superfluous tables from a meeting room so the team can work together more closely.

Rearranging the furniture seems like a very practical way to support the teams you're coaching but it's more than that. Kent goes on to explain that for a team "Taking control of their physical environment is the first step toward taking control of how they work overall." Changes in the work environment send a powerful signal to the team that change is afoot and that the needs of individuals on the team are valued.

And there's more to environment than desks and computers...

At Open Volcano , Marta Gonzalez encouraged me to join her in hosting a session about "Creating an Agile Environment" based on a series of workshops I ran with Mike Hill at XPDay 2006, SPA2007, and Agile2007. There was an empty slot in our open space schedule so we announced the topic and posted it on the board.

   

The previous workshops with Mike involved asking participants to model environments with craft materials and Mike's old lego bricks. We had a sack full of crazy Playmobil characters (including pirates, medics, and firemen) that I picked up on eBay to represent people at work---surprising how appropriate some of the characters are for work situations. However, I figured we could do roughly the same format at Open Volcano by inviting participants to draw agile work environments on flipchart paper.

Everyone loves to tell horror stories about places they've worked. So we start the workshop by drawing "hellish" work environments, based on their real experiences. The pictures quickly fill up with pictures of noisy phones and windows with bars on. You'd think drawing would tend to focus on the obvious physical features of the workspace, such as furniture, but people also showed invisible annoyances like noise, temperature, smells, and management culture.

When we shared the drawings with the group, Marta and I teased out the following environment factors as sometimes impeding the work of teams:-

• Access to information and people
• Temperature (too cold or hot for comfort)
• Noise (from printers, phones, construction work, and other people outside the team)
• Coffee (eg, broiled brown liquid labelled as "normal coffee" isn't!)
• Smell (from food or team mates)
• Light (no daylight)
• Drabness (beige and grey decor doesn't spark creativity)
• Status symbols implying hierarchy (manager has the private office with windows)
• Rules (notices from other departments about what's allowed) --- like Irving's Cider House Rules written by someone else who does not understand the needs of the workers.
• Space (some offices are cluttered and cramped with stuff that doesn't belong to the team working around it)

Some of these are what Hertzberg called Hygiene Factors, we notice their absence and many reflect the company culture indicating whose needs are appreciated by the organization. Talk to the team about what annoys them about their work environment, now you can work with them (and managers) to start resolving these things. Many of these can be improved by the team. For instance, the team can brighten up the team space by bringing in pictures and plants from home, or club together to get a better coffee machine.

Next, we asked the workshop participants to draw a heavenly environment. Not surprisingly, agile teams want plenty of mobile whiteboards, movable desks with large screens that support pair programming comfortably. We also saw more human needs reflected in the work environments, such as pets!

It's clear that people may have different preferences about work environment, which may not be compatible, and this becomes a concern when they are working too close together.

The key seems to be people want to be able to configure their workspace. Here are some ideas for coaches to improve your team's work environment:

• Work in stealth mode, ask for forgiveness afterwards!
• Get everyone involved in the design.
• Offer to restore environment after trialling new setup.
• Read Christopher Alexander "The Timeless Way of Building" and visit Frank Lloyd-Wright buildings.
• Visit other agile teams to get more ideas.

It goes without saying that changes shouldn't conflict with genuine concerns from an organization's perspective such as health, safety, and legal concerns.

Last but not least, here's a great cartoon that Chris Matts drew while talking to Marta about her perfect work environment while she took care of our youngest participant, baby Noah.

Shu-Ha-Ri Considered Harmful?

Back in 2002, Alistair Cockburn wrote about three levels  of practice: learn, detach, transcend that we can apply to our listening, reading and coaching. He used Shu-Ha-Ri from Aikido to illustrate that these three levels of practice are found in other skill areas.

• Shu, the student copies techniques without adapting them.
• Ha, the student reflects on what has been learned and breaks free from traditions.
• Ri, the student is now a practitioner extending the art.

In the 2nd edition of Agile Software Development, Alistair adds "You can apply Shu-Ha-Ri to designing courses and writing technique materials."

Although he takes care to say "Organize your material to reassure the advanced people in your course that it is not being presented as a cure-all, but simply as another technique in the toolbox of the professional. .. But before you finish, put the technique into a larger context so that the beginners can start to see where they will expand to and so that the advanced people can see how this technique bridges to others they might already know or want to learn."

I've seen Agile rollout programs styled around Shu-Ha-Ri for years. In the early days of both XP and SCRUM, it was stressed that you should first do all the practices by the book. Only then would you be in a position to adapt them. You would avoid the travesty of Pretty Adventuresome Programming  where the team avoids any difficult new practices and also drops stuff not mandated like documentation!

Jeff Sutherland relies on the same Shu-Ha-Ri philosophy when he expounds "You enter the dojo and do what the Sensei (teacher) says. You repeat exercises over and over until it is part of muscle memory. Only when you have mastered the basic practices are you allowed to improvise. And the last and most important – Before you have gained discipline, centering, and flexibility, you are a hazard to yourself and others."

I'm uncomfortable with approaches that force students to follow agile practices without questioning. These approaches seem to violate the first value of the Agile Manifesto "Individuals and interactions over processes and tools." I question whether introducing agile software development techniques to people is anything like martial arts training. Software development is knowledge work and our aim is to build a team of reflective practitioners. To do this we need to engage with how people think about their work. Are techniques from physical arts that build muscle-memory really applicable here?

For me, agile Boot Camps and Shock Therapy approaches lack basic respect for the team's unique context and the experience of people on the team. Agile software development is a much looser discipline than a martial art like Aikido. Organizational culture and nature of the product being built are major factors in what agile techniques the team will benefit from most. If we establish a sensei-novice model, we're not fostering the independent thinking and reflection that will take the team beyond the Shu level.

A different approach that draws from martial arts is the Coding Dojo . Dojos are becoming a popular way to encourage learning in groups without this emphasis on a sensei.

Installing a basic set of agile practices by force can be done quickly so the organization starts getting benefits from new ways of working faster. Teams are superficially at the Shu level in the space of a few weeks. Often, the management team considers the agile rollout is now complete. It's assumed that teams will continue to apply what they've learned. But without any experts around to enforce agile practice, pretty soon a team falls back to their old ways or sometimes worse carries on with agile practices that don't make sense for their project.

I was pleased to see "cargo-cult agile" called out in the new book "Practices for Scaling Lean & Agile Development" by Craig Larman and Bas Vodde. They say "Avoid forcing--When coaching we encourage: volunteering; do not force any agile or lean approach onto people; people should be left the choice to think and experiment...with concentrated long-term, high quality support. The best, the most sticky adoptions we have seen had this approach."

Learning new ways of working takes time.  As Ron Jeffries once said "They're called practices for a reason".."You have to have done them. Practice makes perfect." If you base an agile adoption on Shu-Ha-Ri model, the trick is to remember the goal is beyond the first-level. Your teams need more than training. Allow plenty of time and on-going coaching support for teams to get them into the Ha phase and beyond.