I still remember the look. The questioning, doubting look from a CEO who was disillusioned with the technobabble that technologists often engage in. He was ready for it, and the only question was would I really try to go there?
To set the stage, I was a technology executive for a growing Fortune 100 organization. The organization had dipped its toe in Agile and DevOps waters and invested more than $3 million in its first Agile initiative to build a business-critical system. Eighteen months had passed with no results, no working software, and more than 30 new Agilists were offering excuses for why things were not working. Many of those same Agile excuses are still in use today.
A month earlier, the technology executive leading this initiative was replaced – with me. My job was to either to engineer a turnaround or be the one to blame when I went to face the CEO. And, that time had come. The only questions were what would I be foolish enough to say, and how long would it take for him to kill the project?
What did I say?
What I said to the CEO was, “We have working software in production.” You could have heard a pin drop. The stare changed from palpable anger to disbelief. How did we get there?
Let’s first talk about what we did not do. In short, we did not speak in technobabble and talk of the promises of DevOps and Agile. Instead, we showed him what talented people from technology, the business, and even from “shadow” technology groups could do when they worked together to push towards a shared goal. The synergy was unstoppable.
At the end of the day, Agile and DevOps are touted as many different things. Here are a few examples of how DevOps tools are described in the marketplace:
- “…a single intuitive drag-and-drop UI for all solutions and can act as a central point of management for your entire business.”
- “…automate the full software development lifecycle, preventing downtime, increasing performance, and meeting or exceeding your customers’ high expectations.”
- “…execute key development functions without compromising quality, performance, or reliability.”
And as for Agile, in previous blog posts, we addressed Agile misconceptions. Something very different is going on. 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.
DevOps and feedback
The motivation for DevOps is simple. The projects we work on can be extremely complex. Business change is constant. So, we need a way of working that adapts to constant business change and fosters rapid feedback as we develop software. Agile and DevOps also allow the opportunity to pivot, turn and adjust as frequently as the business requires. This stands in stark contrast to starting a project with a stack of requirements documents and taking months to deliver.
At a high level, DevOps utilizes a set of practices and tools. These automate the way development teams that are building the software product, and those IT teams that are deploying or operating the software. The goal is simple: We want to develop, build, test and deploy software faster and more reliably. If we are successful, the benefits include increased speed-to-market for the business.
There is one important, crucial caveat. Neither DevOps or Agile will work unless technologists and the business are willing to change the way that they approach their work. For Agile, the Scrum Guide puts it this way: “when the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, they build trust for everyone. Successful use of Scrum depends on people becoming more proficient in living these five values.” The same is true for DevOps, as noted on the Atlassian DevOps website: “At its essence, DevOps is a culture, a movement, a philosophy (that fosters) a firm handshake between development and operations that emphasizes a shift in mindset, better collaboration, and tighter integration.”
And there is the challenge. Culture is not created by methodology. Firm handshakes, commitment, courage and respect are not tools. People must put them to use to overcome obstacles and create synergy. We must be able to get out of our own boxes and work differently with each other. The difference between success and failure is completely within our control – if we are willing to change. As I discussed in Leadership Patterns for Software and Technology Professionals, “This type of leadership begins with leading yourself and changing the way you think about yourself, your career, and your work.”
No silver bullet…
As I spoke about leadership and Agile recently to a group in Houston, an executive pointed out that there are no silver bullets, reminding us of an old but proven truth. Nothing you can buy is going to make our problems go away. The CEO that I was working for knew it, too.
And guess what? The same is true for Agile and DevOps. They are only as valuable as the people who are using them and, more important, the way they interact with each other and their customers. Interactions with people solve big problems like the one we were facing. No technology ever will.
Also see Matt's blog, Speed, Adaptation and the Pace of Change
Continue the Agile and DevOps conversation by subscribing to the Genesis10 blog.
