Agile Coaching

Ever Considered Ditching Your Tests?

At Agile Open Holland, Rob Westgeest proposed a session called "Ditch Your Tests?" I love to challenge assumptions so I joined the conversation to find out if this can ever make sense. Rob kicked off the session by asking us whether, for a stable piece of code, there can ever be valid reasons for throwing away the tests? And if so, why? Rob captured all the reasons we could think of in this mindmap.

It seemed that these things fell into three categories so we annotated the branches with Q, O, and B where:

• Q indicates bad quality tests. These are fragile, hard to maintain or plain stupid tests.
• O indicates tests that are obsolete. These can be ditched because requirements have changed and tests can be deleted along with the code.
• B indicates tests that block us from doing the right thing.

One of our revelations was that once you absorb a TDD mindset, writing tests is your way of learning about what the code does. Reading someone else's tests isn't quite the same and creating that fresh learning. So for complex code, you might choose to go through the process of building the tests again purely to understand it. For example, you might write tests to understand how to use an API. The tests you write can be thrown away, in this instance, as you're not testing that the code that implements the API, these tests simply help you understand how the API can be used.

The conversation got more heated when we got into whether Mock Objects put developers off refactoring. I first started using mocks 10 years ago at Connextra, when there were no tools to support this way of working (see brief history). I recall cases where unpicking the mocks put us off refactoring the code and although there are much better tools nowadays, I'd say mocks do create a small barrier to refactoring. I've also noticed that Mock Objects can sometimes drive teams to write ravioli code where the code is milled down to neat little objects making the larger design harder to see.

So if we have acceptance/system tests that prove the system is working and unit tests are really a design tool then why do we feel nervous about deleting them? Well, the obvious answer is that a good set of unit tests helps us pinpoint bugs and that can save the whole team valuable time. So preserving your design thinking as unit tests has a more practical purpose as well.

Non-Functional Requirements: are user stories useful?

Here are my notes from the London Scrum User Group this week. LSUG meetings are run as a mini-openspace and so several topics were being discussed in parallel. I proposed the topic "Non-Functional Requirements: are user stories useful?" and joining me in this discussion was Sean Witter, Dave Hale, and Roman Pichler (author of upcoming book "Agile Product Management with Scrum").

I tried to take notes of our conversation on a single index card which got a bit messy! I've linked a scan of this card below but hopefully I've captured the main points of our conversation in this post.

We talked about "non-functional requirements" broadly encompassing both execution qualities, observable at run-time (such as security, performance, usability), and evolution qualities (such as maintainability and scalability) which relate to how the code is structured, see wikipedia. But we also agreed that "non-functional" is a pretty bad name. Roman has a friend who works for Audi and he has responsibility for a system property: weight. Perhaps scrum teams might be better off asking their product owner about what important system properties they need to think about.

We got started by talking about the types of developments that require attention to non-functional requirements. One example, we talked about was Google Chrome where performance was distinguishing feature for marketing and Google did explicit competitor analysis. Another example was a  stock broker, for whom seconds cost money, although functionality also has to be correct.

So what's tricky about non-functional requirements and user stories? The first challenge is that a Product Owner might not know that they need to talk to technical stakeholders to get their perspective on the product backlog. This leads to a product backlog which is solely comprised of functional user stories which makes it easy for the team to miss important non-functional aspects. Where a team releases early and often then they can get user feedback which can help reveal this. But if they only have a low number of friendly users then these early releases probably won't be stretching the system and it will only be once the system is under full-load that limitations are revealed.

You can flush out important non-functional aspects of the product at a vision workshop before the team starts sprinting. You can even frame this as a risk brainstorm and make sure key technical experts, such as software architects take part. Afterward, the whole team is aware of what non-functional qualities they need to aspire to. Of course, not every requirement will be anticipated so the team should still expect some aspects to emerge during development.

Another approach is to make sure that the product owner has on-going support from such specialists, you may even decide to pair a business product owner with a "technical product owner". Sean suggested that a BA might be a good "caretaker" for this responsibility.

