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?

Would you be willing to preach what you practice?

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.

You are a Leader

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

What are you rewarding?

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.

Keep your ears, your eyes, and your mind open

Developers shouldn't specialize

Davey Brion wrote a post not too long ago warning developers about the dangers of specializing in a particular technology.

The real message

Davey concludes his post with the following paragraph:

"Keep your ears, your eyes and your mind open. If you notice that a group of people gets excited about something new, then figure out why. If you notice that something appears to be working well for others, then figure out why. If you notice an increasing stream of criticism on the technology you’re using, then figure out why. You’ll need information like this to make well-founded decisions about your future."

Should we always pay back Technical Debt?

A former coworker of mine, Jim Highsmith, has recently written an article on The Financial Implications of Technical Debt. Jim states that recent studies indicate the cost of technical debt is near $1 trillion in the U.S. I would like to see these studies. I do know that not too long ago, Gartner released a report indicating that the worldwide cost of IT Debt will be $1 trillion by 2015. Regardless, the point he makes is still valid - technical debt is egregious.

Jim states, "Unfortunately, by the time many organizations are paying attention, all the solutions are bad ones: 1) do nothing and it gets worse, 2) re-place/re-write the software (expensive, high risk, doesn’t address the root cause problem), or 3) systematically invest in incremental improvement."

Of these three (bad) options, I think the second is often a better choice than the third. The first represents failure to make a necessary decision.

Training Software Professionals

Here is the slide deck to my SCNA talk, "Training Software Professionals, Just What the Doctor Ordered". In the past, my slide decks stood on their own. That is, you could thumb through the deck and easily glean all the key points of the talk. But I am trying to move away from that presentation style to one where the slides offer visual support, but the speaker (me) tells the actual story.

Uncle Bob on Humility

The following just hit my inbox. It is a post on the Software Craftsmanship Google Group.

 

On Oct 24, 2010, at 12:36 , David Starr wrote:

My question is, "what can be done to fix the reputation [of elitism] and change the conversation before craftsmanship is deemed irrelevant"?

Uncle Bob's Reply

As a craftsman I am dedicated to improving myself; and therefore I realize I am deficient.  As someone who is admittedly deficient, I am not interested in pointing out someone else's deficiencies.

In general, whenever someone asks "what can we, as a group, do to ...", the best answer is going to be of the form: "Each of us, as an individual, should ...".

So, to deal with perceived elitism, each of us as individuals should remember that we are not elite.

 

Code as a Cause of Project Failure

During the speaker panel at SCNA this past weekend, Chad Fowler (@chadfowler) asked, "How many projects fail because of the code?". Given the context, I assumed he was making the point that projects fail due to business issues, not code. The room was silent. While one might have assumed this meant the entire group thought it rhetorical, I concluded everyone agreed with Chad. Projects fail not due to code, but due to business issues.