The problem with "fail fast" is that it too often becomes "move fast." Failure is hidden or spun as success, speed is rewarded, and the learning part gets lost entirely. At its worst, "fail fast" is an excuse to rush into the next thing without pausing to understand what just happened.
What I want to promote instead is Observe Often. The shift in language is intentional—when we say “observe,” we bring focus back to what matters: seeing, measuring, and learning from what we do. And “often” reinforces frequency over haste. It’s not about reckless speed; it’s about small, deliberate moves and frequent feedback loops.
When I say I’m joining Test Double as their new VP of Delivery, I’m not just making a career move—I’m making an alignment move. This is a company that already values the things I value. They’ve built a strong culture, a strong team, and a strong set of practices. I’m not joining to overhaul anything. I’m joining to help make something great even better.
Today, I’m excited to announce the beta launch of Collaboration Contracts, a lightweight app designed to help teams—especially distributed ones—quickly define and manage their roles in decisions. Whether you're using it to bring clarity to one-off decisions or baking it into how your team operates every day, the app is built to support alignment, accountability, and smoother collaboration.
The Experiment Canvas is a simple means of planning, tracking, and responding to your experiments.
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.
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.
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.
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.
It ain't easy slinging code
Over the course of my more than twenty years in the software development industry, I've worked with hundreds if not thousands of developers. Many of the projects I've been involved with have suffered from the same malady; a disconnect between expectations and realistic possibility.
Michael Nygard tweeted
'The phrase "business value" seems to hide uncertainty behind vagueness. Can we just say "money" instead?'
I disagree. Or more accurately, I disagree with what I infer Michael means by this single tweet. I cannot say with any certainty what he meant, much less address the context of or inspiration behind his statement.
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.
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.
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.
I've been on numerous Agile projects with varying methods for capturing stories. Quite popular (and purportedly the ThoughtWorks standard) is the "As a, I want, So that" story format.
While I have seen teams do well with this format, I think it can be radically improved with a minor change. I prefer to see "So that, as a, I want" story format.
My reasoning is quite simple; the emphasis is incorrect in the common story format.
A chain is no stronger than its weakest link. Metaphorically, this applies to teams. But in actuality, this is simply not the case. Humans have not only tenacity, but the ability to countervail one another. This is a quality that inanimate objects simply do not possess. We can and will compensate for one another for the good of the team. Links in a chain are incapable of sharing their strength. No other link can compensate for the weakest.
Measuring and reporting are important
I've often heard said, "That which you cannot measure, you cannot improve." And while I do believe this is a general truth, I think it fails to tell the entire story. It is not just about what we can measure, but what we actually do measure that is significant; "That which is reported, will improve."
