When I begin my executive presentations, this is one of the questions that I ask the Executive Team. “Why do you persist in asking your I.T. teams to predict your organization’s future, when it is an impossible thing to do?”
“Then you wonder why, when they deliver the product 2 years later, it does not meet the needs of the organization.”
This has been the traditional software development mindset. When the Business Analyst puts together the Business Case for the new Financial ERP project, they list the high-level requirements and then project how much it will cost and how long it will take based on those needs or requirements gathered from the Business Stakeholders. Once an agreement is reached and all “signed-off”, the project proceeds into the Analysis phase. Here a number of documents are produced, reviewed, modified, reviewed again, modified again, and on and on.
One of the main documents created during this phase is what we call our Business Requirements report. This document contains all the needs of the business that should be delivered in this new product which is scheduled for release in three years’ time. This document contains the requirements of the business as seen from today’s perspective. This is what the information technology Department agrees to deliver in three years’ time.
The question that I ask senior executives is this, “how in the world can you expect your business analyst to determine the needs of the business as to where it will be in three years’ time .” That is an impossibility!
So what we do is, we make assumptions. Statistics today tell us that at least 70% of what we build into our initial requirements documents are based on assumptions and should be changed during development if we are to deliver a successful product. What we say in the agile world is this, “the assumption is the mother of all screw-ups.” That is why so many of our developments end up being screwed-up. I know I am being rather blunt here, but statistics today tell us that in our traditional systems development, and by traditional I mean the waterfall approach, we still have not achieved a 25% success rate. Actually I am being quite generous with that statistic, as some organizations today are reporting a much lower success factor.
There is a gentleman n the Information Technology industry by the name of Steve McConnell who runs a Consulting Group in Seattle Washington. Some of you might be familiar with a book that Steve wrote way back in the early 1990s, called Code Complete, and in that book, he presented a graphic that he called the “Cone of Uncertainty”. Most software development subject matter experts of the day agreed with what he had delivered. They agreed that in the development of a majority of systems, this cone of uncertainty always existed at the very beginning of any project. I have attached the graphic here is Steve presented it in his book.
As you will notice, when you are in the analysis phase there is a large amount of uncertainty that we face. It is in these areas of uncertainty that we make assumptions, and it is upon those assumptions that we actually write our software.
Now it is interesting to note that around 2015, Steve conducted a webinar and in that webinar, he said this, “people I have good news and bad news for you. The good news is we no longer face a cone of uncertainty in our development projects. What we now face is the bad news, which is a “Cloud of Uncertainty”. This is far greater and much more widespread than our initial “Cone of Uncertainty”. As a matter of fact, if you look at the attached graphic, you see this carries on right through to the end of the project.
It is in this uncertainty that we define our systems upon. We make assumptions and in most cases the assumptions are wrong. What does this mean? It means what we deliver is not what the business needs. It is not what our stakeholders need to run their businesses efficiently and effectively.
Here is the foundational reality that you need to understand. You see the day after the organization all impacted stakeholders sign-off on the requirements document, the world around the business changes. And continues to change, week by week, and month by month. Yet we are building a system based on a requirements document that was produced two years ago. If a business remains were they were 2 years ago when that system is delivered, then they are a failure. Why? Because a successful business continues to grow. markets grow, markets change, Revenue grows, management changes, standards change, governments change, etc.. The question to be asked here is this, “How are you and your organization addressing this continual enormous change all through the development of the system when you build it in your traditional waterfall fashion.
A prime example at the writing of this blog post is that the world today it’s just coming out of a global lock-down due to the Covid-19 pandemic. Businesses left, right, and center, are going bankrupt. They are closing down. they are down-sizing. Jobs are being eliminated. Unemployment is rising. Multitudes of software systems that were in development prior to this situation beginning, are being shelved. Why? Because these organizations were not agile enough to Pivot and change courses of action continually on a day by day basis, based on the situation on the world around them. This is what “being Agile” is all about. Adapting to this change.
In the agile world, we do just enough analysis at the front end of a development project which is based on those things that we are certain about. We do not do B.D.U.F. (big design upfront). We begin writing software very, very, early in the process. As this software is created based on the things that we are certain about, the feedback-loop, which as Jeff Sutherland co-founder of Scrum says is what Agile is all about, lets us know if we need a “course correction.” This is why the shorter the iteration (the time frame for a build and inspect), the faster we get input from our stakeholders viewing this software. This draws certainty out of uncertainty. This continues to radiate out throughout the system as the more that the stakeholders see, the more we are certain about it. So what we say in the agile world is this, ” we do not build systems based on fixed initial designs, but our systems “evolve”. They “emerge” throughout the entire development process.
The whole Focus of agile is to develop the ability to continually pivot and change direction based on the continually changing world around us. This allows us to continually change and adjust our course of direction, bringing us to the exact point we need to be at when we for the product to our stakeholders.
So I say this to corporate management, Don’t expect your information technology department to know where you will be in three years time. Why? Because you don’t! Business analysts, don’t expect to know exactly where the business will be in three years’ time. I.T practitioner, don’t expect to know where the business will be in three years’ time. Instead, begin as early as possible to begin building a product and then continually inspect and adapt all the way through the building of the product. If you do this and everyone in the organization from the CEO down understands this, then you can say we are AGILE!
Remember “We are AGILE!”
Author: Ed Rubuliak
email: ed.the.scrum.professor@gmail.com
web site: https://theagilemasteryacademy.com