3 DevOps, agile, and scrum myths, debunked

3 DevOps, agile, and scrum myths, debunked

These misconceptions hold teams - and individuals - back. IT leaders need to put them to rest

up
28 readers like this

on

January 31, 2019
CIO Hands Communication

"If you want a happy ending that depends on where you stop your story." – Orson Welles

Storytelling is not unusual in technology. Both technologists and business customers tell themselves stories. We want to believe that our project will deliver on time, that customers will be delighted with our work, or that the latest release of the software will solve their problem. Business users want to believe us. Unfortunately, many of these stories are myths – a story that may or may not have a determinable basis of fact.  

When I attend governance reviews, no one ever tells the audience that their project is a failure. There is always a somewhat credible story. And yet, a survey from cloud portfolio management provider Innotas discovered that 55 percent of businesses surveyed had experienced an IT project failure within the previous 12 months. This is true for all types of projects, and all types of methodologies.

[ Some common DevOps wisdom falls flat. Read 7 pieces of contrarian DevOps advice. ]

Failure and myths can exist in DevOps, agile and scrum environments, too. While leveraging transparency, inspection, and adaptation into our work with customers helps us have a more honest discussion with the business, we are still prone to overcommit and underachieve. Debunking some common agile and scrum myths may help everyone move the ball forward in 2019.

Myth #1: Agile, scrum, or DevOps will save us

Agile and scrum point us to more than just a process or framework. And DevOps is not just about technology. With these enabling tools, we are changing the way people work, and in the process changing the role of the technologist from code writer to critical thinker, and from order taker to business partner.

[ Some people get confused about Agile vs. DevOps. We break it down: Read Agile vs. DevOps: What’s the difference? ]

But the reality is that no technology, process, or framework will be effective unless both technologists and business stakeholders are willing to change the way that they interact. This kind of value-based cultural change is not created by methodology. 

We must be able to get out of our own boxes and work differently with each other.

Commitment, courage, and respect are not just nice words – they are a few of the key values noted in The Scrum Guide. They are outward signs of an internal change in how we work. People must put them to use to overcome obstacles and create synergy.  

Technology is hard and sometimes messy. We solve complex business problems with nuances and expectations that are often unstated. We must be able to get out of our own boxes and work differently with each other. Frequent interactions and feedback help us deliver software more rapidly and keep up with market demand.  

Myth #2: Plans are waterfall, not agile

Let’s be serious. No organization should invest a significant amount of time and money into an agile initiative without reasonable assurances that there is a credible plan in place to achieve the goals and an understanding of what will be built. Planning and risk reduction are not anti-agile, and they can come in a variety of forms.  

We are not regressing to waterfall and heavyweight documentation when we demonstrate a well-thought-out plan that is credible.

To start a large initiative, a few baselines are important. Perhaps the most important of these is to have a documented agreement of what the project or system will do. In technology, we frequently get stuck on trying to do this in either requirements or user stories, both of which are too long to expect executive sponsors to read. An executive will read and provide feedback on a two-page document; they won’t take time to read requirements.  

Following this, we need to establish some architectural and project planning baselines, and then formalize this into a concise presentation that allows us to tell a compelling story that establishes our credibility for executives and other stakeholders. More important, doing this lowers the project’s risk and raises the probability of success.

We are not regressing to waterfall and heavyweight documentation when we demonstrate a well-thought-out plan that is credible. We are showing executives and sponsors that we care about their investment and have a reasonable plan for success. 

Pages

Matt McBride has led multiple technology transformations from the ground up in Fortune 500 organizations such as Countrywide Financial, Bank of America, Tyco, ADT, and 1st Global.  He currently serves as Executive Vice President of Digital and Agile Transformation at Genesis10.  Matt brings a front-line perspective and insights on these initiatives, and regularly advises and consults with executives and boards nationwide.  Matt previously served as the Chief Information Officer for 1st Global Resources, a nationwide broker dealer and investment advisory firm headquartered in Dallas. 

7 New CIO Rules of Road

Harvard Business Review: IT Talent Crisis: Proven Advice from CIOs and HR Leaders

CIOs: We welcome you to join the conversation

Related Topics

Submitted By Jeremiah Cruit
March 22, 2019

As automation touches more of your organization, security will be far from automatic. Bots’ privileges need close scrutiny, for example.

Submitted By Enterprisers Project
March 22, 2019

Is that IT manager salary competitive? Let’s explore data points on salaries - and options that may help you earn more.

Submitted By Carla Rudder
March 21, 2019

If you are job hunting, you’ll hear this advice over and over: “Tap your network!”

x

Email Capture

Keep up with the latest thoughts, strategies, and insights from CIOs & IT leaders.