In May 2017, Red Hat CEO Jim Whitehurst drew a stark conclusion in his keynote presentation at the annual Red Hat Summit event in San Francisco: "Planning as we know it is dead." He said those same words again during a Red Hat planning session in October of 2018, when a cross-functional group of Red Hat leaders assembled to assess the current state of the business and discuss the roadmap for the coming year.
The technology landscape and business environment are changing so quickly, Jim argued, that trying to conduct planning activities in any kind of traditional way just isn't possible anymore. For some, this is a radical idea—and a deeply uncomfortable one. For others, the idea that we can't do traditional, long-term planning is obvious. The question (and much confusion) arises when we start thinking about what we will do when long term planning is no longer possible.
While we can no longer plan in the traditional, comforting way of specifying a fixed roadmap and making steady, foreseeable progress towards it, we can still have a strategy with goals that help us achieve it. The big difference in approach is understanding that the plan will evolve as we go and we need to make real-time adjustments based on results. That means doing things in smaller chunks, getting feedback from customers and stakeholders, and modifying our approach accordingly.
In this spirit, Jim suggested that we replace long-term planning with a more experimental approach, one common in open source software development: "Try, learn, modify." I believe in this approach and use it frequently in my work, but it's not without its challenges. Misconceptions about it can steer people in wrong directions. In this chapter, I'll walk through some of those misconceptions and offer some ways we might think differently about iterative approaches to achieving goals in an era when planning is dead.
1. "Agile" isn't a catch-all
The term "agile" originated with a specific meaning related to flexible but disciplined software development. Over time, other industries and professional domains have discovered the benefits of rapid iteration, radical customer-centricity, continual feedback, and cross-team collaboration.
But I've seen "agile" become a kind of catch-all phrase people use without much reflection. I'm not an agile expert (and I don't pretend to be), so when I hear people using "agile" outside of its original context, I like to ask clarifying questions about intent. In other words, What does being "agile" mean for your work and what are the benefits? This might mean asking:
- How does your team prioritize its work?
- How often does your team share, or "release", its work to get feedback?
- How does your team process the feedback, balance contradictory feedback, or weigh feedback from different stakeholders?
- How easy is it for your team to adjust course based on feedback?
- What indicators does your team look at to understand if it's moving in the right direction?
Asking questions like these can help focus the discussion and clear up the assumptions and confusion that terms like "agile" can create. They prompt people to clarify what (if anything) about their processes is actually agile. I try to make it a regular practice to dig in deeper when people cite "being agile" as a reason for not planning or prioritizing.
2. "Planning is dead" doesn't mean "we don't have goals"
Instead of saying "we're agile" as a proxy for "we don't have a roadmap, or a plan, or even a vision," I like to talk about flexibility and the need to iterate on our approach as we move toward a long term goal.
For example, currently my team at Red Hat (which creates the product documentation for all Red Hat products) has a long-term plan of making our content more flexible and customer-goal oriented—of moving away from the traditional "product reference book format" that we've used previously. This change is a huge shift in how we conceive of, plan, and execute our work, and we've taken this long-term focus as a result of customer feedback. In making the change, we need to balance the demands of short product release cycles, continual streams of incoming feedback, and limited resources. Making an important change in how we approach our work is like changing a car's tire while we're still driving it.
So we need to be creative, try different approaches, and shift gears quickly based on real time results and experiences. We can't set the daily demands of new content creation aside to focus on the reformulation of the existing content, but we also can't move forward without making progress towards the change. That'd be like driving a car with a flat tire indefinitely.
The best way to move forward is to focus on small chunks. In the case of my team, if one product has five reference manuals done in the "old style," we may continue to maintain four of them status quo, making just incremental changes—and completely rewrite one of them in the new, modular style during a product release cycle. We put that content out there, get feedback from stakeholders and customers, and then adjust our approach as we tackle another small chunk in the next release cycle.
Under the old "waterfall" model, we may have taken years to work on changes across all content, pausing other work, and then releasing the new content all at once to customers. But product release cycles aren't done over the course of years any more; they happen over the course of months. While keeping up with that pace of can be challenging, the new cadence also gives us the continual ability to get feedback as we work—so we know if we're on the right track and we can make adjustments quickly if needed.
As you look at your work, there are some questions you can ask yourself, your peers, or your leadership to better understand the long term plan if it feels like the work is haphazard:
- Do you know what the long term vision is for your team? What do you hope your customer experience looks like in three years? In 12 months?
- Do you understand how the long-term vision for your team connects to the goals of the company as a whole?
- Do you have short term goals? In other words, for the work that you are doing right now, do you understand what you (or your leadership) are hoping to achieve with it? And how does that short term goal contribute toward that longer term vision?
Questions like these can help you understand, or tease out, the purpose behind the work you are doing. They can also help the team avoid the pitfalls of using "agile" is an explanation rather than as a method (e.g., "we're doing it this way because we're agile" versus "we're using this agile method to achieve our goal").
3. "Constant change" doesn't mean "total chaos"
At the heart of "try, learn, modify" is a state of constant change. We all know change is hard. We experience it personally and we see it every day in our work and lives. This basic human truth substantially complicates the reality we face: having to continuously adjust our work to suit the changing environment.
Even people who embrace "agile" can have hard a time with change. We have a reflex to resist it, question it, avoid it, and fear it. It makes us uncomfortable and insecure. Even people who purport to love and embrace change can have a hard time with it.
I'm one of those people. As a leader of a team, I see the need for change. But as a member of a team of leadership peers, I know I'm uncomfortable when it's "inflicted" on me.
What I try to tell my team is that we can make change easier by understanding that it is inevitable (indeed, it is part of the plan), by anticipating it, and by being excited about the possibilities rather than being afraid of the unknown. One question I've been asking myself recently is this: Has there ever been a year in my professional career (or my life for that matter) where I could successfully predict what would happen during the course of the year? The answer is a resounding "no"; something unexpected always happens. Change is routine.
Many people have (or have developed) a comfort with change that is truly remarkable to observe: a calm openness to trying out different approaches, an unthreatened willingness to explore possibilities, a desire to talk about how we might be more effective if we did things differently. So my advice for improving how we deal with change is to observe how we react to it:
- Do you feel like somebody else is being "political"?
- Do have the urge to protect "your territory"?
- Do you find yourself explaining why we need to keep doing things a certain way?
- Do you ask yourself why "upper management" is making so many bad decisions or sending mixed signals?
In my experience, all of these are signs of discomfort with change. Left unchecked, they can sew distrust of others' motivations. If you feel any of these things, explore those feelings and discuss them with your leadership and your team.
Being open about discomfort is a great way to move past it. And if we can get past the discomfort, it can be a lot of fun.
2 Comments