Where am I on the evolutionary scale?

At the beginning of this chapter, I stated that the effectiveness of adopting CD and DevOps is very much dependent on where a business sits on the evolutionary scale. We've been through ACME's evolution and the phases it went through. Please take into account that ACME is fictional and its story is pretty simplistic. A real-world business is not simple—far from it—and it is pretty difficult to ascertain where a given business sits on the CD and DevOps evolutionary scale. Without this information, it's hard to understand how receptive, responsive, and open to adoption a business actually is.

With that said, there are some simple ways of getting a clearer idea. For example, the following list of questions can help you get a rough idea. Looking at your business, ask yourself the following:

	Option #1	Option #2	Option #3
Does your business favor process over people?	Process	People	We don't have any processes worth mentioning.
Do immovable deadlines in project plans take precedence over delivering quality solutions incrementally?	Yes, meeting deadlines is the only thing that matters.	We have the flexibility to make small changes, and re-plan to ensure quality doesn't suffer.	We do whatever is needed to keep the customer happy.
Are your projects run with fixed timescales, fixed resource, and fixed scope, or is there flexibility?	Yes, and this is all agreed up front, signed off, and intricately planned.	No, we have flexibility in at least one of these areas.	We do whatever is needed to keep the customer happy.
	Option #1	Option #2	Option #3
Do your developers have access to the production environment?	No, why would we trust developers to not screw things up?	All developers have secure read-only access to the live environments and all configuration via specific tools.	Yes, they have full access to do whatever is needed.
Is failure scorned upon or used as something to learn from?	Failure is failure and there are no excuses—heads will roll.	We ensure failure will have a small impact and learn from our mistakes.	Failure means no more business and we're all out of a job.
Who is on-call for out-of-hours production issues?	The T1 help desk, with the T2 operations support and T3 applications support teams backing them up.	We normally have a point of contact on call who can reach out to anyone they need.	Everyone within software engineering
Are you able to ship code when it is ready or do you have to wait for a scheduled release?	The release team schedule and agree on the delivery into production via the CAB and transition team based upon the agreed program plan.	We trust our engineers to ship code using our deployment tools when they are confident it is ready and doesn't compromise overall quality.	Our engineers normally FTP code to the production servers when it's finished compiling.
Does your senior leadership understand the complexities and challenges of delivering software?	They don't know in detail, but there are many reports compiled and generated by the PMO which are regularly reviewed during project-review meetings.	They all have access to tools which give visibility of the various projects and metrics representing progress.	They don't have the time or inclination to understand this—they expect stuff gets done.
Do the engineering teams have an understanding of how the business is doing from a commercial perspective?	All of the top-level financial information is compiled and published by the CFO to the company intranet every 6-12 months.	They all have access to the tools that give visibility of the current KPIs and metrics representing progress.	They don't, but as long as they get paid, that should be enough.
Does the engineering team have access to customer feedback?	This is normally collected and vetted by the customer service team and raised as defect or enhancement requests.	Customer feedback is captured via specialist tools and available to all.	Yes, this normally relates to defects and bugs that need fixing.

If you were to apply these to the ACME business at certain points through their evolution, you would find that the Version 1.0 business would mostly answer 3, the version 2.0 business would mostly answer 1, and the highly-evolved version of the business would mostly answer 2.

The preceding is simply an example that gives you and insight into how you can—at a very holistic viewpoint—ascertain how mature the business is and where it sits within the CD and DevOps evolutionary scale. You will no doubt have some additional, complimentary, or more relevant questions you could use. However, if you follow a similar format, you will be able to get a feel for where things sit, and more importantly, what areas need the most focus. You should widen the net as much as possible to get a view from as many parts of your business as possible—that way, you won't come across surprises when you decide to take the plunge.