Of Jellybeans and Elephants

Break down how your team delivers software and successfully invite and manage change.

By
Matthew D Edwards
February 4, 2021

Originally published on LinkedIn.

Imagine a world where you have the responsibility of building an elephant.

Will you start at the atomic or cellular level? Will you start at the skeletal system and work into the central nervous and circulatory systems? How about features, functions, capabilities, and constraints? Where will you start?

Elephant made out of jellybeans
As each jellybeans (stories) are completed, a software team is incrementally building the elephant.

How many attempts or iterations do you think it will take to get the job done completely, correctly, and usefully? How about just to get a first, working version?

Now imagine a world where the only time you learn the true value of the work you've done is at the end of each iteration. If all goes as planned, each iteration results in having more knowledge, experience, and value than at the beginning.

You make a commitment to deliver something, you actively work to deliver it as committed, and then you deliver. All as planned.

And as expected, after it is demonstrated to the stakeholders, you receive the feedback you need for the next steps. That feedback tells you one of three things:

  • Let's keep it.
  • Let's change it.
  • Let's head a completely different direction.

Given the size of an elephant, how frequently would you like to have feedback telling you where you are in relation to done?

Jellybean Patterns

In the below examples, look at each jellybean as a complete iteration containing Plan, Work, Demonstrate, Receive Feedback.

Each jellybean is viewed as a complete iteration containing Plan, Work, Demonstrate, Receive Feedback.

Consider these patterns: For someone who delivers daily, they can entertain change each new day. For someone who delivers every two weeks, they can entertain change every 14 days. And for someone who chooses monthly deliverables? Every thirty days. Remember, each iteration teaches you so that you can keep what you have, change to something new, or pivot altogether.

30 deliverables in 30 days compared to 1 deliverable in 30 days.

Author's note: To keep this article simple, I've chosen to use simple numbers (1 and 30) in order to amplify the point through stark contrast. For the rest of this article we'll discuss daily and monthly deliverables.

Since we're building an elephant, I'll take the liberty of suggesting it will take greater than one month. So let's look at what a one-year delivery pattern looks like using 1 day and 1 month as units of measure.

360 deliverables in 360 days compared to 12 deliverable in 360 days.

Comparatively, if we accept that each jellybean is an iteration and that each iteration enables the same plan, work, demo, receive feedback pattern, the above pattern suggests that, through the course of one year, daily iterations enable nearly 97% more opportunities to learn and change than monthly. Likewise, if we assume weekly iterations, there are 80% more opportunities to change your mind than if delivering monthly.

Dial the iteration frequency into what makes sense for your company, teams, and client.

Remember, while you may feel you're choosing iteration lengths, what you're actually choosing is the number of times you develop, deliver, demonstrate, and learn across a period of time.

How many opportunities would you like to try something, learn, and change during a single project?

Let's further explore the superpowers of delivering jellybeans instead of elephants. This time, let's address unplanned change.

Jellybean Patterns and Mid-Cycle Change

Even with best intentions, small iterations, and high-performing teams, change happens mid-iteration. Not ideal. However, occasionally clients and teams experience new variables such as market shifts, attrition, mergers & acquisitions, products and services portfolio pivots, the team missed something, or the client realized they wanted a purple toaster instead of a red car.

Working to mitigate and manage change is good and normal. Eliminating change is neither realistic, nor healthy. Change will happen. Some change is good.

Plan for it. Invite it.

Imagine being in the middle of an iteration and you're required to pick up work that was previously unplanned. Do you stop what you're doing, reset the clock, and pick up the new work? Do you put it in the backlog and get to it when you're done with the current effort?

Does your delivery pattern enable change while minimizing waste (**Where "waste" = time, effort, and deliverables that will not be utilized 'as is' or at all)? Change is driven by economic opportunity and client delight for the company, not project delivery convenience for you.

If you are practicing daily iterations, let's say you started at 0800 hours and I asked you to pivot at 1200 hours. The potential project waste due to the pivot is 4 hours.

Similarly, if you are practicing two-week iterations, you started on Day 01 and I asked you to pivot on Day 6, the potential project waste due to the pivot is 5 days.

So it may make more sense to consider, if you are practicing 30-day iterations, you started on Day 01 and I asked you to pivot on Day 15, the potential project waste due to the pivot is then 15 days.

**Note: A more accurate waste calculation for these examples will be to consider (total_#people_involved) * (total_#hours_expended) * AVG(labor_costs_per_hour) + (overhead_costs (i.e., operational expenses))

30 deliverables with change and improvement inside 30 days compared to 1 deliverable in 30 days.

Now, using the same math argument mentioned above, consider what change looks like spanning an entire year.

360 deliverables with change and improvement inside 360 days compared to 12 deliverables in 360 days.

If value is realized by what is delivered and waste is calculated by what is not delivered, how important do you believe iteration sizes are to realizing value and managing the economic impact of waste?

3 Questions to Ask Yourself

Imagine this is your company and your personal money.

  • How long are you willing to wait to find out if your financial investment was worth it?
  • How long are you willing to wait to find out if your idea is even a good idea?
  • How much will it cost you to change?

5 Steps to Make Sure You Get Results for Your Money

  • Use a small team who strive for simplicity and thrive in change
  • Use small iteration (batch) sizes to provide feedback now, not later
  • Use a Plan, Work, Demonstrate, Receive Feedback pattern PER iteration
  • Focus upon constant delivery (flow) over start-stop behaviors
  • Plan for change. Stay small. Constantly deliver, assess, and change.

What Are You Going To Do Next?

Start with the elephant. Break it down into jellybeans. Deliver a predictable, constant cadence of jellybeans where each jellybean includes plan, work, demonstrate, receive feedback. Invite change.

It may surprise you to discover along the way, the client told you they wanted an elephant when they really wanted a platypus. How would you discover a platypus met the need if you only delivered an elephant sized iteration?

And this is only one scenario.

What if you don't know for sure what you want? How much money are you willing to spend to discover it?

Imagine we're going to spend $5000 of your money.

Do you prefer 50 iterations of $100 where you can change your mind every $100 and find out you wanted a platypus, not an elephant?

Or do you prefer 2 iterations of $2500 where you can change your mind twice, but remain committed to some form of an elephant?

I know what I prefer. Jellybeans enable me the opportunity to change when I need to, and to manage my risk, spend, waste, and time to market.

What does this look like for you?

Defining the Elephant

What do you do if your team, your company, or your client says they need an elephant but you believe they need a whale? Read my previous article, How to Know if You're Adding Value.