"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.
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.
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.
