Meetings

I found this note while cleaning up. I think it's a summary of John Cleese's short movie "Meetings Bloody Meetings".

1. Plan. Why are we meeting? What's the purpose? What are the subjects?
2. Inform. Tell the attendees what, why and the expected outcome.
3. Prepare. Create an agenda, with a time line, and the items to be covered.
4. Structure. If the purpose is to make a decision, this involves presentation of evidence, interpretation of the evidence and a decision. If the purpose is to inform, then present the information.
5. Summarize and Record.

I hear complaints about time wasted in meetings. This complaint is absolutely justified. I've wasted a lot of my professional career in dumb meetings.

Out of Touch Management. The out-of-touch manager requires long meetings in which each direct report provides a complete status report. The all-hands meeting appears to be the only time the out-of-touch manager ever talks to anyone. Consequently, it devolves to a sequence of one-on-one meetings which the rest of the team is forced to attend.

If the goal is for many people to inform one person, those conversations don't require a meeting.

Going Through The Motions. The going-through-the-motions manager is aware that a staff meeting is expected, but has nothing really to say or do. These meetings often devolve into awkward silences as open-ended questions are thrown out to try and stimulate some interaction.

If there's no goal (no decision, no information) then there's no purpose for the meeting.

Best Practice.

In the days before agility, I worked with two project managers who gathered information in one-on-one meetings. These are separate projects for separate customers. But the same best practice.

The PM would stop by your cube, figure out what you were doing, what you needed, what you were planning to accomplish. Then, at the ever-so-brief staff meeting, a few key interactions among the staff would be lifted up from all those one-on-one meetings.

Let's review the brilliance of these two PM's.

1. They stopped by your cube. They did not play the power game and make you come to their office. They stopped by. In later years this was called "Management by Walking Around" -- something hailed as brilliant. These PM's just did it.
2. They hung around long enough to actually get what was going on. They didn't waste time asking you to write and email status to them. They asked, listened, understood and summarized your status for you.
3. They recognized the needs for interaction and made them happen. The status meetings were like daily scrum meetings. Since they were weekly, they weren't as brief, but they were just as focused. No long status reports. No long conversations.

Objections.

Some managers don't have time to sit in everyone's cubicle. This overstates their value as managers by understating the huge cost of wasting everyone's time in serial one-on-one's done in a conference room. 12 direct reports means 13 man-hours wasted in a one hour meeting.

Some managers don't have time to write status reports. Instead they forward emails all day.

It's probably better to get off the email treadmill. Get status, write short, to-the-point status reports.

Focus.