Once you've flushed out some non-functional requirements, the next challenge is making sure that they get planned in. Non-functional requirements are often associated with more than one single product backlog item- like business rules. Attention may need to be paid to make sure they're checked every sprint. Roman suggested that you can make it explicit which constraints apply to each product backlog by building them in as extra columns in the Product Backlog and checking those which apply to specific item rows.

One obvious way to check that software doesn't slip through without non-functional qualities being checked, is for the team to build these checks into their Definition of Done. If it's hard to measure programatically then this turns into a review by someone.

A Scrum team can also establish a Done checklist which applies to the whole Product Increment. Although they will need to allow time at the end of the sprint to execute this and fix any problems. I've encountered instances where some types of testing is expensive or time-consuming and the team has chosen to defer this specialized testing to a subsequent sprint. Although introducing special polishing/consolidation/release sprints is risky because issues may be revealed that require significant rework.

As we wrapped up our conversation, Roman also suggested taking a look at what Tom Gilb says in his 1988 book "Principles of Software Engineering Management". Tom emphasizes the importance of establishing key metrics from the outset.

I'm interested in your comments on the above as I'll be giving a talk on this topic at DevOpsDays '09  on October 30-31.

Celebrating Extreme Tuesday Club's 10th Birthday

I'm writing this on the train back from Extreme Tuesday Club. XTC was celebrating it's 10th anniversary. For those who don't know XTC is a weekly meeting for XP enthusiasts which runs every Tuesday in a London pub - the first meeting was 10th August 1999. There's no set format for meetings but most are simply an opportunity for agile interested folk to meet and talk informally over a few beers.

As I walked into the pub, I had no idea who would be there. There's a wiki for people to signup but most people don't get around to doing this. Bob Marshall was the first face I recognized as I pushed open the door into a room already crowded and buzzing with conversation.

I was quickly drawn into a conversation with Antony Marcano and Andy Palmer of http://pairwith.us/ fame. They're brimming with ideas for a new app to make Agile2009 program to navigate. I provided them with a CSV of the program data and we talked through the user stories for a typical user.

Next I caught up with Ivan Moore, we were past colleagues at Connextra between 2000-2003. He wanted to know when my book "Agile Coaching" would be out. XTC is where I first met Liz Sedley my co-author. Steve Freeman joined us. His new book "Growing Object-Oriented Software, Guided by Tests" is going through copyedits now and should be out in the autumn.

Soon after, some of the XTC founders also showed up including Oli Bye - who hosted the XTC wiki for the early years. More and more agile faces kept on appearing - I can't name them all here. Although some XTC founders like Tim Mackinnon and Paul Simmons weren't able to make it.

The next person I talked to was Nathan Lewis who works at the BBC. I was engaged as a coach for his team three years ago. He's just submitted a session for XPDay - XTC's annual conference with the tag line "More than XP. More than one day". We talked about some of the challenges faced in implementing TDD at BBC and the pros and cons of Mock Objects. Not long afted, Nathan was surprised to see Matt Patterson appear - another developer on the team on the first BBC project I coached in 2006.

David Harvey appeared. He's been talking with Mike Sutton - co-organizer of the Agile Coaches Gathering. They're keen to run a one day workshop for Agile Coaches focusing on techniques from theatre improvisation. That reminded me I had some announcement to make.

I chimed on my glass to get some attention for an announcement. But first I asked for a cheer for XTC's 10th birthday and acknowledgement of the founders. I remind people that they need to propose their sessions for XPDay by 14th August. Then I got to my announcement that on 27th September Agile Alliance are organizing a user group reception in London which will be co-hosted with Lean Conference at RSA vaults. Liz Keogh jumped in with another announcement she and Dan North will be running a session at SkillsMatter on BDD next week. There's also a one day BDD conference in the offing.

