Why do so few enterprise IT organizations delight their users and business partners? Why is it so hard to build good software? Even for enterprise IT organizations with mature defined processes.
To answer the question, we need to look at the classic way we build software. We start by setting up an adversarial relationship with our business partners without realizing it. Conventional wisdom says we need to define what we will build, up front and then control scope. We make our users and business partners commit by signing a requirements contract. Do you know of many marriage that were saved once the lawyers were hired? Bad contracts don’t bring collaboration, bad contracts bring conflict. We turn our users and business partners, our strongest assets into adversaries.
Look at the challenge we put in front of our users and business partners. We ask them to define a new system at great detail, up front when we all know the least about the system. It is clear that out business processes and systems are complex. Regulation and competition make it so. What chance do we have of getting the requirements right? Is it any wonder our partners are hesitant to sign a requirements contract? Is it any wonder the requirements often are vague and imprecise?
Once scope is signed off, we finalize our estimates. We use the estimate to set a schedule and budget. This is our plan. All when we all know the least about the system. Our plan is a really a big guess. But is looks so precise. All those tasks and dependencies. Such folly.
Is it any wonder the users want to change the requirements and scope? To argue about what a requirement means? That the schedule runs long. That the budget is overrun. That defects are too numerous to count? Finally, we descend to arguing about what is and is not a defect.
Then, we do a post-mortem. Inevitable someone says, "we need to take more time to plan better"! Never mind that it already took too long to define the scope. That at some point an executive said, "enough, start coding". Yes, the obligatory post-mortem exclamation, "we need to plan better!". What a belly laugh!!!
Where did this idea come from about planning up front and locking scope? Is it because IT was tired of being beat up? Users change their minds. They do so because they learn as we build software. However, we don't know how to incorporate what was learned without impacting schedule and budget. So, we insist on freezing scope. Think about it. We don't allow ourselves a way to incorporate what we learned as we build. Is it any wonder the users says, "that is not what I asked for"? What they are saying is "never mind what I said, that is not what I need".
We need a serious change in mind set. We need to accept that conventional project management wisdom got it wrong. How many times do we need to fail before we can conclude our processes and systems are broken?
Lets accept the fact many details are not knowable at a project start. That our attempt to control scope results in unhappy users and unmeet business need.
Let's accept that fact that phasing our activity to plan, design, code, test and release in a single cycle over the life of the build doesn't work. We have proven that to ourselves, our users and our business partners, again and again. Yet, how many of us have this formula for failure codified in our enterprise IT methodology? Experienced developers can feel the churn in their stomachs every time they travel down this failed path.
Say it out-loud, "our processes are broken". Let's stop whispering "under commit and over deliver". Let's stop covering our hides and start focusing on value. Let stops using our broken processes and systems and expect different results. Let’s stop acting insanely.