Agile Coaching

Introducing Agile Techniques to Teams Outside Software Development

Recently I've been helping teams outside Development apply some basic Agile practices. Our company was founded using XP at the core of our approach to software development. We've grown along with the success of our products and now have several departments with day-to-day work that does not involve the Development team (such as Finance, Infrastructure, and "People & Places" who combine HR and facilities management) interested in managing their work along similar lines.

Rather than blasting these teams with Agile theory and principles, we're building things up slowly. We start with a simple sketch about how to make the work for the week visible on the wall then put it together using super-sticky notes - see the photo from our Infra team based. Columns can be added as needed and, when the system seems to be working, lines can be added with tape. Our People & Places team brought in a spirit level and some flowery scrapbooking tape for to make their wall beautiful.

 

Around the board, we run a simple meeting cycle: surfacing and prioritising work for the week ahead, daily standups and monthly retrospectives. People on these teams are positive about the new approach because it helps them to know what's going on around them and have the benefit of advice from team members. They're also enjoying spending more time together as a team and getting a buzz from seeing how much work has been Done. Our People & Places team even have a large photo album where they file all their Done tickets so they'll be able to look back later.

Challenges that come up are pretty typical things we see in software development teams, like long standups and large tasks that don't move. We don't currently estimate the work or apply work-in-progress limits although we've discussed whether this might be worth experimenting with. For now we're limited by wall space and when columns get too full we can see we're being a little optimistic -- taking on too much work or have a lot depending on external suppliers.

Based on this experience I convened an Open Jam discussion at Agile2012 for people who were also interested in applying Agile techniques with non-software teams at Agile. You can see the original flipchart notes here.  I've reworded them a little to help the points discussed clearer.

What's different outside software development?

• Not having a shared goal (on the org chart but not sharing work as a team)
• IT based examples may not help communicate ideas to non-software people
• Work may be very fluid or constrained by lead times and dependencies on other groups
• Team members may be used to being told what to do
• Team members may be uncomfortable with increased visibility of their work
• Team may have more varied experience levels whereas in software development most are engineering graduates
• Individuals may not be interested in team goals if they have a strong focus on their own objectives

What techniques are not specific to sw dev that you can try anywhere?

• Visible work "Kanban"
• Standup meetings
• Setting priorities as a team
• Limiting work-in-progress
• Retrospectives
• Product Owner role (responsible for priorities)
• Coach role (helping team reflect and improve)
• Reviews / Showcases of work done
• Timeboxing / Pomodoros (http://www.pomodorotechnique.com/)
• Pairing
• Test driving without automation
• Visible outcomes - iterating over visible product
• User stories: Who? What? Why?
• Frequent user testing
• Interactive facilitated workshops
• Shorter more focussed meetings with only relevant people
• Balancing relevance against exclusion
• Focus on throughput over efficiency

Getting the conversation started:

• Explaining the value over beer or coffee
• Introducing facilitation as a way to make meetings more fun
• Executive evangelists
• Arranging a tour of software development teams using Agile
• Finding one open and curious person
• Organising a team reliance - involving all hands as supporters
• Making an Agile coach available to teams outside Development
• Crafting an interesting elevator pitch
• Create interest with cool looking stuff

Poll of areas where people at this Open Jam were applying Agile outside software:

• Publishing school text books
• Finance
• Exec team
• National sales
• HR
• Marketing
• Infrastructure
• Supply chain optimisation
• Political programs
• Volunteers at conferences and festivals
• Academic researchers
• Working with children (at school and at home)

If you came to this Agile2012 Open Jam session, please let me know if I've missed anything important from this write-up. It would also be great to hear from anyone who has tried applying Agile techniques outside software, what challenges did you encounter and how did you overcome them?

Guiding New Retrospective Facilitators

I'm now working as a coach for two XP development teams at Unruly. One of the issues that we identified to from the start is retrospectives had become a little stale and in need of freshening up. Although I have plenty of facilitation experience, I would rather see the team members grow their own skills than for me to facilitate every retrospective. So I put out an invitation to all team members interested in learning about retrospective facilitation. Anyone interested in taking a turn at facilitating a retrospective of the other team (than the one they're currently in) gets personal coaching from me.

A week or so before the retrospective, I arrange to meet with each new facilitator to discuss their ideas for the design and preparation for facilitating the next session. We sketch out the design with some further reading and make a list what needs to be done (source sticky notes , book suitable room, find out what happened on actions and working agreements from previous retrospective, contact remote participants). This approach enables me to join in the retrospective as a participant and also to offer some feedback to the new person facilitating after the retrospective is over.

Each new facilitator brings a fresh approach to the meeting and being from another team has a neutral perspective to current issues being faced. In taking the plunge to lead a retrospective, they are able to build their confidence as meeting facilitators in a safe environment. I hope that as we grow our facilitation skills and become more familiar with the meeting mechanics that we will get deeper engagement in our retrospectives.

Naturally, a little patience is required from the team hosting a new facilitator - this is often the first time that they've run some retrospective activities and pacing these comes with practice. Facilitating is hard work - paying attention to the current conversataion at the same time as watching the clock and keeping legible notes is not as easy as it looks! Another challenge that they've taken in their stride is one of our team working in a remote location and experimented with a number of different approaches to include her in our retrospectives.

