Matt Wynne :: Tea-Driven Development

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?

I just came across an article written five years ago by Richard Gabriel proposing a university course run along the lines of his own Master’s in Fine Arts in poetry. The idea evidently gathered some momentum at the time, but now seems to have come to a halt.

What a shame. I’ve had an idea to get back to university on a ’some day’ list for a while, and this would have been pretty much exactly my thing, I think. Seems to me like it was just an idea ahead of its time… I wonder how popular something like that would be now, with the increased focus on Quality that is sneaking in the back door behind the noisy razzmatazz of agile adoption.

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.

As with most stupid questions like this, the answer is “neither”. There are times when integration tests really help, and there are times when they can be a pain in the neck.

I was prompted to write this post when a colleague pointed me towards this page on the behaviour-driven wiki, which mentions the disadvantages of integration tests, which usually involve some complex (and often slow to run) procedure to set up an expected state in the system your code is integrating with. This tight coupling with the external system reduces agility and makes the test code brittle.

The page does point out that “even in this state the code is often much more robust and a much better functional fit than code developed under more traditional methods based on large-scale up-front design”

I agree with the principles in the article, and I believe BDD is a great way to think, but I do think as long as the integration tests are well-factored (and hence easy to change) then the problems highlighted don’t apply – you’re still going to be quick on your feet if requirements change.

The question is whether you’re going to spend more time fixing your unit tests than you would debugging the code – if you’re confident you can write it correctly first time and anybody needing to change it is highly unlikely to introduce bugs in the area you’re coding, it’s a waste of everybody’s time to write a unit test – the test just becomes baggage for the team to drag around.

Conversely, if there’s a risk that future changes could break what you’re coding, or you’re bored of hitting F5 in the browser to test some subtle tweak in a function way down deep in a subsystem, thinking of an imaginative way to write a lightweight unit test that isolates that function and proves that it works as you want it to, is probably going to save you some dull debugging time.

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.