DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Planning: Risk Management to Manage Uncertainty

Planning: Risk Management to Manage Uncertainty

Software development projects tend to involve some level of uncertainty with consumers. Learn how an Agile approach can help.

Johanna Rothman user avatar by
Johanna Rothman
·
Aug. 06, 18 · Opinion
Like (2)
Save
Tweet
Share
3.43K Views

Join the DZone community and get the full member experience.

Join For Free

Many organizations plan to create certainty, guarantees of some variety. What if we thought about Agile planning as a way to manage uncertainty?

When I look at long roadmaps with all the "must-do" feature sets and the pressure managers put on teams to commit to delivery, I wonder about this question:

How well do we understand the problems we want to solve?

I find these questions help me:

  • Do we understand the customer's current problem(s)?
  • Is this the same problem the customer had before? Our delivery might have changed the customer's thinking about the problem was. Our delivery might change our perspective on this problem.
  • Did we already deliver enough to solve this problem and we can move to another problem?

The less we understand the problem(s), the more we need to experiment. The more we need experiments, the more we need rolling wave planning.

The more we use rolling wave planning for learning and feedback from those experiments, the smaller the stories need to be. That's so we can obtain feedback.

The smaller the stories, the more frequently we can update the planning. The more frequently we can update the planning, the more we can create somewhat firm roadmaps for the near term and more hypothesis-driven roadmaps for the long term. (See the Agile and Lean Roadmapping Series.)

In preparation for my talk at Agile 2018, I created this table to explain how not every problem set is the same:

The left-most column is about well-understood problems. If we understand the customer problems well, we might be able to plan (and execute against) a six-quarter roadmap.

It's relatively easy to create a roadmap, populate it, commit (in some way) to it, etc. That's because the problems don't change.

We might still have problems where management wants the teams to break the laws of physics, but that's actually a manageable problem. (At some point, the Queen of Denial recognizes reality.)

In the middle column, if we mostly understand the problems, maybe we use a limited horizon and expect to use rolling wave plans with MVPs or some such minimums. We need the feedback to refine our plans. (I happen to prefer a three-month rolling wave, but that might not be enough planning for you.)

The risks here are that the problems change faster than our rolling wave and deliveries. Can you "guarantee" or commit to anything? You might, especially if you keep commitments to not more than one month of work. (I'm not positive about even a month, but that's quite product-dependent.)

Now, the right-most column table is where I see many organizations slipping into desiring guarantees instead of managing uncertainty. When we have significant uncertainty, I like to have a "roadmap" of the Big Ideas and Experiments, not of feature sets. I like a one-month rolling wave to see how small we can make those Big Ideas and Experiments. (Yes, I need to create an image for that.)

An Agile approach works well for Mostly Understood and Not At All Understood problems because we need to see progress and verify that the progress solves the variety of problems.

We don't need an Agile approach if we have a well-defined unchangeable customer problem. We might use an Agile approach to help everyone understand our progress, but we don't need an Agile approach.

The more we need feedback to inform our future planning, the more we need an Agile approach. That means an Agile approach to planning, even at the roadmap level so we can manage uncertainty, not eliminate it.

planning Uncertainty agile

Published at DZone with permission of Johanna Rothman, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Learning by Doing: An HTTP API With Rust
  • Data Ingestion vs. ETL: Definition, Benefits, and Key Differences
  • How To Use Terraform to Provision an AWS EC2 Instance
  • Pair Testing in Software Development

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: