For about the last ten years, most of the development shops I’ve seen and worked with are operating under a process that is Scrum-like on the surface. It’s standard to divide work into “stories,” to assign points to those stories, to organize time into “sprints” that are just about always two weeks, and to move those “stories” from left to right on a Jira board.

I have many, many things to say about how people mess up Scrum. A lot of it is embedded in the prior paragraph: they’re “Scrum-like” on the surface but they don’t even try to embrace the values of “commitment, courage, focus, openness and respect” that the Scrum Guide calls for.

I’ve been away from the “tech scene” for a little while. Other priorities got in the way of hanging out with other software people in any organized or ongoing way. And last week was a little sad, as all my regulars were out at CodeMash without me!

Very recently though I was prompted to check out a tech meetup. I showed up fifteen minutes early, but the program was advertised as being a half hour late, so it netted out to missing the first little bit. Maybe I missed something important.

The topic was a type of business modeling that works on many levels, which is great, but unfortunately the speaker brought his boardroom pitch and boardroom slides. So we, a roomful of implementors, were treated to an hour’s worth of what could have been titled “Why you, a CEO, should adopt this high-level management technique.”

It was a lot of drill-down. It would have been good if we had money and were thinking of hiring his firm to consult with us.

The most important rule of public speaking, which probably isn’t written anywhere but should definitely go first, is “Read the room.” The speech you give in a meetup of implementors is not the case you make to your boss in your annual review is not the testimony you give as an expert witness is not the war story you tell over drinks afterwards even if you’re conveying the same concepts.

A much better presentation would have been perhaps to start with a story, or two really brief stories, illustrating the management practice at a tactical project level. Show how it creates a win. Get people to notice that the thing you’re talking about is actually relevant to their daily lives. Then summarize the management principle you came to talk about and introduce a nice catchphrase that gives people a hook so you can easily shout it out later. Give a brief example of how your C-level people might apply the principle even though it’s likely to be above our pay grade. Then circle back and talk about how we might benefit from applying this principle directly, maybe using two or three clear steps that help us confirm that we’re on the right track.

Everything has to start with “So what?” and “Why are you saying this to me?” If you don’t establish those two things you don’t have an audience, you have a bunch of people who probably feel somewhat socially obligated not to walk out of the room.

More importantly though, I think you have an obligation. People have sacrificed time and energy to come hear what you have to say, and it’s your job to provide enough value to make that sacrifice beneficial. You’re obligated to make the time interesting, relevant, and useful.

And in the context of a gathering of tech implementation experts, that means not recycling your CEO pitch.

We just got hired as a jazz band, which is great. But there’s this one guy who insists on playing drums and only plays marching music. It’s the way he’s always played music and it’s all he knows. He is absolutely willing to play in the jazz band but will only play a marching beat. That’s okay, right?

I had a long talk with a new team last week. They’re doing a hybrid agile/waterfall approach on a project that needs tons of changes to reach viable status. My old pal Paul got in touch to ask me about some “intricate” issues.

This thing here, from veteran management guy Steve Denning–it’s Forbes, so of course there has to be an infographic that makes less sense than just explaining things.

All mockery aside, I’m seeing an important point here. The lowest-functioning corporations depend on coercion, threats, and “fiat” to get stuff done. If you’re a little more sophisticated and higher functioning, you evolve into “management tools” that aren’t so dependent on brute force to work: measurement systems, strategic planning, that sort of thing. That’s a lot better in many ways, because people respond better and feel better when they’re not being ordered around.

If you’re in that upper realm of “leadership tools,” using persuasion and role modeling to show your people the corporate goals and how to achieve them… that’s a fantastic step forward. But it only works if you discard those lower-level techniques that rely on intimidation.

Inspire all you want! But if the person at the bottom of the stack, doing the real work on the assembly line, at the customer service desk, or in a programming cubicle, is routinely coerced or punished–you have a bigger problem than can be solved with one or two workshops or planning meetings at management level.

I like this chart and plan to use it!

Read the full article though. Denning has some great insights on why Agile software development fails in organizations that don’t adapt on a larger scale. You have to cut out hierarchy and privilege, and if you’re not emotionally ready to let go of those things you are better off not pretending your development shop is “Agile.”

“Sucks” rules

Something I like to do regularly to keep my brain “agile” is to take something I like, add the word “sucks” to it, and Google the result. I found this on a search for “Agile development sucks”: Your Daily Scrum Is Killing Your Team, by J.B. Rainsberger. I didn’t know about J.B.’s work until now, but I’ll try to catch up.