A farming analogy for predictable Agile teams

Picture under a Creative commons license

Often, predictability is one of the factors which determines the success of a team which has adopted Agile way of working. Although, Agility and predictability don’t go hand in hand, the sense of predictability is to do more with delivering predictable value to build trust with users rather than achieving vanity metrics of commitment percentage, less variance in velocity etc. This is an attempt to show what this actually means via a flower farming analogy. Let your imagination a little loose as you may not see a 1:1 mapping! 😊

Once, there was a successful farmer who made it big in his flower harvesting and selling business. In an annual inter-village competition to showcase the highest yield, this farmer consistently won. His harvest also had the best variety of flowers which catered to different purposes of oil extraction, loose flowers, floristry etc. People outside his village were curious to know how he managed to do this consistently by repeating the feat every season. He was once invited to share his success story in a inter-village fest. People expected that he was about unfold a bunch of secrets to his success.

But the man surprised everyone when he shared the simple process which many felt can be emulated easily.

First, he clarified that the focus was not on best yield but the process to get the best yield. He made sure the crop got the right manure, maintained the right watering and pest control schedule based on the growth stage, rain etc. He also planned a optimal harvest schedule to ensure the yield catered to multiple purposes. Then, he shared the “secret” sauce! Seeds from his previous yield were also made available to the people who were growing flowers around his field! This ensured the pollination happened between the best varieties, yielding the best flowers and harvest

This analogously maps to the activities an Agile team should also focus on to get better and become predictable and successful. The other key take away here is the process to get to predictability is also very important rather than an utopian goal of predictable delivery

Refine enough to get the backlog right (Right manure)

A refined backlog is a basic need without which the team cannot make a successful plan to achieve the Sprint goal. The emergent nature of work does bring in a few surprises every now and then, which the team can navigate but a surprise at every other step will throw the team off-track affecting predictability

Control and reduce tech debt (Right “Pest” control)

Teams who enjoy a stable product cannot relax too much and let go of the advantage. Tackling tech debt effectively to ensure the team can reasonably estimate what they can finish in a set of Sprints is important to get to better predictability

Best way is to predict the amount of time needed to tackle bugs based on most previous experience and factor that in every Sprint. The key is to correct the deviation to a lesser number which does not have a significant impact on Sprint goal

Just enough design and documentation (Right watering)

Just in time (JIT) and just enough design serves well for the emergent nature of work the team tackles Sprint on Sprint. Teams can focus on consensus of high-level design rather than tackling nitty-gritties too early in the cycle and have the minimum implementation to elicit feedback. This prevents waste and results in highly maintainable code

Make sure each Sprint has a goal to be met (Right harvest plan)

Image from 9gag.com

Similar to how its important to have harvest goals, for achieving all the objectives of flower farming, having incremental Sprint goals are also important for realizing the product potential. It also provides flexibility regarding the functionality implemented, similar to how the harvest time needs to be adjusted based on weather situation. This eventually leads the team on a path of achieving predictable value Sprint on Sprint.

Provide stakeholders access to every release (Distribute seeds of the previous yield)

Incrementally releasing what the team built to users which can be put to use without disrupting production is key for product success. Canary releases and Beta releases enabled for few users are couple of ways to achieve this.

The value realized at the hands of the user is often the missing piece in making the team predictable and trustworthy for clients and stakeholders. Measuring predictability with stories closed each Sprint is a very narrow prism which can easily cause dysfunctions and results in sub-optimal value.


Doing the above consistently requires a stable team, which is 100% available, and that cannot be take for granted. Also, not every team can successfully tackle tech debt in a disciplined manner every Sprint, owing to non-trivial bugs, conflicting priorities. Sprint goals are also a hypothesis about potential value and cannot be validated as “the value” expected at the hands of the user. The list can go on as to why these simple steps are hard to master.

However, the above should not discourage teams from adopting this approach. The benefits gained in terms of backlog readiness with refinement, a more stable product with tech debt reduction, Agility of the team with JIT design, building product with a purpose and user feedback with frequent releases are too valuable to let go of for any Agile team.

I will take inspiration from Mike Cohn and state that, with constant practice, high transparency and continuously learning from failures teams even a simple process, like the one above, can help the team be predictable and succeed in Agile…

Scrum Master, Agile enthusiast and Enabler