A farming analogy for predictable Agile teams
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)
Unrefined backlog items pulled into Sprint during planning, for which the team has not been given enough time to break down, estimate and accommodate learning (when needed) is a recipe for disastrous Sprint. Just like the wrong manure! This might result in half-done work, stress for the team, and can affect other non-discretionary work which the team needs to undertake during a Sprint.
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)
Imagine a team handling a legacy product and reeling with Severity 1 issues frequently. No amount of planning and estimation can save the Sprint. Along with the lost focus, the impact on team morale and confidence to do new work cannot be understated. This can be likened to a swamp of pests raiding the farm too often…
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)
I have been in teams where design for implementation in upcoming Sprint is fully completed in the current one! I have also seen teams looking at all the design alternatives in the same Sprint as that of implementation. Both can slow down delivery and eventually cause unpredictability. Too much or too little water ruins the crop!
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)
Many Agile teams are led to believe completing all the backlog items on the Sprint is the purpose of a Sprint. This is wrong at many levels. The objective is to meet the Sprint goal, which is an articulation of creative collaboration between the team and the product owner, to achieve maximum business value every Sprint. Sprint goal ensures the team begins each Sprint with an “end” in mind and allows the team to inspect and adapt work
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)
Scrum teams often forget the product building is incomplete until it’s in a real system and used by real user. Despite many cycles of product backlog collaboration, demos, checks including user acceptance tests, the usage in a live system does throws up feedback. The collaboration with users at this stage (akin to pollination) makes the difference between a working v/s a great product (analogously the best crop!).
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.
Conclusion
Well, this sounds simple! Why can’t every team do and achieve this?
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…