Developers (DBA's, Sys Admins, all technical folk) live in a world of technology delivery.

Mangers, however, live in a world of budgets, status reports, and weird exercises in foretelling the future. ("How long will it take? How much will it cost?")

There's no good reason to impose the world of status reporting and fortune-telling on technical people. There are, however, lots of bad reasons for imposing unplanned, unprepared and unstructured meetings on a team that would rather be building product than talking about building product.

Code Kata Resources (Updated)

I've got a ton of exercises in the Building Skills books. Specifically, my OO Design book is based on my own personal Code Kata exercises.

Plus there's the established Code Kata resources. The CodeKata page, Mark Needham's blog posting on code-kata, Rizky Farhan's Collection of Software Projects, jp.hamilton's Code Kata Resources. The Coding Dojo page (which suffers from showing no usable URL's -- what a mistake.)

Plus there are the random problem sites: Project Euler, Top Coder, UVa, SPOJ, Google CodeJam.

I've done a few (63) Project Euler problems (I got stumped by problem 69). Another 37 and I'd be at level 3.

The question isn't "where are the problems?" The question is "Are these good Code Kata problems?"

Software Performance Improvement

Yesterday, I looked at some marketing material on SPI (Software Process Improvement). It was quite good. The approach was very pragmatic, the deliverables very sound.

The hard part is connecting with customers.

I've only worked with a few customers who were actually interested in process improvement. I've worked with close to a hundred customers who were interested in process enforcement, usually called "compliance".

Laurent Bossavit's Learning Notes has this entry, filed under "Four types of process errors".

Of course, what actually matters - what is worth discussing - is what people actually do. A 10-page process document or a flowchart are nice, but generally irrelevant unless they match very closely with what people actually do in the pursuit of shipping software.

In thinking about SPI, one has to find a way past the Core Hubris™. Bossavit identifies four types of errors. His are all focused on projects that "produce a bad outcome". We'll have to put this on one bucket, the "problem recognized" bucket. We'll rename Bossavit's Type I to Type IV as Type R-I to R-IV because a problem was Recognized.

The Language of Denial

What he misses are the process errors that "produce a questionable outcome". In this case, the outcome can be declared good by the manager that produced it (it went into production) or declared bad by the manager that maintains it (quality is appalling.) These are far, far more insidious and pernicious errors than the four he ties to a bad outcome.

Delivery is all that matters, right? If it goes into production, how "bad" can the outcome be?

The answer is -- sadly -- pretty bad. I'm often asked to work with production code that should have raised red flags, been identified as a bad outcome, and lead to serious questions about process improvement. And yet, there's no question raised at all.

Worse, I'm often asked to follow the process that lead to the horrifying code and the need for rework. What created the mess we're reworking? A flawed process? Why, then, must our proposal swear undying fealty to the broken process? So we can fail yet again?

Even worse, we're sometimes asked to follow a process for which there is no example. "Produce documentation like this," I'm told. Followed by, "but that's not a good example of what I mean." It turns out, there is no example of anyone ever following the written process. But, we're expected (no required) to comply with a process that has a nebulous definition and no examples.

Some Questionable Outcome Errors

I think there are four variations on the theme of process errors. We call this class "Q" errors because there was a questionable result. Not a recognized problem but a shadow of a doubt.

• Type Q-I error (blame) is when you don't follow the written process, produce a questionable outcome, and blame non-conformance. The point here is that we don't ask why the written process was not followed. Why is the actual process different? Is it a mistake, or is the written process unusable as written?
• Type Q-II error (fudge) is when you don't follow the written process, produce a questionable outcome, and declare the situation to be exceptional. Either the technology was new or the business problem was not well understood. (Note. All interesting projects have one or both features. If the technology was understood and the business problem was understood, you could download an open source solution.)
• Type Q-III error (denial) is when you don't follow the written process, produce a questionable outcome and ignore the gaps between written and actual. No proposed changes. Nothing. Just business as usual.
• Type Q-IV error (insight) is when you don't follow the written process, produce a questionable outcome, and ask two questions. "What was so wrong with the written process that we didn't follow it?" and "What was wrong with what we actually did?" (Note. I've never seen this happen. But that's just me.)

Marketing Past the Hubris

There's a Core Hubris in many software development organizations. It's a presumption that, since they have stuff in production, they know how to deliver more stuff.

Indeed, in many organizations, SPI dies an early death because of the Core Hubris. They already know what they're doing. They don't need any help with that. This is why the blame-fudge-denial errors are so common.

The Core Hubris is also why shoddy code goes into production. There are three paths a project can take.

1. The High Road. The processes mostly work, are mostly followed, and code is produced that has reasonable quality and gets delivered.
2. The Low Road. The processes don't work well or aren't followed and code is produced that's questionable. It's put into production anyway, victory is declared and little, if anything is learned.
3. The Blocked Road. The processes don't work or aren't followed and a bad result is produced. Almost without exception, this means the project is cancelled early. Deeper questions aren't asked because the reasons for cancellation aren't well understood by everyone involved. One day you're working, the next day you're reassigned.

Paths 2 and 3 (the Low Road and the Blocked Road) are both places that need SPI. There are several marketing problems to overcome.

Getting Help

First, will they acknowledge the problem? Probably not. If you've delivered anything -- no matter how bad -- you don't need help. Further, you have two layers of the organization that need to acknowledge the problem. Management needs to recognize that they're wasting money on shoddy quality. Staff needs to recognize that they've got quality problems.

Second, will they ask for help? Probably not. Most of the process errors involve deflections or denials. To seek outside support for something as "simple" as software development is a defeatist attitude. It doesn't matter that software development actually is very hard. What matters is that it shouldn't be so hard, and asking for help is career suicide.

Third, will they follow through on the help? Probably not. Change is disruptive. It means grumpy people complaining about the 8:30 AM Scrum stand-up meeting. It means grumpy project managers having only one or two sprints carefully planned down to the last 6 minutes of activity, and the future sprints are unplanned. It means grumpy business analysts complaining about being forced to focus on just a few use cases and get those right, leaving the "big picture" to fall into a black-hole. It means grumpy DBA's complaining about an evolving data model. It means grumpy programmers complaining that unit test code is not deliverable and is a waste of time.

Management can -- and often does -- act schizophrenically around improvements. They both (a) demand improvement and simultaneously (b) demand that the improvements be subverted in order to deliver "on time".

What to Sell

I think the marketing message for SPI has to be something along the following lines.

Is your software actually perfect? Is maintenance easy? Is adaption and migration a simple administrative step?

• Are you sure? Do you have evidence? If not, perhaps your processes aren't as perfect as you wish.

Do you scramble to deliver something that works? Is maintenance always more complex than you thought? Have you ever had to reverse engineer a system to replace it?

• You might want to consider improving your processes.

Have you failed to deliver?

• You need to reconsider your processes.

Do you have code that's both an asset and a liability? Is it so valuable you need to keep it in production, but it's in such bad shape that maintenance is an expensive nightmare?

• The root cause is process problems. Address the process issues and you should be able to reduce maintenance costs, or get better quality results for your maintenance spend.

This, I think, is the target audience for SPI services. Most IT people think they're successful. I've seen their worst code, and I disagree.

By worst I mean the following: So valuable you can't throw it away and so broken you can't maintain it yourself. This code is a costly, risky burden on the IT organization but still creates value for the enterprise as a whole. Flawed processes put it into production, and flawed processes prevents effective rework.

The folks that understand that merely delivering may not be enough are the folks that might consider SPI services.