What Time’s Your Stand-Up?

The stand-up meeting has had quite a lot of attention on my team over the last week. At our last retrospective, it was brought up as a problem that we nearly always had at least one person missing when we started the meeting. Obviously this hampers us reaching the goal of having a rich and motivating exchange of information throughout the whole team. We still get a chance to adapt the plan, but not everyone’s going to know about that if they weren’t there. I also feel it really drags down morale when the same one or two people (and it’s nearly always the same ones) appear not to be as committed as the rest.

So, like all good self-organising teams, we got together and talked about it. Yep, we had a meeting about a meeting.

During this, at times heated, discussion it became clear that we were talking about two separate issues. As well as using the stand-up to synchronise our work, we were using it as our starting-point for the day. Those who like a lie-in will tend to get themselves in just in time for stand-up, and thus their day begins.

So while the first and most obvious issue for debate was what time to have the stand-up meeting, lurking in the background was the much more thorny issue of how late it is acceptable for a team-member to turn up for work.

Fortunately we spotted this pretty much in time before the mud-slinging between the early-risers and the alarm-clock-o-phobes began. On reflection of the benefits of the meeting as a whole, we judged that providing a start-point for the day was not as important as the other benefits about communication which require every member of the team to be present. So we decided to abandon the use of the stand-up as our start to the day.

So that we can still harness the motivation that comes out of a good stand-up, we decided to hold it at 2pm, when everyone should be back from lunch and ready to blast through the afternoon.

All we can do is try it and see how it works.

What time do your team have their stand-up, and why?


Comments (0)


The Path to Greatness – Anyone Got a Map?

I just bumbled into a great post by Raganwald on the subject of certification for professional software developers.

It’s something I’ve been giving some thought to lately. I coach my team informally on a daily basis as we work together and more formally at the end of each iteration during our retrospective. I’ve also been asked to start a process of coaching other teams too.

In my other life, I teach people to snowboard. BASI, the organisation who taught me to teach, have developed a clear progression from complete novice through experienced recreational riders, right up to instructor trainer. Similarly, I just took the PADI Open Water Diver course, and again there is a clear progression where you learn the skills required to dive safely on your own.

Like Raganwald, I feel that certifying people for technical skills like expertise in coding a particular language is really missing the point. I thing he’s on to something by wanting to prove that a person knows how to produce a bullet-proof product – after all, that’s the whole point isn’t it?

I’m interested in the series of learnings that people go though in their time at work that take them to the point where they do a lot of these things as second nature. Where they don’t claim something is ‘finished’ when they first manage to get some data up on the screen; where they know exactly when to step away from the keyboard and make a cup of tea to mull something over, or when to ask for some help instead of thrashing themselves, quietly, into a rotting hole. The things that make people valued members of my team are much more the ‘soft’ skills that mean they spend their time at work as effectively as possible, like confidence, humility, and empathy.

In a way it’s a good thing that we don’t just have a simple scale to measure people against, we’re dealing with real human beings, after all. On the other hand, it might be handy to have a map to help us all along the way.


Comments (0)


The Power of a Good Story

When I sat Mike Cohn‘s scrum-master course last year, one of the concepts I learned was the idea of templating all your user stories like this:

As a [type of user], I want to [do something useful with the system], so that [reason / motivation for wanting to do it].

I’ve come to realise that capturing these three perspectives on any deliverable is actually really powerful stuff. When you break it down, what you’re essentially getting is:

  1. who is the stakeholder who wants this work done?
  2. what is the goal for the person trying to deliver it?
  3. why does the stakeholder want it done?
(1) and (3) really help you prioritize: Does this user really need this? If so, do they need it right now, or is there another feature / story we should be delivering first? (3) especially, can really settle disagreements here, or make otherwise opaque choices become more obvious.

The whole story, but especially (2) gives the developer (or whoever is delivering the work) a clear goal to work towards.

I think it’s far too easy to dismiss this format as wordy and unnecessary, as I did it myself at first. Like so many agile practices though, when I force myself to use it in a consistent and disciplined way, it’s then that the power of it really emerges.


Comments (0)