This weekend my colleague Martin van Borselaer wrote a blog post “Where Scrum Sucks” in which he argued that Scrum lacks the Business side of project control. Martin has successfully used a combination of Scrum and PRINCE2 to solve this problem in various projects.
I believe Martin is right that for some projects more control from a business perspective is needed. However, I don’t think that adding more layers of control is helping us in making better software. It widens the gap between the business and the production team and it takes another chunk out of the project budget. That’s not business value, working solutions are!
If all this project control is not helping to create better solutions, what does it give us but a formal process for dispute? An escalation path?
Maybe we should look at it from another perspective. If a project is so large that it needs multiple management layers and business roles to keep control, shouldn’t we reconsider its size? Can’t we make IT smaller, clearer and euh… cheaper?
What’s keeping us from a just do it approach?
Trust
Our customers don’t trust us and they have very good reason not to. As IT we have too often been unable to deliver what the business needs. Projects were too late, over budget and in the end they frequently didn’t even fit the business requirements.
We as IT professionals also don’t trust our customers. When I was working as a analyst / programmer, one of my managers had a saying: “customers, you can never estimate them low enough”. The result of this skepticism is thicker contracts, larger risk margins, etc.
Customers always complain about the results and they disagree with our perception of the requirements. And programmers always complain that the specifications are not clear enough.
So what do we do? We calculate for argument, creating top heavy projects by adding layer upon layer of overhead. Customers try to at least limit the financial risks by demanding fixed price / fixed date projects. IT in reply requires more and more formal procedures and stacks of requirement documents to hide behind.
I am sure that in most cases this is not needed. That we can get better results with lower budgets. How? By making IT smaller. By accepting that you can’t know everything up front and that you will run into changes. And, most importantly by working together as partners, with a shared and clear goal. To do this, we need trust. Trust that we can do the job and that we won’t overcharge or under staff.
We will have to earn this trust. That’s difficult and that’s why I like Scrum so much. With Scrum we can prove our success to a customer with only limited risk.
Scrum allows us to deliver a (potentially) shippable product in one month (one month!), from customer okay until release.
If it doesn’t work, the financial risk is limited. Okay, one month work is still an investment but a tiny one compared to the alternatives.
And if it does work (and in most cases it will), we can start to work together on getting results and gain more confidence with each iteration. Putting tangible results first and keeping project overhead to a minimum. That’s business value!
It starts with trust. And yet, trust is a very difficult thing to earn. Without it, the customer will demand more control and more management. In those situations, or if the challenge is too complex or too political, Martin’s combination is perfect. Especially if in time you are able to show the results, reduce the overhead and start working together.
That’s my tuppence worth…
