THANK YOU FOR SUBSCRIBING
By Paul Little fair, and Chief Information Officer,
"We need an IT solution. Exactly how much is it going to cost?"
"I'm not sure I’m able to answer that question."
"Well, you're employed to tell us. It's your job. Come on, we want to know. We think one million is good? Or is it two million?"
"Well, it’s a little bit more complex than that."
You don't want to have the fight. You don't want to say, "Look, I don't know, it's three million at least, if not five, take it or leave it." You're tempted to say, "Give me some money and I’ll let you know when I need more."
Sound familiar? As an IT executive you run into this all too often. You're getting a hard time. So you pull out a figure. You play the "estimation game".
This is where I believe IT people are being dishonest. And why most projects run over time and over budget.
"Agile methodology creates open and honest conversations as well as enables true collaboration"
Why is there so often disconnect between business executives and IT on costs? Why do we guess and bluff when we're asked for an exact figure? We couldn't even tell you precisely how long it will take to drive to the airport during rush hour … and getting to the airport is a “known process!”
As most of us know, in the 1970s Winston Royce defined the Waterfall model for the delivery of projects. Under Waterfall you get the requirements from the business and work out how that turns into software. You do some design, some analysis, some code, some testing and then deploy. It's a pretty standard pattern that we're all familiar with.
But this process doesn't often work. Because after your upfront design, you always run into more complexity than you expected.
So we fail and we’re criticised, but then we repeat the same process in the belief that one day it will work.
In defense of Royce, when he formulated the model, he actually said we need to go through an iterative cycle, get explicit feedback, and repeat the process. But that just got lost. So businesses go through the waterfall cycle only once. It's a pattern that’s consistently failed us. Yet even the guy who wrote it says it's not right.
Why do we keep making the same mistakes? Haven't we learned yet?
Agile: Embracing Uncertainty Most of us have started adopting Agile. This way of developing software embraces the uncertainty. We've started our journey towards an honest approach.
These are the things we now value:
Time for an honest conversation
The Agile approach isn't forcing deadlines on people and saying, "this is your job and this is how you do it." It's an enabler to bring technology people and business people together. Agile methodology creates open and honest conversations. It enables true collaboration.
This can be scary. There's nowhere for us to hide. With Waterfall, we avoid the difficult conversations upfront. If things don't go well at the beginning of a three-year project, we get to hide for (at least) three years, always assuming we are going to somehow make up the time and achieve our deadlines. We only get found out at the end when we don't deliver. Then we get into the change request night mare.
Agile makes us more culpable, more accountable. We're showing people every two weeks what we've achieved. We don't have the three-year project anymore. We only have to cope with brief phases of uncertainty. In return we get discipline and feedback from the business. And as we deliver, we build trust and confidence.