Tuesday, November 24, 2009

Scrum?

So I've been on several teams that refer to themselves as agile. They do scrum meetings each day and get updates from individuals on the team. Presumably, the meeting is for coordination of effort among the individuals.

Scrum seems to work better in some groups - finding holes in requirements, promoting discussion about a data model, general communication to make sure everyone can deliver for the next iteration.

Sound good? Sound normal? Sound effective?

Well I've wondered lately about the cumulative time from all the individuals in the room - that's a lot of work time. That's a lot of disruption. That's a lot of "I'm working on bugs" on some days.

Then today I was reading a passage in the book Peopleware that warns of a balance.
The ultimate management sin is wasting people's time.
...
When you convoke a meeting with n people present, the normal presumption is that all those in the room are there because they need to interact with each other in order to come to certain conclusions. When, instead, the participants take turns interacting with one key figure, the expected rationale for assembling the whole group is missing; the boss might just as well have interacted separately with each of the subordinates without obliging the others to listen in.
He goes on to say that some ceremonial meetings are necessary, for project milestones, when new people come on, celebrating a release, etc. However, the authors in the same section of the book say:
A real working meeting is called when there is a real reason for all the people invited to think through some matter together. The purpose of the meeting is to reach consensus. Such a meeting is, almost by definition, an ad hoc affair. Ad hoc implies that the meeting is unlikely to be regularly scheduled. Any regular get-together is therefore somewhat suspect as likely to have a ceremonial purpose rather than a focused goal of consensus. The weekly status meeting is an obvious example. Though its goal may seem to be status reporting, its real intent is status confirmation. And it's not the status of the work, but the status of the boss.
Weekly status meetings?!? What about a daily status meeting?

Now I'm not saying that scrum is always a waste of everyone's time. However, I wonder if we in the world of agile are missing the point sometimes and ceremony trumps getting work done. I wonder if many of the same things could be accomplished by having a common work area online, like a campfire chat room or an IRC channel for work discussions. I thought a recent interview (links to page 2) with Jason Fried of 37 Signals was interesting - his take on meetings.

The excerpts from Peopleware come from chapter 33: "The Ultimate Management Sin Is ..." It goes on to talk about all sorts of ways to waste people's time.

I just thought it was interesting to contrast the need in agile for a scrum-like meeting with the need for uninterrupted work time. I think it just inspires thought about whether or not a given meeting, particularly a regularly scheduled meeting, is of value.

An Office Environment

Since I picked it up in grad school, I've been fascinated by a book called Peopleware and the different ways of thinking about the work place.

This morning I read a bit about how a work place or work space affects the productivity of a software developer:
"Staying late or arriving early or staying home to work in peace is a damning indictment of the office environment. The amazing thing is not that it's so often impossible to work in the workplace; the amazing thing is that everyone knows it and nobody ever does anything about it."
- Chapter 8, "You Never Get Anything Done Around Here from 9 to 5"
They went on to describe a study they did involving developer productivity. They found the normal 10:1 range of individual developer productivity. What was surprising was they also found that there was a 10:1 or so range for organizational productivity - with two developers from each organization. The two developers from each performed on about the same level.

It would seem that not only individual developer productivity matters, but also their working environment.