Tag Archives: 2011

Post #Agile2011 Playlist

Posted on by
Reply
Reading time ~ 2 minutes

An insight I picked up from Jeff Patton during his user story mapping workshop at Agile 2011.

  • Use music to help you facilitate your sessions

Jeff used “Kung-Fu Fighting” as backing/timing music for one of the group exercises.

When I got home I sat at my computer trawling my music collection for perfect facilitation tunes ranging from 3 to 10 minutes long.

I have loads that I’ll unleash on teams over the coming months 🙂

There’s an important trick to these though. They have to be the “right” tempo and style to match the activity and team – generally upbeat and well-known enough that team members can “feel” the end of the tune coming.

In the meantime, in a change from my normal programming I’ll switch to my other passion; music…

If like me it’s been a really intense week and you’re on a post conference come-down (see Doc List’s post on similar here), here’s my recommended selection of music (in this order) to recover to…

If there’s any of these you don’t own, buy them now or cue them up on your favourite online station! I’ve added links to the hardest-to-find tracks.

2011-08-14 All Agiled Out – on Spotify

* playlist heavily influenced by available music selection on the airplane journey home

Note – If you’re not feeling so cheerful, It’s important you don’t stop part-way through.

For anyone who’s a fan of “High Fidelity”, the art of the compilation tape is the journey you’re taken on.  This one will only leave you happy if you make it to the end!

Improving Your Retrospectives

Posted on by
2
Reading time ~ 3 minutes

Inspired by Carl Bruiners – he described many unsuccessful retrospectives as “Happy Clappy” or “Toothless”.

– I love the term “happy clappy”

Last weekend  I hosted/facilitated a short session at the UK Agile Coaches Gathering on “How To Improve Retrospectives”. A valuable hour or so of shared challenges and lessons. Here’s the highlights I was able to capture.

Let the Team Vent

  • If you have a very frustrated team with a succession of issues, give them time for catharsis. 2 or 3 “venting” sessions to let off steam rather than retrospectives needing concrete action may actually be necessary. After the sore points have been drained, circle the team back around to actually solving some issues
  • Facilitate the venting to keep it constructive, not personal and ensure they are actually draining issues, not fuelling flames

Think Lean

  • Prevent batching and waiting by raising issues sooner with the potential to address improvements rapidly before a retrospective even happens
  • Capture your data points and lessons as soon as they come up – on the board for the team to see every day. Discuss them as part of the stand-up
  • Track activities, lessons and problems on a timeline during the project or
    sprint, not at the end. There will be less head-scratching and forgotten issues in the retrospective. It’ll be faster to get moving, you’ll have fixed more and people will feel the time spent has been more productive
  • Consider setting a threshold / count of the number of issues or lessons raised as a trigger for a retrospective rather than just sticking to a sprint rhythm

Figure out what to do with “stuck” actions

  • If there are recurring problems beyond the team’s control, take them off the table. There’s no point in self-flagellation. Raise them in a forum other than retrospectives
  • Define a clear, workable escalation path for when a team needs support to resolve a retrospective action
  • Work with “management” to clear at least 1 stuck retrospective action in order to build team trust in both the management and process – prove it’s working, worthwhile and supported

Keep it interesting & fresh

  • Once a team is used to the general structure of retrospectives and using these relatively effectively, use variety to keep things fresh and interesting – see the “Agile Retrospectives” book and associated mailing list for ideas
  • Retrospect on your retrospectives, – e.g. using start/stop/continue

Beware of US/UK social differences

  • Thanking and congratulating each other is not a common cultural behavior in the UK. Get teams comfortable with other activities and working as a team before approaching some of the “softer” areas
  • Recognise your team members may not be happy talking about how they “feel” about projects, each other, values or any other “hippy” concepts

One of attendees at the coaches gathering described a painful retrospective experience where a single member of a team effectively shot down a retrospective by refusing to participate in sharing feelings. I’ve had similar derailing experiences where a single team member didn’t want to take ownership of any actions or decisions and pulled a team with them. In both cases we just called a halt to that part of a retrospective and moved on. There’s always next time.

