By Woody Zuill

Meetings are great

Meetings are great.  I’m pretty sure that we would all prefer to have meetings all day if we could.  But life isn’t perfect.

Not Really

Ooops. Did I say Meetings are great?  I meant to say meetings are mostly USELESS.  Note I said mostly – not all, just mostly. To clarify (so people won’t complain too much): In my experience meetings are typically not an effective way to get things done.  Seems like they should be, but they AIN’T. Mostly.

[Disclaimer: If you haven’t already guessed, I am talking about meetings in software development.  Nothing else. Especially whatever it is you do, unless you are doing software development.]

Regardless, some meetings are ‘necessary’ in some organizations.  Did you notice the clever use of quote marks around ‘necessary’ in that last sentence?  That is my way of saying ‘mistakenly thought to be necessary’.

Like I said, life isn’t perfect.  Stranger still, in some rare cases meetings are actually useful.  Please don’t quote me on that.  It’s just between you and me.

If you MUST have meetings then make them meaningful.  I can’t help you much with that in this post.  Maybe some other time.  I’ve seen a lot of articles, book chapters, books, and training materials on “how to have effective meetings”.  You can even take week long trainings on this. So, read those, take the courses, listen to a podcast about it, and then make sure that whatever meetings you have are effective.

Teamwork

Teamwork is about people working together to do something.  If your work lends itself well to teamwork, being good at working as a team might pay off.  Working together is not the same as a meeting.

Definitions

A few definitions of words as used within the scope of this article:

Team: All the people needed to create the software being created and who work together to get the software created. (Also goes for maintenance work).  ALL the people needed MUST work together.  Otherwise – it’s not really a team AS DEFINED FOR THE PURPOSES OF THIS ARTICLE.  Okay?

Teamwork: Teamwork is people working with each other to create the software they are creating. The key part of that is “working with each other”. Teamwork is working together.

Meeting: A gathering of people to communicate about the software they are creating.  Examples: Daily Standups, design meetings, requirements gathering meetings, bug assessment meetings, planning meetings, etc. [I am purposefully NOT including these: Retrospectives, Lunch, Trainings, Pair programming]. Meetings are often used for deciding things, communicating things, assigning things, allocating things, and selecting “action items”.  Rarely for doing the work of creating software.

[Disclaimer: You don’t need to work as a team to create software, even when many people are involved.  You can have meetings, communicate via documents, send emails, respond to emails, forward emails, draw charts, email charts, correct charts, completely redo charts over and over, create requirements documents, have more meetings, sign-off on things, base-line things, hand-off things, then repeat, eventually write code, enter test and fix cycle, desperately polish up resume, and so on. There are lots of ways to manage making software.  Good luck on that.  Some famous person once said something about “the definition of insanity” that would be appropriate to point out and reflect on here.  Please recall that quote and chuckle at how appropriate it is.]

No Meetings Rule

Strive to arrange how your team works and interacts so that you never find a need to have a meeting.  That’s the rule.  It’s something to shoot for.  In some workplaces I’ve experienced this, and in some others I haven’t, and I’ve seen lots in between.  The key here is to get as close to this as possible.  It’s a lofty goal.

Meetings are a “smell” in your “process” in the same way that long methods are a “smell” in code, and in the same way that the rotten egg smell is a “smell” in your living room.  These smells are indications that there might be something that needs to be fixed.   Potential solutions (respectively): Fewer meetings, shorter methods, smaller pile of dirty socks in the corner.

Of course, fewer meetings need to be replaced with some other way to get the work done that you are trying to get done that we thought the meetings were helping us do.  Got it?

But Woody, how can we work without meetings?

If everyone works together in the same space (more or less), and is working on the same things (more or less) at the same time (more or less) then we are working as a team (more or less).  Hopefully you can see that this eliminates the need for meetings.  But really work towards the more than the less in each of those.  It works like this:

Same Space

If everyone needed for doing this work is sitting within easy talking distance then communication can be made “in real time”.  Easy talking distance is 5 or 10 feet with no walls, doors, or cubicles in between.  When I have a question I can ask it – and get a response right away.  If no one knows the answer, we have discovered something we didn’t know – right away!  This is always fantastic.  The less time it takes to get answers and discover the things we need to discover, the better off we are.  Being close physically allows us to be close “in time” as well.

Same Things

A “greater than the parts” effect happens when we all work on the same thing. This idea of  synergy happens easily when all the brain-power and effort is being applied to the same thing.  The answer to a question is likely already in the brain of the person being asked (the askee?) because the asker and askee are thinking about and working on the same stuff (more or less). And if that answer hasn’t yet been thought about, it is simply another thing we are going to pay attention to RIGHT NOW, because it is what WE are ALL working on.  It is no interruption for the askee because she is working with the asker on the same stuff.  Ideally, WE are all working to get the same exact thing done and delivered.

Same Time

When the whole team is working at the same time on the same thing we shorten the feedback loop for all interactions.  Work speeds up by an order of magnitude (your mileage may vary). The conversation happens quickly –

• Asker: “I was wondering about how this detail fits in” –
• Askee: “Yes, it’s like this…”
• Asker: “That’s not what I meant, I am asking about this part of that…”
• Askee – “Ohhhh, I see, right – it’s like this…”
• Asker – “Great! thanks”

That might seem like an exaggeration.  However, even when we don’t know the answer, the quick communication gets to the point very quickly:

• Asker: “I was wondering about how this detail fits in” –
• Askee: “Yes, it’s like this…”
• Asker: “That’s not what I meant, I am asking about this part of that…”
• Askee: “Ohhhh, I see, right – you mean this thing here?”
• Asker: “Yes, that is where I am stumped”
• Askee: “hm, I’ll need to figure that out.  I’ll do that now… can you help me look at a few things?”
• Asker: “Sure! Let’s take a stab at it” (This is LTASAI driven development, by the way).

Okay.  This is just a little, quickie blog post so I’m not covering all the types of communications we need to make. Hopefully you get the idea.

Working in the Same Space,  on the Same Thing, at the Same Time “side benefit”

To do this same space, thing, and time approach we need to have relatively small things to work on.  Very little of what we do is “small things”, but almost everything we do is made up of small things. You get the idea.  BREAK IT DOWN.  But, only break it down just before you work on it.  You have a pile of big things to work on (some call that a backlog, but it’s just a pile of big things to work on). The key is, that “backlog” is a pile of BIG things.  You peel off a small thing when you are ready to do more work, and you work on it – all together, in the same space, at the same time.  If it turns out to be too big, you’ll discover that – and you just peel off a smaller bit.  If it’s dependent on something else, you’ll discover that and you’ll work it out.  I have confidence in you.

So the side benefit is you will need to get really good at breaking things down and working on the smallest reasonable part of everything you work on.  They’ll tell you it can’t be done.  Prove them wrong.

But Woody! We still need meetings for certain things

Of course you do! I’m just suggesting that more and better teamwork is a way to lessen the need for meetings.  It’s like this little paraphrasing of one of the Agile Manifesto Principles.  We can call this the Principle Of Meetings:

Simplicity – Maximizing the number of meetings NOT HELD – is essential.

And remember.  There is no Agile Manifesto Value of “We Value Meetings Over Getting Work Done”.   Although, way back when, I have worked at places where it seemed that way.