Elements of Success

It was fun to watch this short video about a software development project:

But why was it fun to watch? Stylish hardware – all Macs! – or pretty women or fashionable sun glasses?

No, I think the fun springs from two factors. At least for me.

• Energy
• Accomplishments

What I saw was a high energy team. All motivated, all focused, all coherent.

Where did the energy come from?

• The team was small.
• The team was cross-functional, i.e. it was empowered to do all that was necessary to deliver. External dependencies were minimal and consciously chosen.
• The time frame was short and tangible.
• The goal was crystal clear and understandable to everyone.
• Who benefited from the solution was tangible to everyone.
• The customer (store personnel, manager) was eager to get the solution in hand - and stayed in close contact with the team.
• There was no fixed scope to what the team should deliver until the week's end. They had a goal, but no backlog to drain. No estimation, no velocity measurement.

High energy is good – but there is always a danger that it gets drained. This project, though, seemed to keep it high. How?

• Short time frame, again.
• Frequent and benevolent feedback from different sources.
• Seeing users actually use (and like) the solution.

To sum it up: The team again and again was given a sense of accomplishment. They made a difference with what they did. They started and they finished things thereby moving the solution forward. Thereby they found closure.

And even the short time frame, where at the end it's said you're never really done, helped to get a feeling of actually accomplishing something.

Of course this all is nothing terribly new. But it was good to see "in a nutshell".

If you want a software project to become a success you need to pay attention to these elements:

• Small team – small is not only beautiful, but also efficient and effective
• Cross-functionality – because any outside dependency slows the team down
• Frequent feedback – to avoid waste and keep the energy high
• Close contact with users – it's not only the frequency of feedback that's important, but also the actual contact with anyone who's going to benefit from the solution; this provides energy and instills purpose which is important for focus and coherence
• Short time frame – we're better at focusing and investing energy when we can see a light at the end of the tunnel ;-) This could mean to work in sprints. But if one sprint follows another without so much as a one or two day break in-between, then that's not what I mean. Rather, I think, after an intense time (maybe one to four weeks) there should follow something very different. Only that ensures a sense of accomplishment and closure. Teams really need to take a break – which does not mean to go on vacation, but to do something very different. It's like changing what you grow on a field: that should change, too, to not exhaust the soil.
• No fixed scope – Focus on a direction, set up a goal, have a vision, but do not become obsessed with a certain number of features to deliver. Fixing scope destroys focus on value and creates pressure from day one on.

Software development can be quite easy, I'd say. The choice is your's (or your manager's ;-) ). You can go for high energy, high focus, high value – or you can go for... whatever. Where "whatever" will always be slower, more laden with friction, wasteful, flaccid.