Read Next

Agile Scrum: Delivering Broken Software Since 1991

Update: This is quite a long article. If you're looking for a quick read, it breaks down a bit like this:

Update 2: There are active and interesting discussions of this article on HackerNews and Reddit

I have a lot of love for Scrum, the software development process. I have my own little box of Index Cards and Sharpies, and I have sized Backlogs for many of my side projects. Scrum has potential to empower developers more than almost any other set of techniques.

But in almost every implementation of Scrum I've seen in The Real World™, managers are incentivized to help their team deliver broken software to a deadline, and usually end up succeeding in the former and failing in the latter. And when implemented like that, a system that should be an absolutely overwhelming win for developers becomes a tool to beat them around the head with...

So here's Scrum, simplified, and as it's meant to work: You have a Backlog of work to complete, broken down in to Stories, which ­are distinct pieces of work that should take a few hours to a few days to complete. These are frequently displayed on a Story Board, real or virtual.

What Shape are You?

On Made of Metaphors

My post before this was a kind of therapy / Buddhism / personal growth kind of deal, but I also spend a lot of time thinking about how to run effective teams and to be a responsible, thoughtful manager of people. It is my work: I am a lead engineer at Bungie, an independent video game developer of about 300 employees (though not for long, we're growing.) There are some unique aspects to making videogames, and I'll use game development terminology here as I refer to, say, texture artists or sound designers or programmers, but when I talk to friends in different creative industries - film, industrial design, other software development - I find these themes are pretty universal.

If you're going to manage people, you're going to have a lot of conversations about employee performance. It's just bound to happen. Sometimes, like during reviews, it might seem excessive. You might wonder if's worth all the time it takes. It is. It's OK that you spend a bunch of time on this. As a manager, that is your job. It's your job to have well-formed opinions about how you evaluate people and how you work with them to help them grow. If you aren't spending time on that, then you may be succeeding as a leader, but probably not as a manager. Apples and oranges.

It is, however, important to spend this time well. During conversations about performance, everything you talk about should boil down to one thing: the value they contribute to the team. What is their value, and how can they become more valuable?

I find a lot of review conversations tend to focus on strengths, weaknesses, and specific work results. These seem like reasonable topics, and there's value there, but I also find this often leads to a review that looks like this:

Rendering New Theme...