It's at that point that the real nature of XTC rears it's head. Steve Freeman asks for additional volunteers to keep it going and to find a new pub to host it - we're being kicked out of The Counting House pub at the end of September. All this time an XTC has run as a self-organizing collective. It was set up as the simplest agile meeting that could possibly work. There's no central organizing committee - although we do have one for XPDay. XTC depends on the people who attend the meetings to check with the pub. Recently Steve Freeman has been picking this up but it's a responsibility that has been passed around. The debate spins out about possible venues - foremost in people's mind is the quality of the food and the beer. Maybe it's time for XTC to split? Keith Braithwaite adds that "communities grow by budding".

General conversation breaks out. I get to catch up with Patrick Kua who's delighted to be working on a new engagement in London. I also get to meet Cesar Idovo Carillo, a nominee for Agile Alliance board. It's nice to meet someone in person when you've exchanged emails. I was excited to hear Ceasr's ideas for how Agile Alliance can better support agile user groups. He wants to spread some of the ideas that he's tried at Bay APLN in San Francisco. He's also keen to get some discussion going around the ideas and strengths of the different candidates for Agile Alliance board election to be held in Chicago at Agile2009.

Finally, I got a chance to catch up with to ex-Connextra developer, Tim Cox. He's now at Google and working on code that has some developers in UK and others in Mountain View. He's really happy to be working in an organization with top-notch technical leadership. He's also hoping that he gets the opportunity to go out to Mountain View to encourage consistent coding approaches and evangelize about dependency injection. He feels this would help breakdown the us vs them attitude that sometimes creeps in on distributed teams. In turn, I share one of my current concerns about the defect rates at a current client and get some encouragement about how to present them in a way that they'll take notice. This is this kind of conversation that encouraged me to put forward the pattern "A Shoulder To Cry On" for the book Fearless Change: Patterns for Introducing New Ideas.

 It's hard to convey the energy and discussions going on at XTC but I hope this blog post acts as a taster for anyone thinking of dropping in. When is it? Every Tuesday evening (the clue's in the name) and where? In a London pub - directions available on the wiki.

I'd like to thank everyone who has contributed to XTC by coming along to the meetings and joining in the conversation. Those conversations have been an invaluable resource and sped me on my way to doing a job that I really enjoy.

XP2009 Telling Your Stories Workshop

While I was at XP2009 conference, I participated in a workshop on "Telling Your Stories: Why Stories Are Important for Your Team" organized by Joh Hunt and Diana Larsen. The workshop explored story-telling and how this might be used by agile software teams.

Joh and Diana introduced us to using cards to prompt story-telling. Even although we didn't know the other workshop participants, making up stories around the picture cards felt very natural and we were soon smiling as we enjoyed making up fairy tales.

Next we shifted into telling stories from our own experience and picked one of these to develop into a sort of parable. This was harder as real experiences don't seem to fit as easily and don't always have neat endings.

Finally, we moved into discussion about how we might used story-telling with agile teams. Our group had two ideas:

1. A team could use story card images in a retrospective. Ask each team member to pick three images representing BEFORE, NOW, FORECAST.
2. A team could use the archetype cards to reflect on team behaviour as part of team appreciations.

You can view the photos from this session here.

My takeaways from the workshop are that most people know how to tell a story and that these skills might be leveraged by agile software teams in retrospectives because retrospectives create a shared team story. Reminded me of the David Snowden technique of looking at two possible futures success and failure and then imagining what events led up to these different outcomes. (Need to dig up refs from Cynefin training)

I'm looking forward to running this workshop with Joh in a condensed form in Chicago at Agile2009 conference.

You can order some Once Upon A Time story-telling cards from: http://www.atlas-games.com/onceuponatime/index.php - if you're interested in trying this yourself.

XP2009 workshop: What Does an Agile Coach Do?

I ran a workshop with James Pullicino at XP2009 on "What Does an Agile Coach Do?" I've been writing a book about Agile Coaching with Liz Sedley and so have done lots of thinking about this topic over the last year. Everyone has different ideas about what agile coaches do.

