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!

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!

Adapting Your Agile Coaching Style

One of the questions we explore in my "Agile Coaching Skills" training course is when to adapt your coaching style. I draw an arrow running from Directive to Non-Directive, like the middle arrow in the sketch below, to represent one important aspect of coaching style. I explain that the coaching style you adopt depends on the experience of the team members (topmost arrow) and your own experience (bottom arrow).

 

A heavily directive approach would be one where people are firmly told to follow a specific set of agile practices, as in Shock Therapy popularised by Jeff Sutherland. There's no choice being made by the team, they rely totally on the expertise of the agile coach to determine an approach suitable for their situation. The reason that they are willing to do this is that they recognise that they are new to agile and don't have the skills to decide what's appropriate. The agile coach acts as their guide and mentor enabling them to enter a new world of agile software development. Many coaches would consider this directive coaching style to be more consulting or teaching than coaching.

A totally non-directive approach would be where a coach relies purely on asking thought-provoking questions and sharing their observations to help a team identify alternative ways of working. In theory, this coach need not have any subject matter expertise in applying agile practices, they leave the choice of where to go upto the team. This approach works in situations where the team has built up enough knowledge in basic agile practices to apply them. However, the team is still struggling to overcome mental blocks about what is allowed within their organisation and see how they might improve. The coach's questions helps this team break through obstacles in their way and reveal choices open to them. A team that is new to agile, and is still grappling with building basic skills, may find this coaching style frustrating because people want definitive answers while they're learning and don't feel confident to experiment yet.

As agile coaches, we work with teams with a variety of experiences and so we need to remember to adapt our coaching style accordingly. Some teams are just embarking on their agile journey, others are already partway down the agile road, teams may also contain a mixture of new and experienced team members. We need to recognise where the team is at and adapt our coaching style to match the needs of the team. So when the team is new, we need to be prepared to act as teacher. As the team gains confidence, we need to recognise that it's time to step back and help them build a sense of autonomy, enabling the team members to choose where to go next rather than supplying all the answers. To take the team on this journey, it helps to have some experience of applying agile to draw on so you can support the team with directive style guidance when they get stuck.

Remember also that a team's agile journey is not usually a straightforward one where they load up with new agile practices at the beginning and simply perfect their application of those initial practices as they go. The road most teams travel has many twists and turns. Depending on the terrain the team encounters, it may be appropriate to learn new practices and drop or unlearn old habits along the way. As agile coaches, we need to see when to step in with guidance and direction to help the team learn a new skill and when to step back into non-directive style coaching. Be prepared to switch in and out of these styles throughout your time with the team.

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 :-)