I work as a consultant. It’s been a really good way for me to try different kinds of roles and get to know different organizations. I’ve learned a great deal.
But I’ve never really been happy with the way we work in the projects I’ve been in. Even though we have tried to work in an agile way within the team, the organization as a whole hasn’t shared our philosophy.
A couple of weeks ago I joined a new project, and it is quite different from what I’ve experienced before. Pretty much the entire development organization is a textbook example of how to work agile. My team work in a kanban-style way, with little focus on sprints and with continuous integration and deployment. When we have implemented a feature, we release it. When we run out of tasks we estimate new tasks from the backlog and put them up on our board. The team has all the functions needed to take a story from nothing to release – back end devs, front end devs, designers and testers.
It’s pretty great.
I’m not going to go into detail about why working this way is so great, more than to say that we are really productive and we produce high-quality software. That’s for another post. What I want to talk about is what it takes to work this way, and why so many organizations fail in doing so.
Sales people like to promise things. I know, I have been there, and I have made promises to customers without knowing if our developers could commit to them. If you work with B2B at all, you have probably experienced this. Sales guys committing to delivering a fixed set of features on a fixed date. And thus preventing the organization from being agile.
The same thing often happen with internal projects, because of the way most companies are organized – separate units with separate budgets. This effectively makes internal projects equivalent to any other B2B project.
Now, why is ‘fixed scope, fixed time’ so hard to combine with agile?
Most importantly, being agile is being adaptive to change. And when things change in a project with fixed scope and timeframe, the only variable you have left is quality. And there are few things creative people like designers and developers hate more than being forced to produce crappy things. Things will change in the project. Requirements will be misunderstood or conflicting. The scope you agree to is never what the customer wants in the end. The more you try to specify things, the more problems you will face when implementing them.
Secondly, by setting fixed scope and time you take ownership of the development process. You have committed to things that are not in your hands, but in the hands of the development teams. And a development team without a sense of ownership will have no motivation to deliver.
I like to think of it this way: Bugs exists not just in code, but also in requirement documents, in wireframes, in graphic design specifications and every other artifact you produce. Agile is about producing less of these bug-ridden artifacts and minimize impact of errors that occur.
The way to making your organization more agile starts with letting go of the detailed specifications. Agree to high level goals, and agree to a process where the development teams have control, where changes can be made easily and where a working system is most valued. Don’t fool yourself into thinking that you are agile just because your teams have scrum boards. You’re agile when you can easily adapt to change and when you allow your organization to constantly improve.
People love to make great things, and they will if they are given the means.
11 May 2013 by Andreas Eldh