Software companies long ago abandoned complex release processes where comprehensive new versions would show up every few years. So why do software application buyers continue to plan for and tolerate implementation schedules that span several months or in some cases even years? What’s good for the goose is good for the gander, and software buyers need to wisen up and stop being lulled into an unreasonably long technology implementation that will almost certainly not yield the benefits promised during the sales cycle.

What is Agile?

Agile development has been a mainstay in software development for at least ten to fifteen years now. It coincides with the rising popularity (and dominance these days) of software as a service (SaaS) offerings. The basic premise of agile development is that you deploy new technology frequently with the smallest amount of incremental code possible. Agile development also gave birth to the popular notion among technology startups of the minimal viable product (MVP). In all these cases, the idea is to do and learn and do and learn and do and learn – over and over again. Here are the four key principles of agile development from the agile manifesto:

• individuals and interactions over processes and tools;
• working software over comprehensive documentation;
• customer collaboration over contract negotiation; and
• responding to change over following a plan.

These principles contrast with the historical waterfall method of software development where you plan and plan and plan and plan and plan and code and code and code and code and code and then deploy and OH SHIT! NOTHING IS AS WE EXPECTED!!! HOW DID THIS HAPPEN?!!

Agile is so popular because waterfall is simply broken. For so many reasons, but primarily because planning is filled with the flaws of confirmation bias. When development teams have lots of time to plan and code, they avoid real feedback from the market for extended periods of time and just do what they want to do. Agile and MVP concepts force the issue of a reality check as quickly as possible. It’s like the Japanese concept of lean manufacturing: reduce the amount of work in process inventory and you will find the flaws and waste in your manufacturing process. Funny how all these industries, from software development to manufacturing, all ultimately arrive at the same wisdom over time.

Use Agile and Lean Concepts for a Smoother Software Deployment

It’s time for the folks that buy and deploy software to learn from these agile and lean concepts. I cringe every time I hear about a potential customer’s long planning and deployment cycle for a new software package. When they are thinking in terms of several months or even years before the first system capability hits production, they are not thinking about the problem the right way.

The problem

Planning for the perfect system that does everything is the enemy of real progress that could improve the business tomorrow. First, you will inevitably not plan for several things that could improve the business because you have confirmation bias in believing that you really understand what will actually improve the business.

Second, the thing that you believe should improve the business (although it might not) will undoubtedly work differently in production than the staged demonstration that you observed. You simply cannot plan for success when the scale is too big because few organizations (none) have the resources to actually plan and deploy at large scale. It just doesn’t work for all the same reasons that software developers abandoned waterfall and embraced agile.

The solution

So what is the solution? Simple. Small and incremental deployments of minimal viable technology functions that deliver well defined outcomes (a minimum viable deployment, MVD if you will). And then another deployment. And another and another and another. In this manner, any singular failure is quickly discovered and quickly modified to address the flaw that was not visible in planning. The failures will also tend to be small and minimally disruptive. As the principles above direct, let people do, learn, collaborate, and correct instead of thinking you can plan your way to large scale successes.

3 Tips to Put Into Practice

How might this work in practice? First, constrain the timeline to have something, anything, deployed in production and improving the business. Any schedule longer than six to eight weeks from initial kickoff to first production output is too long. Narrow the scope until you can hit the schedule target. You can narrow the scope by feature winnowing or by narrowing the portion of the organization that faces initial adoption.

Second, don’t be overly concerned about integrations and optimizations until primary value is achieved. Primary value is NEVER the elimination of gaps between systems. Primary value is always something more fundamental like faster quoting, easier payment of invoices by the customer, easier scheduling due to a map or routing feature, a better sales demonstration, and/or faster communication to technicians through mobile dispatch.

You can always streamline administration between systems AFTER primary value has been achieved. I cannot tell you how many folks buy on the value of “integration” only to discover the integrated solution is a horrible piece of software that fails to deliver the primary value they were seeking. When the primary value fails, the promise of integration is worthless.

Finally, just say no to any vendor that proposes a huge services implementation requirement for your organization to see first benefit. Force them to absorb the risk or rescope the project until you see value in six to eight weeks. This will eliminate most of the failures you are likely to encounter BEFORE you spend a bunch of money for the simple benefit of learning from a failure.

Forcing the discipline that has made agile development so popular onto the application purchasing and deployment process will speed deployments, minimize expenses and failures, and maximize the amount of innovation your organization is able to absorb. Pay close attention to the key principles of agile enumerated above as you plan your next software purchase and deployment, and I bet you will get a far better result for your organization.