Paul Little fair,
"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!”
Waterfall: Striving for Certainty
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:
- Individuals and interactions over processes and tools. People building working software takes precedence. We value self-organisation, regular interactions, co-location, peer support and enthusiasm to deliver.
- Custom collaboration over negotiation. We don't want to be arguing over a contract any more. Under contract when something happens that we weren't expecting there are penalties. Now we're saying we're going to try to go on the journey together and collaborate.
- Responding to change over following a plan. Whereas Waterfall is rigid and structured, with Agile we navigate, we experiment. Rather than doggedly focusing on a distant destination, our attention is on moving forward in the right direction and overcoming challenges in a timely and pragmatic way. Or agreeing to stop before we create waste.
- Products not projects. We now value frequent releases. We break things down into smaller iterative steps. We create long-lasting teams and bring the work to the people, rather than the people to the work.
- Concurrent testing over build and test phases. Previously we would build then go into a test phase. Now we test as we build and we benefit from the fast feedback.
- Program execution. We ensure all teams are aligned to deliver customer value at the program level with complete transparency to all. This “open kimono” approach is scary for technology and the business but very rewarding.
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.
