I struggle with a lot of things. No, no, it’s true. I’m not the infallible coder of the earth that my online persona may have you believe. There are things in this world that I have trouble with. Saran Wrap, for example. It is one of my life goals to be able to tear off a sheet of it without having it stick to itself, forcing me to fiddle with the edges until it’s a mangled ball of cellophane and I have to summon my nine-year-old daughter to tear off another sheet for me. I just don’t have the required food storage skillz. But I’m learning.
Another point of potential improvement is meeting preparation. In my current assignment, we’re test-driving scrum. I’ve worked in a scrum environment before but I came in partway through and the existing team was already long practiced at it and I was able to merge in pretty quickly. In this one, we’re all kind of getting a feel for it.
Part of the process involves meetings. The daily stand-up, of course, but also code reviews, retrospectives, demos, and planning sessions. And I don’t feel like I’m as productive as I should be in them.
The reason for this is that I’m used to meetings being interruptions in my work. The two-hour eye-wateringly detailed recap of the project plan. For these meetings, I’d work until the last possible moment before another conscriptee passed my desk and said, “you coming to the meeting?” at which point I’d lock my computer and saunter into the meeting, usually a few minutes late. And I wouldn’t be the last one in. These are mindless meetings. Ones where you don’t need to put in any thought before, during, or after. You’re there to grease the project manager’s wheels.
But the scrum meetings seem to demand more discipline from their attendees. They don’t work as well if everyone walks in with a “switch-on” mentality. That is, they turn their attention to the meeting task as soon as they walk in the door.
Consider a retrospective meeting, where you discuss the good, the bad, and the physically unattractive of the most recent sprint. Very often, the question will come to me, “what was good/bad about the last sprint” and I’ll have to sit and think for a few minutes before coming up with some lame contribution just because I didn’t want to look like an idiot. (“Well, I really liked the colour palette we chose.”) Wouldn’t it have been easier if I did that thinking beforehand so I didn’t waste anyone’s time?
This is even more critical for code reviews and planning sessions. Almost anyone that has attended a code review has had everyone walk in, sit down, and the leader says, “So what do we want to look at today?” Ideas are thrown out, some code is plastered on the page, and everyone looks at it for a few seconds before tossing out ideas off the top of their head.
Ditto for planning sessions. “I’m thinking we should handle the admin screen to add customers?” “Hmmm…that might be a good idea…actually, no wait, we should do the invoice screen first, then we’ll have an idea of what data we need to capture.” “But if we do the invoice screen first, we’ll have to wire in the calculation engine.” And so on and so forth.
This is the type of discussion I think is worth *starting* over e-mail. I.e. An e-mail that says, “The planning session is on Monday, the features under consideration are: 1) admin screen for customers, 2) invoice screen, 3) easter egg page showing the after effects of the company Christmas party. Let me know your thoughts before the meeting.” Then, come Monday, everyone has (presumably) contributed to the discussion, some issues have been brought forth and we’ve got a head start.
For code reviews, it’s the same thing. A generic review where the class-at-hand is decided on the spot leads to developers wondering if they’ll have to end up spending the meeting defending their code. But if the code being reviewed was decided beforehand, he could take a look at it and maybe get a sense of the issues that maybe be brought up. And presumably, the issues that *are* brought up are more substantial than “shouldn’t you have an underscore at the beginning of your variable names, Sparky?”
I’m already doing this in some respect for the daily stand-up. It’s not very mentally demanding because you generally have a good idea what you did the day before and what you plan to do today, but I still go through the mental exercise before the meeting. But that’s because the expectation has been set that everyone should know what to say and get to the point. The same expectation usually isn’t held at the more involved meetings.
The latent English professor in me says that this is an awkward place to end the post but for the life of me, I can’t think of anything else to say. So…ummm…start the discussion before the meeting, I guess is the overall takeaway here.
Kyle the Prepared