Agile Coaching

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 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!

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.

Summer Events for Agile Coaches

Summer is here at last with blasts of rain and sunshine. Here some upcoming events that might be of interest to you as agile coaches in the UK.

The first one that I'd like to bring to your attention is the Agile Coaches Gathering at historic Bletchley Park. This event is put together by volunteers (yours truly and Manav Mehan). The event starts on Friday with an Open Space gathering to create a lively program of conversations and simulations relevant to agile coaches. In the evening we venture into Bletchley for dinner at the local chinese and indian restaurants and beers in the pub. The sessions run throughout the day on Saturday. The past two years we've had sunny weather and many sessions outside on the lawn. As I write, we already have 40 people registered for the event and just 20 places left, sign up here to get yours.

 
I'm also excited to announce that I'll be running my Agile Coaching Skills training course in London on 25-26th August. This workshop style class has been extremely popular, past attendees include Jon Jagger and John McFadyen. Unlike a Certified Scrum Master class, we assume that you have some agile experience and our focus is on skills that you need to coach agile teams, such as the art of facilitation and System Thinking.

 

 

If those dates don't work for you then why not venture along to eXtreme Tuesday Club? Everyone is welcome just sign up on the wiki no registration required. It's on every Tuesday, just pop in after work on a sunny evening. You'll get a chance to chat to an eclectic mix of agile practitioners and luminaries like Steve Freeman, Liz Keogh, Tom Gilb often come along. Follow @extremetuesday on Twitter for announcements.

If you're not close to London then maybe one of the upcoming regional events might work for you:

• Agile on the Beach on 15-16th September with keynotes: Mary Poppendieck and Kevlin Henney.
• Agile Cambridge on 29-30th September with keynotes: David Anderson and Jurgen Appelo.
• Agile Yorkshire and Agile Scotland also have regular meetings.

Please post a comment if I've missed any crucial summer events. Hope to see you at some of the above!

Embrace A Skeptic

As an agile coach, you're bound to encounter a few skeptics in the teams and organisations you work with. Although sometimes it seems that skeptics are doomsayers bringing a cloud of negativity to the team and it's tough to see ideas shot down before they've been given a chance. In my experience, skeptics are to be embraced.

I've been coaching agile teams for a few years and had plenty of exposure to naysayers and cynics. What has surprised me is how many of former skeptics are now agile advocates. I started my own agile jouney as a skeptic about XP but I was curious enough to give it a try. I remember also when I first worked with Monica, she was a program manager who seemed determined to stop her team get even a toe-hold to try agile practices like Test-driven Development. Since then she's brought me in to coach her teams in two different media organisations and she now works for an agile consultancy. I have a bunch of similar stories about former agile skeptics so I thought I'd write up what I do when I meet an agile skeptic.

The first thing to remember about a skeptic is that they are at least giving your proposals some serious consideration. They are thinking about whatever is being put forward otherwise they wouldn't be able to come up with any arguments against change. Try to accept that most skeptics care about many of the same things as you do. They want to be able to do a quality job and not to waste time. However, they have to yet to be persuaded that being "agile" helps and likely fear that change will make things worse.

Moreover, they're likely to have real experience to share that underpins their position. To get a skeptic on your side, you have to listen to them and hear their concerns. You are likely to learn something useful by working through the obstacles they see. You can work with them to improve your approach. There may be simple tweaks you can make to avoid the pitfalls that they raise and allay their fears.

In their book, "Fearless Change: Patterns for Introducing New Ideas", Linda Rising and Mary Lynn Manns include the Champion Skeptic pattern. They advise that you actively seek a skeptic to help sharpen your thinking because skeptics can help you find weak parts of your change message.

So next time you find yourself worrying that a skeptic on the team is out to burst your agile bubble, pause and take time to listen to their concerns. You might learn something!