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
57 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

CIOs: We welcome you to join the conversation

Related Topics

Submitted By Gordon Haff
May 24, 2019

CIOs wish for simpler ways to wrangle data and experiment with business models – but change remains hard to scale. Also, it may be time to stop chasing “alignment.”

Submitted By T.R. Kane
May 24, 2019

Organizations that make security an integral part of digital transformation plans gain a competitive advantage, PwC research shows

Submitted By Todd Loeppke
May 23, 2019

Sungard AS lead CTO architect explores how to make a dedicated innovation team work in your organization.

x

Email Capture

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