Meeting Etiquette

As you move up the ranks from technical positions to more managerial positions you invariably find yourself doing less technical work but attending more meetings where issues are discussed and decisions need to be made. Well-run, concise meetings are essential to information flow and collective decision making however I've attended far too many meetings that fail to observe what I consider basic etiquette for meetings. Accordingly, here's my short list of things to do to make meetings more productive:

  1. Before initiating a business discussion, know your goal!
  2. Non-verbal communication is a big part of your message!
  3. Respect and listen to (but don't always follow) other peoples' opinions
  4. Be conscious of how much time you are taking in the conversation.
  5. Time-box open forum discussions to force people to be concise.
  6. Don't be afraid to cut people short if it's heading in the wrong direction.
  7. Evaluate the personality of the other attendees, and adjust communication as necessary.i.e. Don't talk techno-babble to the CEO.
  8. If you invite subject matter experts to attend the meeting let them speak to those issues - they're the SMEs right!
  9. Before agreeing to attend, ask 3 questions about a meeting:
    • What is the purpose?
    • What is the agenda?
    • Am I really needed?
  10. Don't use meetings to grandstand - you'll lose respect fast
  11. If you are providing input to the meeting, come prepared so as not to waste other people's time.
  12. Take notes - reliance on human memory is a sure path to failure.
  13. Prefer quick hand-drawn diagrams on the whiteboard (which can later be photographed/scanned and circulated) over elaborate PowerPoint presentations. You'll get the job done just as effectively an order of magnitude faster.
  14. Prefer video- and tele-conferencing over long-distance travel but make sure the technology works beforehand.
  15. At the end, summarise action points and key decisions made so everyone is on the same page.
  16. And finally, be on-time. You are wasting other peoples' time by being tardy.


Getting Certified in Scrum

Last week I spent 2 days with Jens Østergaard getting up to speed with Scrum. Having been using Scrum for a while I thought it was about time to actually get certified in it and make sure those books I've read on the topic were leading me in the right direction.

Overall the course was excellent. The theory backed-up what I'd previously read on Scrum and the classroom exercises were insightful to say the least. The most disappointing thing was the number of the people in the class - not because the student:teacher ratio was poor (it was fine), but rather that so many folks were keen to learn Scrum. I was a bit surprised by that. Clearly it's way more popular than I imagined.

It's hard to understand why organizations still don't get it. Scrum is not perfect by any stretch of the imagination, and it's not easily to do, but it is eons better than waterfall. Why? Because:

  1. there will always be emerging requirements which need to be accommodated;
  2. written specifications are highly ineffective forms of capturing system details (verbal instructions and regular reviews of working software are far more productive);
  3. prioritisation of the features that offer the greatest immediate business value ensure the ROI of the system is maximized over the development life cycle;
  4. frequent, releasable deliverables means the customer can cut the project the minute they consider the system good enough - which can reduce the cost of the system;
  5. self-organizing, cross-functional, leaderless teams have proven to be effective in decision making;
  6. Project risk is lower because Scrum advocates visibility and honesty so last minute surprises and far less prevalent.

What appeals to me most is the fact that Scrum is based on empirical evidence more so than theories. Take for instance the task estimation process. Scrum advocates planning poker which is in effect an endorsement of the Wisdom of Crowds . By giving all the programmers who have knowledge of what's required an independent vote in the estimation phase, and reiterating this process until convergence, or agreement is reached ensures that task estimates include all collective input from the team and constitute a best-guess given that information.

With regard to written specifications Jens gave the class a series of insightful exercises where each team was divided into "programmers" and "spec-writers". The programmers then left the room whilst Jens presented the spec-writers with several diagrams that had numerous shapes on it - a few crosses, a series of congruent triangles, a rotated 5 point star, etc. You can see these diagrams here.  The spec-writers had to write written specifications and pass them to the programmers who were waiting outside and who hadn't seen what the image was suppose to look like. All communication was written and the programmers had pen and paper to implement the specifications given. At the end of the alloted time, very few teams had a finished diagram from their programmers that looked particularly similar to the original. After a few attempts it became obvious to our team that detailed, unambiguous instructions were damn hard to do. Our team resorted to frequent short instructions based on what we had seen the programmers do on earlier instructions. If you were clinging to the belief that detailed written specifications were all that was required to successfully implement a system this exercise blew that notion out of the water in about 15 minutes!

All in all I have to say that the Certified Scrum Master course through the Agile Alliance is well worth it. And now....woohooo...I'm a Certified Scrum Master :-)