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.