Luckily Patrick Kua has just written an excellent new book on retrospectives, we bought it for our team right away. Patrick is an experienced coach and technical leader with many practical tips to share in The Retrospective Handbook: a guide for agile teams. This book is perfectly pitched for the new facilitator going over key steps in preparing and leading a retrospective (nicely complementing Agile Retrospectives which is more of a recipe book of activities). Patrick's book also includes handy chapters on Distributed Retrospectives and Keeping Retrospectives Fresh so ideal for our team.

I'd be interested to hear questions or comments on this approach to sharing retrospective facilitation between teams.

 

Busy Burning Down Sprint Tasks

Yesterday, I attended a daily standup meeting run by a Scrum Master/Project Manager. He was holding a red marker pen and, as he went around the circle, he'd ask the developers what time was left as he wanted to be able to "burn down" each development tasks by crossing out the original estimate and putting time left. His focus was on whether the tasks each of them was working on would be finished rather than whether features were actually Done. If a developer said "Yes" then he'd say "Great!"  When he got to the last developer, she said boldly "I told you it would be 2 days at about 3:30pm yesterday afternoon so I haven't even had a full day on it yet."

After the development tasks were burned down, it was the testers turn to speak - of course their tasks were not on the board. There were half a dozen feature cards that had been moved over into QA column because the developers had just made a build available. No questions were asked about time left here. Even though testers raised some blockers, such as needing test kit and wanting to understand what scenarios were completed in previous sprints, they were left to resolve these with developers.

The focus of this meeting seems all wrong. The whiteboard that this team was standing around was very cluttered and I don't think anyone could tell from it what would be done at the end of the week. There was a Blockers area on the board but it seemed unused. The system seemed to have been put together in a hurry and left to get untidy, serving only as a prompt in standup meetings rather than an information radiator of sprint progress.

As getting to Done didn't seem to matter, why burn down tasks at all? My guess is that the Scrum Master wanted to make sure everyone knew they had work to do but surely the team already knew that. Instead of gathering progress and making sure everyone is busy, a Scrum Master should be listening out for blockers that are slowing down the team. Being busy is not the goal, delivering working features is.

Where does this idea of burning down tasks come from? Well, Scrum does indeed encourage teams to be aware of time left by creating a Sprint Burndown chart. But a sprint burndown chart should contain all the work remaining on the sprint backlog not just development tasks. Even when constructed correctly a sprint burndown doesn't really tell you much about where the work is, in my opinion these trend lines are pretty useless. A sprint burndown can mask a team working waterfall-style with nothing made available to test until the end of the sprint. A sprint burndown can also mask a team that is spread widely across a number of features rather than swarming to get a few features complete before starting on the next. It's for these reasons that sprint burndowns have largely dropped out of use across the industry. They take time to maintain and don't give you a lot of information. Nowadays, most teams visualize their work by moving cards across a team board to Done.

To get a richer picture of what is going on I recommend establishing swimlanes so it's easier to see features move across the board. You can also generate a Cumulative Flow chart, basically a tally of the number of items in each column, see below. This can give you a view of where the bottlenecks are and understand cycle times. It's also simpler to update because you total the number of items in each column rather than adding up estimates.

For example, table below shows a list of the number of items in each column from the team board, recorded on a weekly basis.

This table can be used to generate this chart:

One last point is that, once teams get good at slicing backlog items, they often stop doing task breakdown in sprint planning. Consider bringing tasks back into these meetings, if there are misunderstandings about what needs to be done. 

I'd be interested to hear if you've seen similar misunderstandings of burning down tasks in sprints and look forward to your comments. I aim to write a separate blog on product backlog burndown charts and velocity soon so please save comments about product/release burndown or burnup charts for that. Thanks!

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!

Honing your Skills as an Agile Coach

Being an Agile Coach is challenging in many ways. You have to balance many things (see Olaf Lewitz recent post Spotting the Balance) as you work with different teams and stay true to your own values. You are a catalyst for change, helping the teams you work with see how they can work differently and supporting them on their agile journey. To do this you will need a solid understanding of agile principles and plenty of experience in how to put them into practice.

When Liz and I wrote our book on "Agile Coaching" we filled it with stories and examples of how to help teams implement agile practices that seem simple but have many common pitfalls that teams fall into. But you need more than this practical know-how to fulfil the role of a coach. Since writing the book I've developed a workshop style course on to help new coaches expand their skills. The surprising thing is that this course doesn't cover agile practices at all - it's all about the other skills you need to be an effective agile coach.

So what skills are important to build for agile coaches? Well, I think these fall into roughly three categories:-

• Working with people: listening, giving feedback, asking questions, building trust and rapport
• Facilitating change: enlisting support, reaching agreement, spreading success, learning from failure
• Systems thinking: seeing the bigger picture, identifying levers for change, communicating danger signals

Interested in developing your skills in these areas then come along to my Agile Coaching Skills class. Next one is running in London on 25-26 August at Skills Matter and after that in Bucharest on 19-20 September at MosaicWorks.

But training is only part of honing your skills. Practice in a safe environment helps. I introduced the Coaches Dojo as a format for a way for agile coaches to support their ongoing learning without relying on trainers. It's pretty simple to run one of these for agile coaches in your area so I hope more people get these started.

I'm always looking to expand my toolkit and find fresh ideas to experiment with. Later today I'm heading over to the Agile Coaches Gathering and looking forward to learning from other coaches in the open space. Look out for an open space or Agile Coach camp near you.

Keep honing your skills as an agile coach in whatever ways you can, there's always more to learn!

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.