Deciding What To Do

  • Capture actions for the team and actions for “management” independently
  • Use dot voting or similar consensus-building activities for selecting actions
  • Encourage people to vote for what they’re motivated to address and capable of resolving, not just items they think are important
  • Limit the number of actions to commit to & address, you can always come back for more
  • If you complete all the committed items, consider pulling one more new action through

Agree When & How actions will be covered

  • Some items are “just go do”, others have more cost. Address just go do items as they come up
  • Consider use of stories for larger actions in backlog and prioritization
  • Try “sprint tasks” to keep “customer” activity/velocity independent of “non-customer” actions and improvements
  • Identify owners for taking management actions to the management (typically a coach, team lead or scrum master)

Thanks to Sophie Manton, Mike Pearce and other attendees for the insights & lessons they shared at the Coaches Gathering.

Agile 20xx – It Takes a Team

Posted on by
Reply
Reading time ~ 3 minutes

Inspired by this post I just read from Seth Godin. As an average joe, hob-nobbing with CEOs isn’t so likely for most of us but the interpersonal interaction certainly is worth making time for. However…

If you’re paying to learn and thinking of attending Agile 2011 (or any other really big conference) take a team!

For the last couple of years I’ve attended the big US Agile Alliance conferences. I love going although I miss my family; I really enjoy the social interaction, spending time with (on the surface) a bunch of smart, similar-minded people sharing a week of learning, collaboration and fun. There are of course undercurrents (see this old post from Jean Tabaka) but I still find attending these conferences a rewarding experience.

For anyone that’s not been, the Agile 20xx conferences are huge and seem to be getting bigger every year. The number of parallel tracks – all with great presenters means you really have to make a plan.

Each year I’ve attended, I’ve had the luxury of going out as part of a team. My advice to future attendees is the same – take a team and collaborate on what you want to see.

My goal each year is to walk away with at least 3 key pieces of new thinking that would add value to my teams. The travel and conference fee for just 3 ideas might be excessive but as I said, I also go to learn, collaborate and have fun.

If even 1 of the ideas I bring back is sticky enough to be introduced successfully to a group of nearly a thousand engineers worldwide then I think that’s worthwhile!

So which sessions do you attend?

Personally I tend to steer away from the “rock star” sessions. Most of what they’re presenting is covered in their current or forthcoming books (and I read a lot of those already) so I don’t get much from them. Other members of my team don’t read so much and so will go along to some of these. Get the team to strike a balance but make sure the motivation is to learn and share, not just to meet “famous people“.

The stuff out there from people without book deals is rarer so I make the most of those sessions but less-experienced or well-known presenters may mean a higher risk of a not-so-good session.  Also keep an eye out for the open space sessions and lightning talks. You’ll find a lot of up-and-coming talent and thinking out there but again, your mileage may vary.

I also tend to look for things that are relevant to my current context, and future direction, not just my current role. A big part of my interest is in viewing things from other people’s and roles perspectives – for example I’ve never formally had the job title of “tester” but “Agile Testing” is one of the best books I’ve read that really “gets” cross-role pairing and test strategies – relevant to developers and managers, not just testers!

Others may prefer to spend the entire week in “UX” or “Testing” tracks but generally I strongly discourage spending the entire week in a single track in your own domain – you just don’t learn enough of the other interesting gems. Maybe it’s just me but agile isn’t just about your own specialist area, it’s about the whole team and organization.

Having presented at Agile Cambridge last year; I and my team have submitted a couple of proposals for Agile 2011 as we’re hoping we can start to give something back. There’s a lot of presentations out there so our chances are slim however despite the number that don’t make it, there are hundreds of great ones that do.

When planning your sessions, take a team and go for a knowledge portfolio – balance risk & reward to get maximum return on your investment. You won’t regret it.