When I look around for books on coaching, I find that there are many about life-coaching. These focus on coaching an individual overturn assumptions to move toward achieving their personal goals. Although I do work with individuals, as an agile coach, I'm especially interested in their interactions as a team. Like sports coaches, our focus is on building effective teamwork as this is essential for agile software development.

I've found one useful book on coaching teams is "Leading Teams" by J.Richard Hackman. He introduces the idea that coaching interventions fall into three basic categories: Motivational, Consultative, and Educational. His model intrigues me. I've been coaching agile teams for the past 7 years and tend to go with my intuitions rather than consciously following a model.

Our workshop at XP2009 was designed to explore Hackman's model through asking some experienced coaches how they would attempt to coach a team in a selection of typical coaching scenarios such as:

• Team member does not participate in Agile meetings.
• Team doesn't have time to write automated tests.
• Team agrees to take on more work than they can realistically achieve.
• Manager/ScrumMaster undermines Agile process by micro-managing the team.
• No support from business for Agile team. No time from Customer/Product-Owner.
• Designers and Architects don't buy-in to Agile approach.
• Team works on more features rather than fixing problems.
• Team don't find retrospective is useful.
• Team miss release deadlines and haven't released code for months.
• Developers work in different city to testers.

It helped that we had some very experienced coaches as participants including Dave Nicolette. We gathered up their different coaching interventions on sticky notes and then attempted to cluster them using the Hackman categories: Motivational, Consultative, Educational. We also created an Other cluster for those notes that didn't seem to fit neatly in a single category.

You can see some photos of the outputs here: http://agilecoach.typepad.com/photos/xp2009_agile_coaches_work/index.html

As you'll see from the photos, there was no big consensus that coaching interventions fit the Hackman model. Although we had lots of interesting conversations exploring how different coaches would work on the above scenarios. It was also great to catchup with James and hear his latest coaching experiences at BBC.

XP2009 conference was in a great location - wonderful to have Open Space sessions on the beach and around the pool - see more photos by Hubert Baumeister.

Agile Coaches Gathering - the sessions

Day 2 of Agile Coaches Gathering was a beautiful sunny day. It was great to catch up with Liz Sedley. Although we've been writing an Agile Coaching book together, our last face-to-face meeting was back in March. It was also nice to catch up with old friends from XTC who sponsored the gathering along with Agile Alliance and Scrum Alliance.

The first session I attended was run by Xavier Quesada Allue about "Effective Coaching Styles" (flipchart below). I'm writing up a some of the topics discussed to be included in the Agile Coaching book. One area was that Agile Coaching is aimed at effective teams unlike life coaching which can be purely focused on and direct by where the individual coachee wants to go.

After the break, I joined the session organized by Peter Camfield on the topic of "Why Do I Coach?" We headed out to the garden to sit in the glorious sunshine and soak up the historic atmosphere of Bletchley Park. People I remember contributing to the session were: Bob Marshall, Liz Keogh, Simon Kirk, and Sophie Johnson.

Peter focused the discussion around the creation of this mindmap (below). It was a frank discussion, we talked about what motivates us to be coaches ranging from social responsibility to some of the selfish reasons why we enjoy it. The session emphasized the importance of understanding our personal motivations to coach agile teams and how being more self-aware can improve our approach to coaching.

I briefly attended a talk by Joseph Pelrine about self-organizing teams but ironically had to leave to organize printing boarding passes!

In passing, David Harvey's session on Dilbert Considered Harmful, I was also blown away by Liz Keogh's beautiful mindmaps.

The highlight of the afternoon for me was the games session out on the lawn where we tried a number of teaching games. By that time I was feeling frazzled. The Point & Go game introduced by Tobias Mayer  where person A points but doesn't move until person B says "Go!" was pretty mind-bending.

We closed the gathering with report backs from all the sessions and a short retrospective. What people liked was the location, weather, and the number of participants (40 people was a good group size). Next time around we may change a few things - such as evening meal arrangements and clustering of topics. Looking forward to the next one!