Scott’s Comments (group member since Feb 26, 2015)

Scott’s comments from the Berkun reading group group.

There was a big trend in the late 80s called expert systems - the idea was: why can't we use basic AI to model what experts know about their expertise and use that instead of the experts? It turned out that for troubleshooting a car or the plumbing of your house, these systems were helpful, but for truly complex/subjective skills like management or leadership the results were never as good. Good managers and leaders are rare - and it's not because of lack of knowledge, there are simply too many subjective variables to abstract the skill into simple rules.

On the positive end there are books sort of like what you are after. My favorite is: Roundtable on Project Management. Each chapter is a discussion of a type of issue, with different thoughts about common tough situations for that issue and opinions on how to solve. It's not a checklist, but it avoids the trap of checklists (this book never tricks you into believing there is a trick or secret) - http://www.amazon.com/Roundtable-Proj...

Kye: you might feel behind but you're the first to comment on Chapter 4, so kudos to you :)

The challenge is every organization and team are so different. To have one checklist for everyone would either be too generic to be useful, or too heavy to be easy to use. The burden is always on the team leader to do some thinking for each project.

On visualization: there's a quote by Mike Davidson that I like:

"A prototype is worth 1000 meetings"

Designers know this. A sketch, a screenshot, a drawing, all compress so much information and decision making into them and generate far better discussion that 30 page specs do. But since most managers and engineers have so little design training they prefer other means, despite how much more effective it is in this case to show and not tell.

The only approach I can see working is a workbook that was really short and simple, and focused on questions you, as the project leader, have to ask yourself.

Siim: I'm always dubious of extreme positions on anything. NoEstimates presumes that there's never a good reason, which I think we all agree isn't right. Sometimes doing careful estimation is worthwhile or necessary and sometimes it isn't. It's another kind of a judgement a good leader has to have: deciding how much up front thinking or planning will help or hurt a project given it's unique goals.

I hear crickets here - has no one survived to chapter 4? Oh Noes!

Thanks Ravi!

What did you find most/least useful in chapter 4? The discussion and commentary begins here.

Maya: I never think the tools are the problem - if a team runs well, with people liking their roles and trusting each other, Skype works great for most situations with remote workers. The problem is when you have too many people who want to be involved in planning (a problem with roles), or are afraid of getting left out (a problem with trust). No tool can fix that - it's a leadership and relationship challenge.

The terminology in this chapter could use updates, but I don't think it's hard to translate (of course I'm biased :)

Welcome Andrew! Curious to see how well the book holds up for you.

Shiran: Hit me up here and I'll get you a copy http://www.scottberkun.com/contact - if you want kindle I can get it to you instantly :)

Ravi: the project manager you mention likely excelled at politics, or managing relationships, and that's the real killer for requirements - they're tortured by the political pressures in the org. Unless a leader can defuse them the method used won't matter.

I'll check out that article.

(Thanks Lisa!) I'm just happy folks have shown up so far. I'd say I can use more criticism - what did I get wrong? what sections haven't aged well? I'd like to come out of this with notes for a free e-book I can write or new chapters to give away.

Still alive? Good. Lets talk about chapter #3 on figuring out what to do.

Rachel: The balancing act thing has always stayed with me as it's both the fun and tough part of the job. You can do many things right and *still* fail. it's not a role for people who want easy and clear measures for success!

Ravi: Given what you know about Agile/Scrum did this chapter hold up well for you? There are some things I'd couch differently, but I thought the core ideas held up well regardless of what methodology was being used. Do you agree/disagree?

A team that can't openly discuss failure is doomed to repeat it or worse.

Ravi: I do like the idea of velocity from Agile - that there is a real pace you can measure about how a team works and that data should drive the next iteration That kind of thinking of trying to use real data from real work to drive predictions is exactly what's missing from all the old school, PMI, big-project, type estimation thinking that's still popular in the software and general project world.

Todd: those dichotomies might be my favorite part of the book. Good leaders balance contrary ideas and so many people in leadership roles believe they don't have to face these balancing acts.

On bad managers - Automattic, where I worked for a year to write The Year Without Pants, doesn't pay team leads any more than individuals. They wanted to remove the financial incentive so that only people truly interested in leading take on the role. It's an interesting idea:

http://scottberkun.com/2014/what-if-m...

Shane: My favorite part about The Checklist Manifesto that many people overlook is how hard it is to write good checklists. Often they're ignored and there are sometimes good reasons workers ignore them. They are a great way to capture wisdom and inside knowledge, but like all tools they are easily abused. So "too many" was the key notion I was after. In other words, there should be a checklist to use when writing a checklist :)

Kye: Glad you were surprised :) The boredom might you feared might occur in chapters 14 & 15 - if memory serves those are the densest chapters in the book. I often tell people who aren't working on a big software projects to skip them if they don't find them applicable.

"If everyone can agree that the schedule is a set of probabilities, the problem isn't in the schedule itself - it's in how the schedule is used"

This was often the primary mistake I'd see teams make - they took schedules as a kind of gospel and never questioned them enough - the schedule is supposed to help the project, it's not a sacred cow.

Alex/Jack: Welcome aboard! The first chapter is short so it should be easy to catch up quickly.

George: It still seems true that we all want a mathematics to work with people and projects to get around the human part. Maybe it's a blind spot of a field that's dominated by introverts?