The Value Transformation
The Value Transformation or How I Learned to Stop Worrying and Love the Business!
It's 2003. May. IT is becalmed, in the doldrums, in limbo. The flurry of activity and inexplicable spending that was the Y2K tsunami has long since blown over. Some say it was IT's finest hour. Others believe it was a totally manufactured crisis. Either way, the business side of the house is no longer supporting any of IT's fantasies. The Standish Group has just published the results of five years of analysis on the failure rate of IT projects. It is at a depressingly low rate of 65% of IT projects that fail. The dominant project methodology is waterfall (popular since the 1970's). Looking at the breakdown of the average IT spend, approximately 20-25% is committed to keeping the everyday IT operations up and running with the remainder going to innovation and new solutions for the business. The business is reacting to Y2K and pushing for more stability, availability and reliability from their IT systems. The business is demanding real business value and ROI from their IT spend, not pie-in-the-sky touchy-feely measurements and vague promises. IT is struggling to respond. Struggling to translate real IT performance gains into actual demonstrable value for the business. Struggling to understand its role in the confusing new millennium. Struggling, in some way, to justify its very existence.
Around this same time, a small group of unconventional programmers gathered at a ski resort in Utah in October 2001 and created Agile. More about that later…
Economically, in 2003, we are in a downturn. The collapse of Enron and Worldcom has vividly demonstrated that no company is "too big to fail." These scandals lead to the passage of the Sarbanes-Oxley Act in 2002. SOX, as it is called, contains provisions where key executives can now be sent to prison for falsifying the financials of public companies. IT is to play a major role in the financial reporting systems of public companies. In addition to the heavy operational focus of most IT shops, new compliance requirements are added to IT shops already heavily burdened with a plethora of audits.
Politically, in 2003, our recent presidential election took six weeks to decide because of the method used by Florida to collect simple data ("hanging chads"). The headlines in Europe call it a real "Mickey Mouse" operation. Less than two years ago, 9/11 caused us all to question everything. Even the long-vaunted FBI had been caught with their IT computing pants down. The nation's top cops, famed for their ability to gather and sift through huge volumes of information, are exposed as laggards, dependent on outdated systems that do not have a prayer of keeping up with the exponentially increasing demand. Systems that were linked, at least indirectly, to the domestic intelligence failures leading up to 9/11. We went from invincible to vulnerable in the span of one sunny Tuesday morning. It is a difficult time for the U.S. and a difficult time to be in IT.
As if things couldn't get any worse for IT, in the May 2003 issue of the Harvard Business Review comes an article by Nicholas Carr entitled, "IT Doesn't Matter." The premise is simple and direct: IT, like so many other technological innovations before it, has become a commodity. IT no longer represents a strategic business advantage. No longer can one organization exercise technological dominance using IT as its lever. Now every organization has roughly the same IT: networks, routers, servers, databases, websites, email, etcetera. Carr further points out that now that IT has reached this stage of commoditization, it represents a major risk to the business enterprise: The risk of not being there. Outages that were mere annoyances in the past now place the business at a significant disadvantage. This was not just a shift in thinking but a strategic shift in where you put your IT spend: Risk mitigation versus innovation. In fact, this fundamental shift in thinking (and spending) was well underway. Every organization on the planet had been caught on the horns of this dilemma three years earlier during the Y2K mess. But there was simply far too much to do at the time and no downtime to think about why we were doing it. Y2K was the embodiment of Carr's basic premise: IT represented a strategic risk for the business.
The industry's response to Carr's article was swift and pointed. Analysts and pundits lined up to debunk the premise that IT and its technology was little more than 21st century plumbing. The overriding theme of the responses to Carr's article can be paraphrased as, "Sure, we all have the same technology but it totally depends on what you do with it! Look at Cisco & Wal-Mart & Dell -- they are innovative." (Remember, this is 2003!) So, the real question is: Was Nicholas Carr right in 2003? Is he right today?
It's Time For A Change!
Fast forward to 2017. What has changed? What hasn't? The Standish Group has now been measuring the failure rate of IT projects for 20 years. The IT project failure rate is still at the depressingly low rate of 65%, with very little fluctuation from year to year. The dominant project methodology is still Waterfall
Agile PM is coming on very strong and will, no doubt, reach the tipping point soon and become the dominant PM methodology. But looking at the aggregate of all IT shops today Waterfall still dominates. By example, let’s look at COBOL, it’s supposed to be dead or dying, right? In 2017, COBOL powers 70% of all business transactions, 95% of all ATM transactions, and there are 200x more COBOL transactions per day than combined Google & YouTube Searches. Reports of COBOL’s death are obviously greatly exaggerated.
In 2017, most IT Operations groups remain focused on delivering reliable stable secure services with a minimum of down time. Now, however, approximately 75 to 80% of the IT spend is committed to keeping the everyday IT operations up and running with the tiny remainder going to innovation and business solutions. Is this progress? Today, the business is pushing for more creativity, flexibility and innovation from their IT systems. Yet many IT Operations groups -- stuck in post-Y2K mode -- remain hunkered down and determined to create the most bullet-proof environments in history.
Meanwhile, the business side has been scrambling to maintain its relevance while competing in our new digital world. Smartphones and tablets that are always connected. More savvy consumers. Drastically different customer expectations and timeframes. The business now knows what needs to be done and they know how fast they need it done. The business has started pushing Development (Dev) and Project Management (PM) to get with the program. Pushing them hard. Very hard. With 20 years of data to back it up, Dev and PM have to admit that they are broken. The waterfall project methodology is simply not working for most software development projects. There are simply better ways to develop software.
Waterfall vs. Agile Explained
The waterfall method was the prevailing methodology of its time. It was created to build PRODUCTS, physical things that would be manufactured in volume and eventually go to market in volume. Requirements are set; design to those requirements; build that design; Implement the build. All the investment is front-loaded and all the business value is received only after implementation at the very end. With waterfall, we have one shot to get it right, one chance to define the scope…in the requirements stage. Get it wrong there and we have to do it all over again from the beginning. When computers began to make headway into the businesses of the 1960's we needed a method to develop new software. The only project methodology around that made any sense was the waterfall method. But that method was never designed to produce software -- it's simply all we had available at the time. No wonder we have a 65% failure rate for IT projects.
But in the late 1990's, some new and radical “lightweight” development methods (all based on object- oriented programming) began to gain popularity: Extreme Programming (XP), Dynamic Systems Development Method (DSDM), and Scrum to name just a few. Proponents of these and other similar methods codified their key values and beliefs in 2001 with the Agile Manifesto. And Agile was born.
Agile is an iterative development method. With each iteration as short as two weeks. Each completed iteration produces ship-ready code. This means that for a minimal investment the business can begin to see value after only two weeks. Built into this two-week schedule is time for feedback from the business. Which means the scope can be adjusted every two weeks. This may seem a bit disorganized and, in truth, it is. But it turns out that most software development is actually far better if the end customer can provide feedback and commentary and tweaks along the way. (In Waterfall “Scope Creep” is strongly discouraged) Agile allows Development and Project Management to operate in synch with the needs of the customer for the first time. Development can begin to keep up with business demand while delivering software that is exactly what the business wants. Truly a win-win-win, a transformation, for Dev and PM and the business.
Upside down world
Phew! Crisis averted. Business, Dev and Project Management are all in synch, Oh My! Breaking into their happy dance and all's right with the world!
Whoa! Not so fast. Yes, things are finally good with Biz, Dev & PM but nobody told Ops. You remember IT Ops, the people who actually deploy all these new wondrous Agile-developed business solutions so that actual value can actually be realized by the business. For real.
IT Operations is still operating under the old rules. The 2003 rules. Nothing has changed for them. Well, that's not quite true. They are trying to apply the 2003 rules to a world with smartphones, Wi-Fi, and ubiquitous cloud environments. They are still trying to: lock it down, resist change, make it bullet-proof, defeat hackers, safeguard availability, increase reliability and maintain stability…and, indirectly, frustrate the heck out of the business and Dev and PM as they try to maximize value at a totally different pace. The 2017 pace. Ops seems to represent a literal roadblock to the fast lane of Agile Deployment. Ops is not a little off-kilter but rather is suffering from a complete disconnect. A different definition of value and success. Like landing on a different planet…where everything seems upside down. A Twilight Zone episode where all the beliefs you have valued and cherished are gone…up in smoke. Poof! Life, literally, doesn't make sense anymore.
Can this chasm be crossed? Can two such diametrically opposed sets of values ever be brought into alignment? Even more than that, can two sides that seem to be polar opposites actually exist --no, thrive -- under a common set of rules? They can. The popular buzz words are digital transformation. But haven't we actually been digitally transforming since before the mid 1990's? Yes, of course, so let's call it what it is -- a value transformation. Which means it's a people transformation.
Why Does IT Exist?
Where do we begin in our discussion of value transformation? Let's start with a simple question for IT, "Why Do You Exist?" Some network geek may make a snarky comment about users slowing down the network, but it shouldn't take too long to get to the realization that "IT serves at the pleasure of the Business." Period. With that True North guiding principle in mind we soon realize that IT's entire raison d'etre, their sole purpose, is to provide value to the business. So far, nothing too controversial here. Now it gets tricky. Who defines value to the business? The business. This is not rocking my world, you say...wait for it. Can the business change its mind as to the definition of value? Yes. Aha! There's the rub! The business can, and often does, change its mind as to its definition of what constitutes value. Dev and PM now get it. Agile gets it. But Ops didn't get the memo. Many IT Ops groups are still operating under the 2003 definition of business value. It's time for Ops to join the party. Enter DevOps.
"DevOps represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams…" -- Gartner
DevOps is really a cultural movement that is completely dependent on improved communication, collaboration and teamwork across the entire value chain. (Notice the People Transformation part). It combines the principles of Lean and the flexibility of Agile with the latest automation tools to deliver high quality services and increased value to the business faster than ever before.
How much better is an IT organization embracing DevOps? A recent survey revealed the following IT and organizational measures for high performing organizations.
High Performing IT Shops:
? Spend 21% less time on rework or unplanned work
? Spend 44% more time on new or value-add work
? Deploy new software 46 times more frequently
? Enable changes 440 times faster
? Recover from failures 96 times faster
? Are 80% more likely to deploy successful changes
High Performing Organizations (where IT uses DevOps) are more than twice as likely to achieve or exceed the following BUSINESS objectives:
? Quantity of products or services
? Operating efficiency
? Customer Satisfaction
? Quality of products or services
? Achieving organizational and mission goals
Organizations that are embracing DevOps today are the leaders in the value transformation happening right now. They are leading in the achievement of both IT objectives and business objectives. Lean and Agile in the context of IT Operations and automation is the secret sauce for real transformation in today's enterprise.