Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Mindless vs. Mindful Meetings, or “How to think before you meet”

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.image

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

This entry was posted in Sundry. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://jamespeckham.com James Peckham

    I’m going to add that if your meetings lack direction or focus then you have a failing scrum master and or product owner. They should be facilitating and making these productive or they should be removed.

  • http://jamespeckham.com James Peckham

    This is one of those ‘agile’ things that people sit in two different camps on.

    Do you spend time hashing out any details of anything that may or may not be in the next sprint at all?

    Do you interrupt a programmer to ask a question about design possibilities without including a QA Analyst?

  • http://www.ronaldwidha.net/askbobo Ronald Widha

    One of the important ingredient to an efficient meeting, I feel, is to include the right people. Often meeting is filled with irelevant people and turned into a socializing event than a productive one.

  • http://codebetter.com/members/kylebaley/default.aspx Kyle Baley

    Azeem: I would start with e-mail and see if it works. Your team is already using it and using it often. So it’s relatively friction-free. Adding a collaboration tool will add process.

    The goal of the pre-planning isn’t to hash out the details. It’s to get you started so you can hit the ground running. Ideally, you won’t spend more than half an hour on it. If you do, it’s a discussion better left for the meeting itself. Essentially, it’s an e-mail that says: This is what I’m thinking for the meeting. If someone wants to reply to address issues, that should be allowed. But after that, if you feel the need to rebut, I’d leave it until you can talk face to face.

    Collaboration tools can have their place. But you have to be sure they aren’t getting in the way in order to get your actual outcome. Otherwise, people won’t use them effectively (or at all).

  • http://codebetter.com/members/azmsrwr/default.aspx Azeem Sarwar

    Do you think mailing is enough for a meeting planning?
    Should we use some collaboration tool to automate the process of planning. Or you consider this automation will be to grease the project manager’s wheels despite an actual outcome?

  • http://codebetter.com/members/azmsrwr/default.aspx Azeem Sarwar

    Mindless meetings makes Scrum look bad in front of management.

    Even due to these once our top managers decided to finish Scrum at all but we survived somehow :)

    Nice post