Saturday, November 22, 2008

The Design/Development Gap - Building Lean Teams

As teams grow larger, they tend to want to start the design for V2 release during the development of the V1 release. The thought process here is that you can get more features out the door. Why waste months doing waterfall linearly, when you can do waterfall in an offset parallel fashion? It's more productive, right?

This results in the introduction of roles like Business Analyst or Program Managers. Often these roles are filled by persons with primarily a project management based background, and less of a technical background (although most i've worked with have had a small amount of technical experience.) Usually this position is tasked with taking a rough list of high level features, and defining all the details in a functional spec.

The problem with this, is that when developers have little or no input into the details, they tend to lose any sort of emotional connection with the feature. By handing a developer a blue print, you give a position that's used to wired to think creatively, no opportunity to be creative. The more and more functionality that thats dropped on their desk in the form of a function spec, the more and more distant they become with what they are building.

The productivity loss as a result of this gap between design and development almost always rears it's ugly head first during the estimation process. A feature that the developer has no connection with will always result in a bloated estimate.

If you're thinking that you're going to get more productive by further parallelizing your waterfall process right now, you're dead wrong. Get the features into the developers hands to do the design. Work with them and be open to new ideas, coach them on what's important to the customer and the business, and make sure your vision is clear to them.

By doing this, you'll see that you've got developers who are designing great things, and are pumped to be coding them. You'll also see that your "wow" features will increase, as your developers will start thinking about how they can make this one little thing cooler by using Google Charts, or smart Ajax, or rich DHTML.

This is the kind of productivity you need. You don't need lots of features, you need great features, and closing the design/development gap will get you there.


Anonymous said...

I think there is a lot of truth to this and a better balance is required.

That said, I hear the "fewer great features is better than lots of moderate features". I do not think this is quite as obvious as it sounds to many people. I think is strongly depends on your target audience

If you are selling a product to a business that needs to do A,B,C,D and E and you come in and say "I can do A and B, really well!" and your competitor walks in and says, "I can do them all, well enough", you are likely to lose the business.

Now, your competitor better REALLY be able to do them all well enough, or they will lose customers and market reputation. Assuming they can, though, you will be fighting for years to compete.

The simple example is SAP and Apple. They are very different companies and both are very large. On makes "all of the features, well enough" and the other concentrates on "the right features." Is one wrong and one right? I don't think so, just different markets.

It may be that you would rather work at Apple than SAP, but that should be seperated from right and wrong in their approaches.

Jim Fiorato said...

I agree that there's an equal place for the Apples and the SAPs of the world. But, which one would you speculate is leaner? Apple or SAP?

And I don't think you can dismiss the "who would you rather work for?" point. That's the most important piece of it all (from my perspective, at least).