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?
As each jellybean (story) is 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 getting 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 has more knowledge, experience, and value than at the beginning.
You commit to delivering something, actively work to deliver it as committed, and then deliver — all as planned.
After it is demonstrated to the stakeholders, you receive feedback for the next steps. You learn one of three things:
Given the size of an elephant, how frequently would you like to have feedback telling you where you are in relation to done?
In the below examples, look at each jellybean as a complete iteration containing Plan, Work, Demonstrate, and Receive Feedback.
Each jellybean is viewed as a complete iteration containing Plan, Work, Demonstrate, and Receive Feedback.
Remember, each iteration teaches you: 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 used simple numbers (1 and 30) 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 suggest it will take more than one month. So, let's examine a one-year delivery pattern using one day and one month as units of measure.
360 deliverables in 360 days compared to 12 deliverables in 360 days.
If we see each jellybean as one try that follows the same steps of planning, working, demonstrating, and getting feedback, then in a year, daily tries offer almost 97% more chances to learn and adapt compared to monthly ones. 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 clients.
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.
Even with the best intentions, small iterations, and high-performing teams, change happens mid-iteration. This is not ideal. Occasionally, clients and teams experience new variables such as market shifts, attrition, mergers and acquisitions, product and service portfolio pivots, the team missing something, or the client realizing 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 finish 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.
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.
If you are practicing 30-day iterations and I asked you to pivot on Day 15, the potential project waste due to the pivot is 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 within 30 days compared to one deliverable in 30 days. The orange and green jellybeans demonstrate where changes and adjustments were made.
Now, using the same math argument mentioned above, consider what change looks like spanning an entire year.
360 deliverables with change and improvement within 360 days compared to 12 deliverables in 360 days. Again, the colors signify where the team was able to adapt to changes.
Imagine this is your company and your personal money.
Start with the elephant. Break it down into jellybeans. Deliver a predictable, constant cadence of jellybeans where each jellybean includes plan, work, demonstrate, and receive feedback. Invite change.
It may surprise you to discover that along the way, the client told you they wanted an elephant when they really wanted a platypus. How would you discover that 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 what you want for sure? How much money are you willing to spend to discover it?
Imagine we're going to spend $5,000 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 two iterations of $2,500, where you can change your mind twice but remain committed to some form of 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?
What do you do if your team, company, or 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.
Do you think your team would benefit from delivering smaller batches? Book Matthew D Edwards to present about establishing flow through frequent feedback loops to eliminate wasted time and money.
Read more articles from Trility’s team.
Read summaries about projects Trility has delivered.
