Rawpixel.com - stock.adobe.com
Continuous planning -- a DevOps strategy that constantly reassesses and updates software delivery plans -- is one of those things that sounds great in theory but can be quite messy to put into practice.
While it makes sense in some situations for DevOps teams to implement something resembling continuous planning, a truly continuous planning strategy is not always feasible, and could sometimes create more trouble than value.
Let's break down what continuous planning means in DevOps, the theoretical benefits and practical challenges associated with it and how to adopt a healthy perspective on continuous planning.
What is continuous planning in DevOps?
In DevOps, continuous planning is a strategy whereby teams constantly evaluate and modify plans related to software delivery. For example, they might decide to kill a new feature that they've recently begun to implement and reallocate development resources toward a different feature that market research suggests customers prefer. Alternatively, teams could push back the target date for a new application release because the QA team has found more bugs to fix than anticipated.
As with everything else that DevOps teams label continuous, such as continuous integration and continuous delivery, continuous in the context of continuous planning is a relative term. No one can reevaluate plans on a literally continuous 24/7 basis. Instead, DevOps teams that strive for continuous planning typically aim to update plans at most a few times per week.
That may not be literal continuity, but it does result in much more frequent plan reevaluations than traditional software delivery approaches, where changes often occur just once or twice a year.
The benefits of continuous planning
The main benefit of a continuous planning strategy is simple: When you frequently reevaluate your plans and update them based on new insights, software planning becomes more agile and proactive. You can get ahead of emerging challenges in software delivery operations, and you can identify and act on new opportunities as quickly as possible.
Continuous planning also provides more opportunities for DevOps engineers, QA teams and other stakeholders in the software delivery process -- including nontechnical business users who depend on the DevOps team to build applications for them -- to check in with each other about the status of development operations. Frequent check-ins encourage collaboration and generate opportunities to routinely develop new ideas.
The challenges of continuous planning
Continuous planning, however, also presents some significant challenges.
One is that continuous planning can slow the velocity of software delivery. Constant discussions and updates can distract teams from actual development. A team that meets multiple times a week to check in about development operations has less head-down time to write, build, test and deploy code.
Even worse, frequent updates to plans may cause much of the code that DevOps engineers work on to become irrelevant. For example, a sudden decision to abandon an in-progress feature means the time spent on that feature was for naught. This not only slows down software delivery but also disappoints developers who worked hard on something that will never be released.
Continuous planning can also be challenging from a business perspective. If priorities are constantly shifting, business stakeholders might struggle to know what's really coming next from their DevOps team. Marketers might begin planning a campaign to promote a new feature only to discover that engineers dropped it because they decided it posed unforeseen technical challenges.
When does continuous planning make sense for DevOps?
Despite the challenges, continuous planning can be a smart strategy. As always, DevOps teams should carefully weigh the benefits and drawbacks of continuous planning based on their organization's needs.
Continuous planning is typically worth the challenges if your business operates in a highly dynamic environment. For instance, a startup trying to disrupt a market with a new application will typically benefit from continuous planning more than an enterprise that maintains a well-established, widely used application.
DevOps team size is another factor in the practicability of continuous planning. Small teams stand to gain less from ongoing formal check-ins because they likely communicate informally among themselves easily enough. On the other hand, continuous planning could be valuable when a project has many stakeholders and needs a structure to regularly incorporate multiple perspectives.
Striking the right balance
Remember, continuous is a relative term. If updating software plans multiple times per week doesn't make sense for your team, there's no reason why you can't assess your plans once or twice per month instead. This would enable more planning agility than you'd get from traditional approaches to software planning -- without the drawbacks of constant plan changes.