Doc Norton
An Experiment Canvas

The Experiment Canvas is a simple means of planning, tracking, and responding to your experiments.

An Experiment Canvas
Doc Norton
Create simple things in small steps

Simple Things

When I say simple, I don’t necessarily mean easy. And I certainly do not mean crude in form or incomplete. Simple indicates something that does not have superfluous parts or multiple responsibilities, is easy to understand, is as independent from the rest of the solution as possible, and meets a need as is.

Simple may not address all use cases, but it does address some use cases.

Create simple things in small steps
Doc Norton
The Behaviors

Over the past several years, as I’ve been helping teams and organizations improve their ability to deliver software products that are desirable, viable, and feasible, I have been experimenting with a Behavior Framework that has proven to be rather effective. And I’d like to share it with you in hopes that you find it useful and that you provide me feedback on your experiences with it.

Doc Norton
Beginning a New Book

My plan is to write a series of blog posts all related to the behaviors framework. Some of them will be about a specific behavior. Some of them will be about tools or techniques that help teams express one or more of the behaviors. Some of them will be my own experiences. And some will be damn near complete fiction.

Doc Norton
What is Velocity?

In this excerpt from Escape Velocity, we take a more in-depth look at Velocity and try to answer (at least in part) the question, “What Is Velocity”?

What is Velocity?

Esther Derby asks: Are we aiming too low?

Esther Derby put together a nice post on the importance of design for a web site in which she asks, "Are we aiming too low?"
 

Agile methods manage business risk. They can bring back enjoyment and pride in work for development teams. For the people who use our software, they make work life maybe less frustrating, because the software isn’t buggy, and maybe a little easier because the software does what it’s supposed to do. But I think we are aiming too low. Can we also make software a pleasure to use?

Values Revisited

In 1992, I started a custom software development company out of my basement. I started it because I was angry. At a relatively young age, I was already keenly aware of the gross dysfunction that existed in most organizations. I didn't want to be a part of that. I wanted to be a part of something different; something better. I had no plan, but I had an abundance of temerity.

Motivating the Unmotivated

I read a post recently from teknophyl entitled "Motivating the Unmotivated". He asked me to read it and give him some feedback. I started a reply in the comments and realized this one was going to take some time.

I encourage you to read his blog entry. I am willing to bet it will resonate with most of you, either as a participant in a similar series of events, or at least as a witness.

Excellent Developers Are the Best Hires

I recently read a post wherein the author was condoning the hire of excellent programmers with abrasive personalities over bad programmers with cordial personalities. Superficially, I agree with this advice as it is ultimately better to have an individual who does their job well and delivers over an individual who you get along with very well, but who cannot produce.

A false dichotomy

The notion that you must choose between great developers with bad personalities or bad developers with great personalities is just plain false. The dynamics involved are far more complex than that, but let's assume for a brief moment, that there are only two criteria any company hires on; raw skill and congeniality.

Roshambo Estimating

This is a quick post. I just want to share a technique we've been using for initial story estimating. I first used this technique at ThoughtWorks when we were working on a project that required a lot of estimating. I think it came about because 1) we did not have any estimating cards immediately available and 2) that is the kind of place ThoughtWorks is. I later came to discover that the technique is not only fun, but it actually has a few additional benefits.

Take Control of your Development Career

I got the opportunity to do a little road-trip with my daughter this past weekend. I had an opportunity to speak at the Carolina Code Camp. They accepted all three of my submissions, so I figured I should make the trip. She spent a couple of semesters at High Point University in North Carolina and was looking forward to seeing some friends, so she offered to come along.

The trip was great. We had a total of fourteen hours together in the car, which gave us plenty of time to catch up, talk philosophy, talk a little politics, and just hang out. If you think fourteen hours is a lot of time to fill talking, you haven't met my daughter or me. Separated, we are fairly loquacious, but together, we can get into a zone and move from subject to subject with nary a pause.
 

The Technical Debt Trap

I had the honor of presenting at Chicago Code Camp this week on the topic of technical debt. For those of you who know me, you know this is a topic I feel passionately about. More accurately, I am concerned about the misunderstandings surrounding technical debt and the frequent use of the term to placate any sense of responsibility over writing messy code in pursuit of a deadline.

Optimal pairing

A while back, I posted a rambling entry about the impact of Harmonic Mean on a team's performance. The post was actually about pairing. My intention was to put a solid mathematical, albeit only pseudo-scientific, explanation behind my paring recommendation, but I think I lost several people (including myself once or twice) in the math and all the fancy words.

In short, whenever you pair two people of disparate skill sets, their contribution to production is more heavily influenced by the lesser skilled or experienced of the two. And the impact is significant. The greater the disparity in skill/experience, the more significant the impact.