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.
It was 1983 and I was in science class when I first heard the term entropy.
I don't recall if we were discussing energy conversion, heat as waste, or some other topic wherein entropy plays a part, but I do recall how profound the concept of entropy seemed to me. The notion that there was a lack of order, a lack of predictability, and a gradual decline into disorder resonated with me deeply.
I've been thinking quite a bit about estimations and our general obsession with getting them "right". After all, we need to know when the project will be done. And we need accuracy. Knowing the entire project will be done before the end of the third quarter isn't good enough. We need to know that the project will be done this month or this week or perhaps even on this specific day.
In a discussion on the Agile Alliance Linked In Group, Michael Moles asked how refactoring fit into the agile process.
The Question
Refactoring: How does it fit into your Agile process?
We are in the midst of writing a new product, at this point the developers are realizing that some of the code should be refactored to improve performance and or clarity for ease of use. How do you fit refactoring into you Agile process? We have created separate backlog items for refactoring specific pieces of code. These backlog items are treated exactly like any other backlog item (meaning they have effort assigned and are committed to sprints by the team). What do you do when refactoring is necessary?
Earlier this week, Bob Marshall (@flowchainsensei) retweeted an article by Dan McCarthy on The Meaning of Respect, where he discussed respect as a value. I then saw a blog post from Seth Godin entitled "Seven Questions for Leaders" where he asks if you would walk away from a client or employee whose values don't match yours. This weekend, at Agile and Beyond, I got into a conversation with several others about company values and walking away from clients when there is a mis-match. At LeanDog, we proudly display our company values and we often refer to the XP values of Simplicity, Communication, Feedback, Respect, and Courage.
Have you ever been on a team where your velocity suffered wild variances? Maybe you ended up using a running average instead of yesterday's weather?
Have you heard phrases like, "Well, our velocity last iteration was 3, but our average is still 22"?
Have you ever heard the phrase, "Dude, we need to get this velocity stable."
Have you worked on teams where they took partial credit for done at the end of the iteration? Where maybe you'd split a card strictly on points and award some apportion to the current iteration and assign the remainder of the card to the next iteration.
I really enjoy pair programming. It seems a natural process to me and I often wonder why it is that I like it so when others may not. Clearly, we have differing tastes and styles. I am sure that contributes to the joy (or lack thereof).
I've been watching others pair lately. And there is something I've noticed; pairing done well is conversation.
I like to practice my craft. I enjoy participating in Code Retreats. I enjoy facilitating Code Retreats. I like working on kata and koans. And a lot of what I talk about includes references to these practices. We at LeanDog are always on the lookout for people who are passionate about improving their own craft. I thought I'd start a blog entry where I catalog resources that might be of interest to others looking for ways to sharpen their saw.
There's an old saying
Practice what you preach
Practice what you preach is a variation of Practice yourself what you preach. I think we are all familiar with the phrase. I suspect most of us understand the basic sentiment upon first read.
This phrase addresses hypocrisy. It originally spoke to those who demanded others be pious while themselves partaking in sinful activities. It certainly applies to anyone whose personal life is lived in a manner incongruent with the values and behaviors they publicly espouse.
Leadership is neither assigned nor selected. People choose whom to follow and a leader thereby emerges.
“The led must not be compelled, they must be able to choose their own leader” - Albert Einstein
We always have a choice. We may not like our options. We may feel we are choosing the lesser of two evils, but nevertheless, we follow at a minimum because we choose not to do otherwise.
“The man who lets a leader prescribe his course is a wreck being towed to the scrap heap.” - Ayn Rand
It is nearing the end of the year and we at LeanDog are wrapping up our fiscal year. We're looking at the potential tax benefits of spending some of our reserve and we're mulling over other ideas related to the spend of money. We are not, however, discussing our bonus objectives. We aren't discussing them because we don't have them. I, for one, am happy that we don't.
Plenty of companies have bonus objectives. Many of those companies are spending a great deal of time (and money) trying to make sure that those objectives are met (or at least appear to be met). To some, this sounds like a good idea. To me, it sounds like rampant dysfunction.
