Agile for everyone! This suggests an image of a medieval monarch making a grand pronouncement."Qu'ils mangent de la brioche," or “Let them eat cake!” was famously spoken by a French monarch upon learning that her poorer subjects had no bread. Should we dance in the streets or be filled with dread?
On the other hand, what is Agile project management? What are Agile principles and techniques? Is Agile for everyone, and should I consider Agile adoption? If so, what does that mean – is it a popular new year’s resolution like “I will give up my daily Starbuck’s Grande Caffe Cocoa Cluster Frappuccino?” Perhaps more important, what’s in it for me? Why should I care as a CEO, board member, CIO, technology executive, Python developer or business customer?
I am guessing you have heard something about Agile, and you have perhaps formed some opinions-- maybe even some strong opinions. Let’s shine some light on these questions and pose some thoughts to ponder going forward.
1% Clarity and 99% Confusion
Let’s first start with one of my favorite questions to ask audiences that I speak to or job candidates: What is Agile? In my line of work (executive consulting, speaking, and teaching graduate students), out of 100 responses I will generally get 99 that miss the mark. The most common response is an attempt at an Agile methodology definition. However, Agile is bigger than methodology--it addresses the way we think and work. Specifically:
Agile is a set of values. Scrum, Kanban, and Lean are specific instantiations of Agile values and principles.
In 2001, the original 17 signatories of the Agile Manifesto met and agreed on a set of values for building technology. They each came from a different background, but all realized that the way to develop software and technology needed to change to realize its full potential. The Manifesto reads:
…we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
So, Agile techniques are not a methodology or a software development life cycle tool. They are a set of values, and more about people and the approach that we take to our work than tools. When we speak of Agile as a tool or software development life cycle, we confuse and dilute its meaning. People see, experience, talk, and propagate their misunderstanding. It’s a bit like the old game of whispering a message from person to person around a circle of 20 people….by the time the message gets back to the start, it is completely different.
You might try your own experiment and ask, “what is Agile?” of a few technologists over lunch or coffee. Then try asking business people. You might be surprised at what you hear, and the lack of agreement.
Why is this important? This lack of clarity hurts everyone. Technologists may develop a fuzzy sense of what Agile is by looking at a diluted imposter. When they speak to customers, additional confusion is created. Customers and business partners do not understand what we are trying to talk about, don’t care, or simply don’t take the time to understand. This ultimately makes our jobs harder. This confusion creates inefficiency, hampers effective technology delivery, and damages careers. Surely there must be a better way.
A Difficult Pivot
In an Agile project, the team views their world very differently. Consider the first value: Individuals and interactions are more important than processes and tools. This concept is the opposite of the way most technologists were trained. Over the course of obtaining an undergraduate degree in computer science, tens of thousands of hours are expended in focusing almost entirely on technology, tools, computing systems, and languages. During this immersion, technologists begin to believe that technology drives career success – and not people. Now we are speaking of individuals and interactions? What happened? What training or background do these graduates have in this area?
Customer collaboration is another value that may be challenging for technology teams. Many technology processes aim to intentionally front load customer interaction to define and negotiate contracts and requirements. Some of the requirements may be necessary and meaningful as a new product’s high-level system design is discussed. However, some of it may be an attempt to short circuit customer interactions and the creativity found in teamwork. In addition, technologists don’t necessarily enjoy spending time with customers – developers signed up to work with technology, not people. Business analysts may feel threatened if someone else is doing “their” work. Executives may worry that more interaction with customers may lead to increased scope and expectations.
So, despite the excitement and buzz about Agile, these transitions are hard. Over the course of multiple conversions, my experience is that about 60% of traditionally oriented technologists can make this transition. Organizations don’t fare well, either. It requires a pivot and change in orientation that may be completely alien. We may have become comfortable hiding behind requirements documents, email, and voice messages rather than engaging in face-to-face interactions. Holding onto these past habits hampers productivity and an agile transition. When the results of “going Agile” fall short of expectations, we think Agile has failed. The reality is that not enough emphasis has been placed on disciplines such as change management, training, mentoring and cultural alignment – all of which are focused on bringing about meaningful change to the way individuals and interactions work in technology development.
Succeeding and Failing Gloriously
So, one might ask: Is it worth it? After all, we already have enough to do! Individuals don’t like change. Organizations and executives hesitate to spend money and time on initiatives that don’t positively impact next quarter’s earnings report or profit.
The answer is a resounding yes. I have led multiple Agile transitions and engagements at Fortune 100 publicly traded, and smaller privately held midsized companies. Where these transitions have been proactively planned and carefully executed, the results have been transformative. Technology teams have increased their productivity by more than 100%, and companies and careers have been dramatically changed. Businesses have seen their technology teams morph from a source of irritation and cost to driving competitive advantage and innovation throughout the company. Yet, for every Agile transition that succeeds, there are many others that fail as we fall back into old habits.
So, transitioning to Agile is not easy or simple, but it can be very rewarding. It can absolutely change businesses and careers. First, we should remember that Agile is not a new tool or a different way of organizing teams. Ultimately, it is about people and changing the way we work. We must unlearn old habits and buy into a new set of values. If you are not realizing the benefits from your technology spend, or believe that people are creative and have amazing potential – Agile just might be for you.
Matt McBride's blog post, Dance or Dread: Is Agile for Everyone? first appeared on CIO.com.
