From building buildings to building software.
In the 1950’s the Waterfall Development Model was introduced into software design and development. The system is a relic of the manufacturing industry where, by necessity, the right answer had to be devised before work started. And, in that world, the right answer makes sense! Could you imagine a scenario where you decided to build a skyscraper differently half way through the build?
That said, the byproduct of the use of this process in software development is that the design of the software (feature + ux) had to be right upfront. A typical development cycle started with Marketing doing some research on a market and a problem and providing their insights in the form of a Market Requirements Document and/or Product Requirements Document. The development team would then hunker down and build what the Marketing team said the market wanted and when they finished they delivered the finished product back to the Marketing team whom helped get it to the customer. This model worked. And it worked very well for companies like Microsoft.
- Something is missing in this process. The Customer.
- The Organizational Anarchists
- What is Agile?
- The anti-Mad Men approach.
- Establishing An Agile Component in a Hierarchical Business
- Three Guiding Things to Keep in Mind
- Agile is About Leadership, Not More Management
- What Starts as Eye Rolling Can Become Eye Opening–if You Let it
- Order the Book
In the late 90’s the internet was rapidly growing into a commercial hotbed stacked with new fangled internet companies and, potentially more importantly, was beginning to provide a viable means to deploy software. No longer was the developer required to hand off their final product to the Marketing team on a gold master they could now deploy the final code straight to the internet and straight to their customer.
With the deployment of their software straight to the customer, the developers and designers had instant access to quantitative data about how their product was working. Not qualitative feedback from Marketing but actual customer interaction data. Which features were used and which were not! All good news right? No.
The Waterfall Development Model and its business processes for which the last half a century had shown a successful path stopped working. It didn’t allow for real-time feedback. There was no concept of quick iterations.
In 2001 a group of developers and organizational thinkers met at a Resort in the mountains of Utah to discuss how new process could enable better connections to customers and result in stronger teams and better software. In that meeting the Agile Development movement was born and it’s now considered to be the preeminent system for building software. Think hard about the last time you met an engineering team that was talking about their backlog and their current sprints…it’s profound how quickly and fully this system has been adopted.
As our engineering brethren were dealing with one of the most disruptive process changing time periods in the past century Marketing stood by relatively unaffected. Our benefit from the newfound agility in engineering was our ability to say that Our products are shipped continuously. Other than that, we blindly plodded through the business processes and systems we’ve been using for the last 100+ years. A set of process that looked eerily similar to the Waterfall Development Model.
Marketing came up with the right answer in the form of a campaign, a tagline, a logo and then went away until we were done before emerging from our work to emblazon our work into it’s presiding channel. And why would we change? This tried and true process has worked for decades. But it doesn’t work anymore and we have Dorsey and Zuckerberg to thank.
The popularization of social networks has made it incredibly easy for our customers and prospects to respond to our campaigns, taglines and logos en mass. That’s a good thing right? It should be however, in marketing, we are hamstrung in our ability to respond because of the lack business processes. We are not agile.
In 2011, in San Francisco, a group of marketers met to discuss the social and technical changes that are requiring marketing teams to work differently. A recognition that the parallels between the engineering and marketing were relevant and that the Agile Development Manifesto should be a model for Marketing.
Agile is a systematic way to meet the practical, day-to-day needs of a business, while still preserving some “impractical” time to explore new opportunities and experiment. The pendulum constantly swings between innovation (coming up with new ideas and trying novel solutions) and marketing (figure out what job customers need you to do for them) and being agile allows you to solve for prioritization of both.
Let’s be honest. Whether it’s due to real or cultural constraints, most businesses feel they don’t have the time or the money to experiment–and probably never will. But without experimentation, status quo businesses eventually lose out to disruptive businesses. Not experimenting based on new business opportunities is like saying you’re too busy making a living to learn, grow, and change in your personal life.
This common dilemma begs the question:
How can your company capitalize on today’s rapid-fire strategic challenges while still meeting short-term and long-term financial numbers?
I believe the answer is to use agile practices, which involve many small, measured, exploratory steps—not one large, expensive, chiseled-in-stone strategy. In other words, agile is the anti-Mad Men approach.
Agile provides the opportunity to explore unknown ideas within a stable process that provides innovation with reliable levels of efficiency. It’s a way to try new things and still make your numbers. One major obstacle to innovation is that the traditional company hierarchy structure excludes many of the most innovative employees by work role definitions, by politics, and by overbearing aversion to risk.
Kotter lists the eight necessary elements required for traditional business to begin to develop an exploratory culture from within. These are the same elements required to develop agile practices, I believe.
- Urgency is critical – The business opportunity or threat must be urgent enough to prompt action. Remember the elephant. He runs on emotion. Find a threat he can get into.
- Establish a guiding coalition – For those who want to be part of the new agile network, they must come from various departments and have broad levels of responsibility and authority within the hierarchy. And, perhaps most importantly, members of the coalition should be volunteers to the agile network. This is a want to group of people, not a have to group.
- Have a vision through the development of initiatives, questions to find answers to, tests to try. – Whatever the business opportunity, develop an idea of what you expect you explorations might turn up. Even if they are wrong, they should serve to motivate the natural urge to know. The vision should pique interests and curiosity.
- Communicate the vision for buy-in from the rest of the agile group and the company as a whole. – State your hypotheses clearly. They don’t have to spot on, but they do have to be interesting. Give everyone an idea of why you chose some initiative to explore and choose a good writer who can express it in plain, simple language.
- Empower broad-based action. – The power of the hierarchy is also its biggest weakness. All the decision making is relegated to the top. In the agile network, ideas and expertise can come from anyone. Although there is a guiding coalition, the object is to remove barriers, not maintain a chain of command. That impulse is the hierarchy trying to regain control.
- Celebrate small, visible, short-term wins. – Your agile network won’t last long unless you show value fairly quickly. Hierarchy skeptics will be quick to crush your efforts, so don’t go big right away. Do something small. Pick an attainable initiative. Do it well. Practice the agile process. That will build momentum.
- Don’t let up. – At the same time that you need a victory, don’t declare too much of a victory too soon. Agile is about learning from mistakes and readjusting. Keep pushing forward, because when you take your foot off the gas, that’s when cultural and political resistance will arise. Make time for your network initiatives. Stick to it, no matter how much routine, busy work pops up.
- Incorporate the changes and the lessons learned into the culture of the business as a whole. – This is how the agile network can inform the hierarchy. When you find better ways to do something or new opportunities to pursue, work them into the “other” side.
Not only are those Kotter’s eight steps key to success, but he gives three guiding principles to keep in mind.
- The eight steps are non-sequential. These steps are a model, not a process or procedure—a shape, not an orderly progression. They should all happen, but they don’t have to happen in any particular order. Don’t lose steam worrying too much about order.
- The agile network must be made up of a volunteer army. About 10% of the workforce will suffice, as long as the people in the network want to be there. Don’t be exclusive or closed to participation, but also don’t try to recruit people who are 100% structurally minded, because they won’t enjoy being there and they won’t see the value of it. As Kotter says, “The volunteer army is not a bunch of grunts carrying out orders from the brass. Its members are change leaders who bring energy, commitment, and enthusiasm.”
- This agile group must function with people who work within the hierarchy, but must maintain a network for flexibility and agility. The network is like a solar system with a guiding coalition at the center and initiatives and sub-initiatives that come together and disband as needed. The network cannot be viewed as a “rogue operation” or the hierarchy will inevitably crush it.
Agile is a game of retraining the modern workplace for better vision, opportunity, response, inquiry, curiosity, inspired action and celebration. It’s NOT project management, budget reviews, reporting, chains of command, compensation or accountability to a Mad Men all-in strategy. It’s two systems in ONE organization that complement–not duplicate–each other. Ideally, workers who thrive in the agile network can bring that newfound energy to the hierarchy, too.
The new agile network may at first feel like one big, soft, squishy, employee engagement exercise. That’s fine! It evolves. It’s not a sudden or dramatic change. Like team building exercises, it takes a certain level of comfort and trust developed over time.
Keep going. Keep the steps small. Communicate the victories from the start. Get your feet underneath you while you sell the agile network to the existing hierarchy. If you do all this, the business value will emerge before the hierarchy can dismiss it as silly, different, a waste of time, or whatever other pejorative usually comes out of the 90% to castigate the 10%.
Today’s waste of time leads to tomorrow’s great idea. Agile work—like creativity itself—is not a game of 95%-or-better success rates. If it were, then everyone would be doing it.
And there would be no opportunity, if everyone were doing it.