One of my favorite scenes in Finding Nemo is when Nemo and friends successfully escape the dentist’s office, land in the ocean in their plastic, water-filled bags, look around and consider their accomplishment, only to hear Bloat, the pufferfish, ask the perfect question, “Now what?”

Your team invests so much time just to get to this point, but they haven’t planned, or in many cases, even thought about what comes next. Instead of being ready to move on to the next opportunities, they’re sitting in the water, bobbing up and down, and breaking their flow to reorganize and plan their next steps.

This easily happens to agile teams that work on their user stories up to the last minute of the sprint,  leaving them little time to plan the next one. Agile teams applying release management practices run into similar challenges when racing to finish and deploy a release but with little planning for the next one.

The impacts of just-in-time (JIT) planning can be significant and long-lasting. I share three examples below from different disciplines: product management, software development, and data governance, and end with how agile continuous planning can help resolve them.

1. Planning the product roadmap, JIT the go-to-market plan

Bringing a new product, customer experience, or service upgrade to market has the challenges of translating new ideas into realities. So much so, that many product managers are often consumed with the work required to plan and deliver the capabilities and lose sight of what comes next once they are released to customers.

The most immediate concern may be in transforming the behavior and gaining adoption. But Gabriel Smith, chief evangelist at Pricefx, says the longer-term impact on customer-facing products and services is likely to be in managing the supply chain and pricing the product or service.

Smith says, “JIT can be a solid strategy to save money and avoid stockpiling, but it puts massive pressure on each link in the chain to be perfect. Understand this value with customer-centric segmentation and analytics, and use transparent pricing. With today’s volatility and supply chain disruptions, be proactive with optimized, dynamic pricing and what-if simulations to reduce risk and optimize margins and revenue.”

Planning an MVP should include an MV go-to-market plan. This plan should include an operational model (including supply chain), a transformation plan (for rolling out to customers and capturing feedback), and a dynamic pricing model (to ensure or maximize profitability). This business planning is possible – but requires a dedicated team to build and evolve the go-to-market plan as the delivery team works on the product or service.

2. Planning the features, JIT the architecture plan

You see similar issues in tech and software development disciplines when agile teams focus on feature delivery with minimal (no?) discussion around the architecture. That’s a devops antipattern that often leads to avoidable and unnecessary technical debt or even frankenarchitectures.

Frédéric Harper, director of developer relations, Mindee, explains, “One of the main issues with JIT planning in software development is potential architecture problems. With the JIT approach, developers code the items that are the highest priority within the moment, meaning that most of the time, architects/developers fail to envision the big picture.

Harper goes on to explain the challenges with JIT planning. “Once the teams wish to move on to another feature creation or modification, the code structure, implementation, or technologies may not be adequate. It’s at that moment that many teams start to perform ‘quick fixes’ to make codes better, but in nature, these short-term solutions have been proven unsuccessful.”

3. Planning the dashboard, JIT the dataops plan

With all the self-service BI tools available and momentum in citizen data science practices, it’s easy to lose sight of the underlying data plumbing required to operationalize dashboards, data visualizations, and machine learning models. I’m referring to automating the data integration, instrumenting data quality practices, instituting other dataops’ best practices, or planning the modelops.

Organizations can have their cake and eat it too when a citizen data science center of excellence balances delivery (from data viz to machine learning models) with the required dataops and proactive data governance.

But underinvesting in the end-to-end data management practices can lead to disaster; manual processes, misinterpretation of the results, and significant data debt.

Continuous agile planning in product, architecture, and dataops

When you push the gas pedal down hard in your car, you still have a plan for getting to your destination and what you plan to do on arrival. And you’re using GPS to update you on traffic so that you can course-correct and even pivot if required.

Continuous agile planning is a practice for agile, multidisciplinary teams that requires teams commit to planning, delivering, and transforming every sprint. There’s a card type for each of these activities, so that product managers, delivery leads, and teammates balance their work depending on where they are in the release cycle. So, for example, at the end of a release cycle, teams should be committing to transformation cards (to ensure the current release meets end-user and business needs) and planning cards (to have some of the backlog planned for the next release cycle). Planning and transforming doesn’t come for free and needs their spots on the backlog and in team commitments.

So if your team isn’t planning sufficiently, think about formalizing to an operating model that includes agile continuous planning.