Hire the best, or hire the lizards

There is a practice I have observed far too many times. And it is one of the largest killers of value at companies large and small. It is the practice of turning superstars into lizards. It actually happens. And you've likely seen or experienced it yourself.

The process goes something like this...

Company F invests significant amounts of time and money in hiring. It develops elaborate recruitment engines to find the best, most creative people. It ensures a robust interview process so only the driven and accomplished make it in the door. And it choreographs onboarding to give these rockstars what they need to deliver value.

Then it happens. Over time, and with imperceptible slowness. The perception changes. Company F starts treating these boiling frogs as the less competent, less trustworthy, versions of the people they hired. These former elites become the necessary recipients of 19th century sticks and carrots.

Sure hiring mistakes happen. But generally, these processes tend to work pretty well.

So what happened?  Did these winners actually lose their ability to deliver? Why are these superstars now looked upon as reptiles with the associated brain capacity?

Leadership. Or more accurately, a failure of leadership.

These former denizens of success were hired, in part, for the great accomplishments they've made in their careers. There is the innovative engineer who developed a method to reduce bandwidth usage by 98%. But now he has every story estimate questioned. There is the product manager who led the global launch of a consumer app to millions of customers. But now she isn't trusted to make a decision on the next two week sprint.

But the success these former heroes achieved is not a result of their own herculean efforts. It is a marriage of the person and the many factors that made up the environment in which she achieved her success.

When a flower doesn't bloom, you fix the environment in which it grows, not the flower. - Alexander den Heijer

If you expect people to achieve similar results they must have a similar environment. Your job as a leader is to craft that environment. And then empower, trust, challenge, nurture, and inspire. Otherwise, you are destroying the greatest asset your company has.

Hiring great people is hard. But if you are hiring the best people and not inspiring them, you might as well hire the lizards. It is a lot easier.

Maybe "How do we scale Agile?" is the wrong question

For the last few years I have been hearing one basic question with increasing frequency, "How do we scale Agile?" More specifically, how do we scale agile product development for a single product across more than a handful of teams?

I can't help but wonder if we should instead be asking ourselves a different question all together: Should we scale Agile?

What Agile frameworks like Scrum point out is that it can be incredibly difficult to scale development beyond a couple teams. This has nothing to do with an inherent inadequacy of Scrum, it has to do with the fact that the communication overhead required to coordinate the activities of multiple teams increases at an exponential rate. The percentage of investment dedicated to coordination continues to rise with each additional team involved in an effort.

Maybe the first question to answer when considering how many teams to dedicate to a product is: Is increasing the size and complexity of this software development effort worth the additional value we will create for users of our software?

I have seen scarce few examples of massive development efforts that create a level of value commensurate with the size of the team building it. But maybe I just haven't been looking in the right places. What do you think?

Update 8/23/2013: Just discovered Martin Fowler's opinion (at least in 2003) about the same matter at http://martinfowler.com/articles/canScaling.html. Reminded that I need to spend even more time on his site! It is a truly great resource.

We shouldn't build software like we build houses

On January 25th, 2013, Wired published an article by Leslie Lamport describing the need to build software like we build houses. This wasn’t the first time I heard this argument, but I was surprised that a publication as forward-thinking as Wired would publish such a backwards-looking article. It absolutely doesn’t make sense to build software like we build houses.

In his article, Lamport describes the need for specifications to help software developers “think clearly about what we are building.” Strangely, he seems to think that programmers don’t like thinking. In my experience, programmers are proud to do work that is so cerebral, and they enjoy opportunities to think deeply about their work. Another surprise is Lamport’s conflation of thinking and specifying; the two are hardly one and the same, and there are more ways to think than by writing specs. In general, though, Lamport’s point is that software should have specs so that programmers won’t make mistakes and software won’t be so hard to change.

Lamport’s overall argument is weak; he tries to make points through metaphors more often than he does through logic. I won’t dwell on this, though, as it’s been covered at length in the article’s comments. Instead I will point out what is implied by and missing from Lamport’s apparent worldview.

Lamport's Worldview

Lamport seems to believe that making mistakes is a big problem in software development and that writing specs is the best way to avoid it. This thinking rests on the assumptions that the writer of the spec knows exactly what the final state of the software should be – what it should do and how it should do it. It assumes that requirements are fully understood, technology is fully understood, and business conditions do not change. Over the past few decades, the software industry has come to realize that this is not often the case. I’m surprised that Lamport hasn’t  been made privy to this discovery, and I wonder whether the nature of his own programming work at Microsoft Research has somehow shielded him from it.

The software industry now understands fairly well that processes with up-front investment in things that aren’t working software – things like specs – work great for situations like accounting, cooking, and building houses. Some people call these “defined process control models.” These processes, while great in other industries, fall down on their faces when it comes to software development, where we don’t often have a lot of certainty about what we are building in, or how it will be built.

The Modern Worldview

In software we look instead to the empirical process control model, which emphasizes inspecting and adapting (i.e., feedback loops) instead of planning and then executing. This is what’s called for when we don’t know exactly what our work product will ultimately look like or how it will work.

In empirical processes, instead of being asked to clearly and unambiguously describe the exact output desired, a customer describes what needs to be accomplished. Developers work in short iterations to incrementally build what is needed, involving the customer all along the way, until the necessary solution is discovered. The result of these processes is typically better software.

Programming is Nothing Like Housebuilding

Building a house is arguably uncreative work. We can categorize houses fairly simply based on their attributes and current state of degradation. Houses, for all their variations, are largely the same and generally serve the same purposes for anyone that lives in them.

Software development, on the other hand, is incredibly creative work. The process of developing any two pieces of software will be quite different, as will its ultimate outputs. Thinking one can accurately define the exact output of a software development project is at best ignorant and at worst arrogant.

We can’t know exactly what will be created at the beginning of a software development project and that is okay. Instead we involve the customer in the process so they can see exactly what is happening as we move along. Lamport might call the evolution of the software in concert with customer feedback a series of mistakes, but anyone who has developed software this way knows there is actually incredible value in these iterations. Users don’t need to visualize how the software will work because they can actually use it after each iteration of development. And neither they nor developers have to waste time investing in specs that will rapidly become obsolete.

And despite what Lamport said, well-built software is incredibly easy to change. Using techniques like TDD allow us to leverage the strengths of software creation, and avoid the limitations inherent in the production of physical objects.