It all started with Snow Crash.

If I hadn’t read it and fallen in love with the idea of the Metaverse, if it hadn’t made me realize how close networked 3D was to being a reality, if I hadn’t thought I can do that, and more importantly I want to do that, I’d never have embarked on the path that eventually wound up at Valve.

By 1994, I had been working at Microsoft for a couple of years. One evening that year, while my daughter was looking at books in the Little Professor bookstore on the Sammamish Plateau, I happened to notice Snow Crash on a shelf. I picked it up and started reading, decided to buy it, and wound up devouring it overnight. I also started thinking to myself that I had a pretty good idea how about 80 percent of it could work right then, and wanted to implement it as badly as I had ever wanted to do anything with a computer – I had read SF all my life, and this was a full-on chance to make SF real. So I tried to start a project at Microsoft to do a networked 3D engine.

Last summer, I had the good fortune to visit a “very advanced” Agile shop. These folks really did embrace agile methods with a discipline, completeness, and a zealous fervor that would be hard to match. In many ways, they could have been a poster child for Agile methods...But these weren’t productive developers freed from mindless process dogma. They were Agile slaves. The dogma they followed was ours, and they followed it well. And as with many organizations in a similar position, they saw some promising results. Continuous integration, refactoring, unit tests, pair programming—all these techniques yielded some benefit. But they weren’t thinking, they weren’t reacting, they weren’t being agile. When problems came up, they addressed them with all the grace and elegance of a deer caught in the terrifying blaze of alien headlights. They knew how to do Agile; they didn’t know how to be agile.

Theme One: Do not, under any circumstances, start a startup.

This is, of course, tongue in cheek. But more than half the speakers said, in one form or another, do not start a startup. The summary went something like:

Don’t start a company just for the sake of starting a company. Don’t start a company because it’s cool. Don’t start one because you think it’s going to turn out like it does in the fictional movies, because it won’t - death is the default for startups. Don’t start a company because you want to be like the founders you see at startup school, or want to be the “next [fill in the blank].”

OK, animators. I know the deal. You guys want to be the next Brad Bird, the next John Lasseter, the next Jennifer Yuh Nelson, or the next Glen Keane.

Well, don’t we all. But here’s the problem. Instead of concentrating on the craft that you so passionately want to blaze a trail in, some of you are concentrating on figuring out how to become the next amazing director. While some of you are going about this endeavor in a respectful and proper manner, some of you are doing it wrong.

In fact, by my completely unscientific count, there are 99% of you doing it right, and 1% of you doing it wrong. It’s not just animators, either. It’s just about every discipline in this and other industries. So to the rest of you, when you read “animator,” fill it in with your specialization!

As the 21st century approached, luxury automakers faced a technical design challenge: an increasing array of new in-car devices--phone, GPS navigation, digital radio, satellite radio, CD changers, Internet access, television, emergency notification, side and rearview cameras, and driving system settings--was turning dashboards into an unfathomable mess. Automakers were forced to rethink how drivers interface with cars.

What’s your immediate response to the idea of replacing all management in your company with leader boards and badges? Does it scare you? Does it make you angry? Does it seem so ludicrously Machiavellian that you laugh in disgust? Good, me too.  The more I think about this the more I like it the more I LOVE IT! It sends chills up my back and makes me want to run away screaming. It’s that good.

The neat thing about The Joel Test is that it's easy to get a quick yes or no to each question. You don't have to figure out lines-of-code-per-day or average-bugs-per-inflection-point. Give your team 1 point for each "yes" answer. The bummer about The Joel Test is that you really shouldn't use it to make sure that your nuclear power plant software is safe.

A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time. 

I was employee #20 at the first start-up and the first engineering lead. Over the course of two years, the team and the company exploded to close to 200 employees. This is when I discovered that growing rapidly teaches you one thing well: how communication continually finds new and interesting ways to break down. The core issue being the folks who’ve been around longer who also tend to have more responsibility. As far as they’re concerned, the ways they organically communicated before will remain as efficient and simple each time the group doubles in size.

They don’t. A growing group needs to continually invest in new ways to figure out what it is collectively thinking so anyone anywhere can answer the question: “What the hell is going on?” This is the first question The Rands Test answers. As I’ll explain shortly, the second question The Rands Test helps you answer is selfish. The second asks: “Where am I?”

Because the platform is new, developers have to learn its ways before writing many of those apps. So to add them quickly, Microsoft has taken an unusual step. It has relaxed a strict rule and will let employees moonlight in their spare time and keep the resulting intellectual property and most of the revenue, as long as that second job is writing apps for Windows Phone 7-based devices.

The daily stand-up is a window into the motivation level of the team. Stand-ups with motivated teams are noisy, complex, often chaotic, and information rich. They often seem like football huddles when the score is tied and there are no timeouts left in the final two minutes of the game. There is humor, intensity and a sense of "being in it together".

The stand-up meeting for an unmotivated team is different. It's common to sense the boredom or an impatience for it to end. It often feels like a group of individuals reporting to the ScrumMaster, who is writing everything down, or even worse, with everyone sitting at a conference table looking at a projection of a spreadsheet on a wall and only paying attention when it's their turn to report.

A tedious daily stand-up meeting is a symptom that the team lacks one or more of the factors of intrinsic motivation. It's often easiest to examine the team's autonomy and the practices of the ScrumMaster, whose role is to foster and grow autonomy.

In Scrum workshops, I often ask developers if they have ever compared the game that they last shipped against the original design document. The usual answer is that, except for the title, much of the design changed during development.

Facebook engineers decide what they want to work on and are allowed to make changes across the site without asking for permission.

Joe Bork has written a great article explaining some of the decisions that go into whether a bug is fixed or not. This means that I can cross that one off my list of potential future entries. Thanks Joe!

But while I'm at it, I'd like to expand a little on what Joe said.His comments generalize to more than just bug fixes. A bug fix is one kind of change to the behaviour of the product, and all changes have similar costs and go through a similar process.

I make fun of systems designers a lot because I am one. I wear a lot of hats, and I actually love to code, but deep down, it’s all about the game systems.

People who think like me are really useful to have on your MMO team. They won’t just dig into the guts of your game, they will revel in the guts of your game, sorting them this way and that, modeling them in myriad ways. This will, generally, result in a better product.

But they won’t ever come to the producer and say, “Okay! The balancing is all finished!” Trust me: that will never happen.

Community management isn’t what it used to be.
Once upon a time, managing a community meant hanging out in an online location – be it a forum or a chat room – and moderating chat. Approving comments. Handling some support issues. Dealing with trolls, helping people with questions. That kind of thing.
But community management, at least the way we approach it, isn’t just online issues management and discussion moderation anymore. It’s a far more fundamental business role, one that ties together responsibilities from a number of different places, both online and off.

This week The McKinsey Quaterly asks: what does stimulating the creativity of animators have in common with developing new product ideas or technology breakthroughs? Apparently, a lot.

Agile Logic helps companies deliver better software faster. Our unique Absolute Agile approach blends the best lean and agile methods to reduce risk, maximize benefits and ensure continuous improvement.

Kevin Schlabach posted recently on his Agile Commentary blog about using a "Snake On The Wall", a lightweight approach he's used to help his team get a handle on the things that are slowing their development process.

INVENTool ist eine frei verfügbare Toolbox, die Ihnen Denkwerkzeuge für die methodische Bearbeitung von Problemen zur Verfügung stellt. Diese Tools bieten wir Ihnen als informative Beschreibung, als eigentliches Arbeitsinstrument sowie mit weiterführenden Hinweisen und Beispielen an.

Tim Bray gives amazing advice on what techies can do when times get tough.