| by Julee Everett |
Agile transformations, in particular, Scrum, often tout “predictability” as a benefit. This concept is a critical component of success, and I find we don’t spend enough time at the beginning on how to achieve predictable delivery. It mostly comes through practice, but some organizations quit before they achieve success and then blame the Agile frameworks rather than changing their behavior or structure. Below are some common questions from teams starting their journey. (Part I, Practical Fibonacci)
Frequently Asked Questions
Coaching the gray areas
Assuming good record keeping of estimates and actual time spent, how many Sprints does it take before the Team can reliably size a Sprint?
Each Team is different and is very dependent on the “good Agile citizenship” influencing them (i.e., no outside pressure, no interruptions, alignment on outcomes) and a healthy ecosystem (i.e., stable, sustainable, cross-functional teams, little or no dependencies). In the healthiest scenario, from my experience, it takes a minimum of three ‘regular’ Sprints to get into the groove. I wouldn’t count the first one or two, and I wouldn’t count holiday weeks. But it does happen. When set up for success and left alone to do what they say they will do, teams get good at figuring out what they can complete in a Sprint. We are shite at estimating (See Part I), so we don’t assume we can get “good” estimates. And spending more time estimating doesn’t make us better at it. A better approach could be the Scrum Master tracks team trends and uses the Retrospective as the event to help the Team get better at relative sizing and planning their Sprint.
Some trends from real-life examples and the corresponding actions the teams adopted:
- The codebase has a lot of technical debt, therefore:
- the Developers can do more refactoring and work on burning down technical debt
- the Scrum Master can ensure the sizing includes all the work that is needed to get to Done
- the Product Owner can make sure the efforts are limited to the current Product Goal in development and not a wash of the entire system
- A client is notoriously difficult to please, therefore:
- the Developers can split work items into smaller sizes and more feedback loops
- the Scrum Master can do some coaching and stakeholder training to help everyone understand how to be a good Agile citizen when working with Scrum Teams
- the Product Owner can work with the client to get daily collaboration, clear acceptance, and define the smallest thing that could deliver value
- We are not following our Definition of Done practices, like Code Reviews, therefore:
- the Developers can add this as a task to the Sprint Backlog to keep everyone accountable for a few Sprints
- the Scrum Master can help the Team ensure this is visible and transparent throughout the Sprint and discuss more in the Sprint Retrospective
- the Product Owner can adjust their Release Planning to include the impacts to sizing to improve quality while balancing the trade-off with time-to-market
- This request is a <feature/codebase/product> that few on the Scrum Team know well, therefore:
- the Developers can add pairing and mentoring to the Sprint Backlog item to increase team effectiveness over individual effectiveness
- the Scrum Master can help the Team find ways to add knowledge sharing
- the Product Owner can ensure the request is the most valuable item the Team can work on and use data and feedback to consider the possibility of sunsetting unused features
Should we assign the work to an engineer before settling on the final estimate? If the Team sizes things together, we usually size as if anyone can do it. This often feels inefficient–to size for the least mature engineer. However, in Agile, we are not striving for individual efficiency but team effectiveness. So as we develop cross-functional teams, we build in mentoring and pairing to help mature the whole Team. We also encourage people to volunteer for work during Sprint Planning rather than assign the work to promote buy-in and personal accountability.
When they are new to sizing, the Team can adjust the Story Points on items relative to each other after the deep dive that Sprint Planning provides, right up until Sprint Planning ends. Then we don’t adjust Story Points again, so we can see where we were way off. We don’t need to take an individual deep dive into each; the Scrum Master helps the Team look for trends where a deep dive could help the Team get better.
Coaching Tips
- Be okay with uncomfortable silence. Online, this can often take over 30 seconds. Encourage your leads and managers from suggesting anything until the silence is unbearable. (Six Tips to Get Them Talking)
- As a coaching approach, use Community of Practice discussions, vlogs, blogs, other training/ability tips to encourage self-organization
- Watch for “passengers” – those who wait to see if the “hero’s” take on all the work. The Scrum Master can work with people individually and during the Sprint Retrospective to improve team balance.
- Encourage a balance between the developers, so everyone gains experience with all areas of the product development, but with a caveat of “is this worth it?” i.e., if the Team only touches a <code/feature/product> occasionally, anyone will need to be brought up to speed. Build in the time for orienting others, or consider the value/shelf life
- Small batch sizes are your friend. The smaller the item, the more predictable anyone will be in sizing. That is easy to say but hard to do. It is a challenging practice resulting from a high-performing team, strong product leadership, and agile engineering. There are lots of engineering practices and maturity needed to get to an ideal state. I’ll add a primer below that can help kick start your approach to splitting items.
Change Management
One last thought – everyone knows that positive reinforcement works better than negative. However, people sometimes forget how long we must practice positive reinforcement to encourage good behavior in practice. Any transformation, at the core, is a change management initiative. It requires proactive, affirmative, and unambiguous communication from leadership (top-down), champions who can further the efforts (bottom-up), lots of training and upskilling, and celebrate any wins, no matter how small! Publish them, record testimonials, and encourage opposing leaders to be heard. Buy-in can improve through a dedication to transparency, communication, and results. It takes a lot of time–a year or more–depending on the complexity and maturity of your organization.
As part of the change management practice, it’s helpful to clarify the behaviors you want to reinforce. For that, I will turn to the great Johanna Rothman, who writes: “The Team’s learning and working are invisible to other people. The only thing external people can see is the duration of the Team’s feedback loops. However, we can see evidence of several kinds of behaviors that encourage agility.”
Relevant Sources
Going further
Estimating: The best source to aid in getting started in estimating, in my opinion, is Mike Cohn’s Estimating book. I encourage a book discussion on this as a Community of Practice discussion while a team matures their agile estimating. He also has an excellent blog for beginners at Mountain Goat Software.
Story Splitting: There are many sources on Story Splitting. Remember, this competency may require several Agile Engineering practices to achieve overall maturity. Here is my favorite source to kickstart the conversation, by Richard Lawrence:
Defining Agile Behaviors: The great Johanna Rothman has this article, among many other valuable insights on this topic of agile teams:
~Julee Everett
Hone your craft, speak your truth, show your thanks
Contact ClearlyAgile to upskill your teams with targeted workshops or certified training
Visit my YouTube Channel to access a growing library of professional development webinars and subscribe below for more content!
