Sun 18 Feb 2007
I’m focusing these days on implementing SCRUM practices in our team. At first I was doing it slowly, by for example introducing a requests handling process that included a public backlog and monthly iterations (Sprints). Judging by the results I think we are ready to fully embrace it.
I think SCRUM matches what we do for many reasons, for example because it exposes publicly the stark reality of limited capabilities and makes our decisions better aligned with the users’ wishes and needs. But the most important reason is that introduces some order into our chaotic world – some, but not too much.
Chaos is a huge impediment to building anything of complexity. Sadly, it is not very well understood that this applies also to software. If we were building a bridge across a valley everyone would understand that we can lay only a certain number of bricks (or whatever) a day and that the bridge’s direction can’t change a few times a month. Somehow, with the software people do think that if they scream at developers loud enough anything can be done. It can’t. It’ll just bring in more chaos.
However, a startup company by its very nature has to be chaotic. Chaos is creative. It is also a necessity – as a startup grows and verifies its first assumptions against the market reality (which can never be fully understood before actually going into the market) it has to adapt. And do it quickly – while still maintaining the momentum it needs to get onto the orbit of safer, operational businesses.
Understandably, any computer systems and software that support a startup’s core business have to grow and adapt with it. At the same time deploying those systems and building that software requires periods of uninterrupted, concentrated work by teams of highly intelligent, highly qualified individuals. By the vary nature if they don’t get those periods – because of the chaos emanating from the business itself – the result must be rubbish (or a mild failure at best).
So the art is to find the fine balance between the chaos and order. Too much order kills the startupness of a startup. Pure chaos makes development of anything technical impossible. The company as a whole has to surf the wave of chaos on a small but hard surfboard of order. SCRUM recognizes that and gives a set of rules that are such a surfboard. It also rejects unrealistic expectations of clearly defined requirements, well known deliverables and long term Gantt charts heavyweight methodologies are so fond of. It’s a real set of tools for managing projects in the real, chaotic and quickly changing world of today’s IT industry.
That’s why I’m so enthusiastic about it.