Tuesday, May 29, 2012

Innovation can't be planned

The profession of software developer is a relative young one. As such we learn new things about it that other professions already have figured out. This post is about one of those things that managers who need to manage developers rarely seem to get: innovation.

Software development is devided in two different types of work, the standard projects for which you can simply apply well known en documented methods that lead to a predictable result, and the innovative projects where features and requirements can change based on the technical possibilities and impossibilities.

For example, implementing a corporate intranet in a CMS is well understood and tends to be predictable. On the other end, building a new product where the UI has to be available on a wide range of platforms and devices is not only new, but also has numerous variables that make it different every step along the way. Sure, there are methods to execute a project like that in a structured way.

Most agile methods appear to be suited to do highly innovative projects. However, they do have a single flaw, which I've recently experienced. Although they do allow for great flexibility in the big picture, once it comes down to the detailed work, they don't allow that same flexibility because at some point there still has to be some predictability so it can be sold to managers and executives alike.

In practice, when using an agile method, developers are still required to commit to delivering a certain amount of work within a certain amount of time. The only thing that has changed is the amount of work they are asked to make an estimate for. It's like instead of asking to design and build a spacecraft you're now asking for only the propulsion system. Sure, it's less work, but it's still highly unpredictable, especially when you find out the maximum speed in the specification is not nearly enough to get the craft to the destination within a reasonable amount of time and the fuel consumption needs to be cut in half.

Obviously the example above is exaggerated, but the point is that with innovation things can only become apparent once you're working on it. You encounter problems you could not have thought of and you have to solve them in order to deliver a product that's up to standard.

So how do you go about building an innovative software product? The first thing is to make sure you have the right people leading the team and trust them. Also make sure there is a clear set of boundaries that the team needs to operate within. Then support them and facilitate their work as much as possible.

This doesn't mean you can not put a timeconstraint on a project. However if you do, you should be prepared to compensate for that in functionality (some would argue that you can also assign more resources to a project, but why I think that has great limitations is a topic for another post).
So please, stop trying to plan your innovative development as you will only be disappointed.

No comments:

Post a Comment