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

Scott’s comments from the Berkun reading group group.

Shiran: you're right about the features/bugs labels. It's arbitrary, but every team sorts out for themselves where the line is. It almost doesn't matter as long as there's a line everyone agrees on.

I was surprised when I worked at WordPress.com they didn't have many bug tracking tools, and the ones they had weren't used consistently. But to their advantage since they use continuous deployment the spin rate for finding issues and fixing them is generally fast (except of course for the issues no one wants to fix that don't quite rank high enough to be dealt with immediately).

Thanks Ravi. You deserve a special prize for hanging in there! Appreciate you going the distance.

#2 is so tricky in practice. How much detail is enough? There's a lot of faith based beliefs about the answer, but generally it depends on the team, how much they're worked together, and how self-aware they are. There's no single answer. If I were making an airplane I'd want different exit criteria than a airplane iPhone game.

Data misuse is a rampant problem - I wrote about it here:
http://scottberkun.com/2013/danger-of...

Shiran: On complex projects you're right, but simpler ones you can just use your judgement. if you were mowing the lawn you'd know intuitively what the critical parts were (say, the path to your driveway).

You're right about balance though. If you bury people in the hardest work first they might not have the morale to want to continue.

Start here.

Start here.

This is one of those chapters that could have been in a completely different book. I've actually thought about a pm-ish book that was all topics like this one - about behavior more than anything else.

> How can we teach or train new PMs to look for these patterns
> or apply these tactics if they've never experienced them?

I don't know that you can - I spoke to a PM class today and told them much the same thing. There are many skills you can only begin to appreciate, much less get good at, by being in them. You have to experience it. I suppose a book could offer more hypotheticals ("imagine you're on a project...") but that's a stretch too since imaginations depend on experience too.

I'm glad my advice here made sense to you. It seems so obvious to talk to people one on one, and that it changes things, but many people think it's too trivial a thing to make a difference.

Start here.

Start here.

It's quite a mystery why trust is so rare. It seems so obvious and it's easy to talk about, but yet most teams and workers struggle to build and maintain it.

I like the notion that trust builds up resistance to adversity - I'd forgotten about this. That although trust is expensive, it takes time and effort to build, the reward is countless situations where things go far smoother in difficult times that they could possibly without trust.

It's one of my favorite chapters too. There was a time while writing the book I thought it should be the first chapter of the book itself. Some projects and organizations are always being managed as if it's a crisis (even if the people involved don't think of it that way).

Exhaustive lists are tough to write since projects are so different, especially if you're thinking of not just software projects, but engineering and construction projects too.

I haven't looked at Rapid Development in a long time, so that's a qualified yes :) Another good book on situations, although it doesn't often a list, is Roundtable on Project Management. http://www.amazon.com/Roundtable-Proj... - each short chapter is a tough situation, and you get to hear advice from a range of different experts. It's a fantastic book, but it's not going to directly provide a situational checklist.

Be curious. Be generous.

Be curious. Be generous.

It can be hard to talk about roles - especially if you're not in charge. It's just an awkward conversation to start so people avoid them. But whenever I start working with someone knew a question on my mind, and that I'll often say, is "how do we work best together? what do you expect of me and me of you?" - even if what's said is predictable it reaffirms those beliefs and makes it easier to refer back to that covenant should things go wrong later.

Shiran: much like specs, every team is different and the way you track anything needs to fit the culture of the team.

At minimum you should keep decision notes for yourself - a short summary of important meetings or decisions. If you like make it public so other people can see it and comment on it. If more people participate do something more formal, if they don't, then use what you like.

This is a chapter for me that had some themes that didn't age well. The Year Without Pants (published 2013) was about an organization that didn't use email at all and I learned much from working there and how tools only matter so much - it's the communication habits people have that matter much more.

I've come to think that places that communicate well learn the behavior from leaders - it's their behavior that matters. And if they care about good communicators they hire for it. If the boss is a poor communicator and doesn't hire for it, no tool can fix the culture.

I'm currently fond of Slack, which is what Automattic uses now (they used to use IRC). It's a great example of how some of what makes email annoying on a team can be refit into a different tool for a far better experience.

Here we go.

here we go.

Learning to manage emotions is so often overlooked - thanks for mentioning it.

It seems many people are in denial about their emotions, which makes them far more dangerous as decision makers. Having some outlet for expressing those feelings, or even just venting pent up ones, goes a long way to helping people be better decision makers. It's not always a problem of intellect - it's often something much simpler but far less acceptable (sorting your feelings out).

There are different kinds of trust to have with people, and one is "can I express my feelings without feeling judged by them"? If you have no where to express and then sort out your feelings you'll always be a slave to them.

Everyone wants to skip ahead :) I don't blame engineers - you want engineers who want to build things. But if they've worked on a few projects they're inevitably experienced getting burned by jumping too quick into coding.

The answer then is trust. That engineers trust designers that their patience is warranted, and designers trust engineers that their patience shouldn't be abused.