Estimation Revisited (Part 3)

In Part 1 of Revisiting Estimations, I explored some challenges and underlying concepts relating to estimates and projections. In Part 2, I more deeply explored Uncertainty, Complexity, and Stakeholder Questions. In Part 3, I explore some guidance for leaders and managers…

Guidance for leaders and managers…

When a software project is “late”, estimates/projections increase (projected completion date “slips”), or current estimates/projections show a likely completion date that is “too far in the future”, leaders and managers may attempt interventions that are well-intended but may in fact work against the goal of “getting done sooner”. Below is a discussion of interventions and possible alternatives:

Intervention: Put pressure on the team to increase velocity, perhaps even to a specific “target velocity”

Why it’s ineffective:

  • The application of pressure often comes from an underlying theory Xassumption: “people are lazy and unmotivated and won’t work hard unless we apply pressure”. This outdated, factory worker mindset is inappropriate when we want people to apply their creativity and energy to solve complex problems for us. It is especially inappropriate when we want them to collaborate to do so.
  • Velocity is only a useful measure of what a team is capable of and might be able to achieve in the future when it is an unbiased measure of “what the team has demonstrated being able to get to done with quality and maintainability”. Pressure to simply increase velocity creates incentives – whether conscious or unconscious – to achieve the desired increase, even at the cost of quality, maintainability, done-ness (cost = deferred work that gets discovered later), and devaluation of velocity as a predictive tool. Velocity might very well go up, while the overall project actually slows down to the increase in bugs, deferred tests and integration, and reduction in coordination because everyone is “heads-down” rather than collaborating to get the work done effectively.
  • A team pressured to “increase speed” spends more time “heads down” working and is less likely to spend time improving and/or collaborating on creative solutions.
  • If a team perceives that the target is clearly unreachable but management keeps reiterating the target as the goal, this works against motivation and transparency.

 What to experiment with:

  • Collaborate with the team(s) to explore better ways of reaching the desired goals – e.g. exploring functional increments that provide the most valuable items first. “Given where we want to go and what we currently know, what could we do?”
  • Ask: what could we be doing differently as an organization that would allow the work to go more smoothly and quickly?
  • Collaborate with the PO to ensure that “what’s most valuable” is being explored constantly. Is there anything that we intend to deliver that is more than what is necessary?
  • Collaborate with the team(s) to create the conditions for high performance…
    • Team has the right mix of cross-functional skills to do the work with high quality and maintainability.
    • Team has a skilled coach (e.g. experienced scrum master) to help guide the team into self-organization, impediment detections & removal, and the pursuit of high performance.
    • PO for the team has the skills and training to define and prioritize the work, shield the team from pressure, and connect the team with the vision and purpose of the work.
    • Organizational focus on detecting and removing systemic impediments (e.g. access to tools, environments, and other shared resources; cross-team dependencies; component teams and knowledge silos; multitasking and attempted 100% utilization; mindsets that work against pair programming and swarming…).
  • Become familiar with the use of systems thinkingand lean thinking to address systemic impediments and to avoid counterproductive interventions.
  • Model the behaviors you want from teams: asking “how am I contributing to slowness?”; blameless retrospectives and continuous improvement; exploring mental models and assumptions, and how they contribute to the organization’s structure and behavior.
  • Create a culture of blameless transparency and continuous learning.

Intervention: Add new people or new teams to do the work

When and why it’s ineffective:

  • The slowdown effect of adding people and teams to a project is so common, it is known as Brooks’ Law: “Adding people to a late software project makes it later”.
  • Changing a team’s makeup makes a shift in team dynamics that takes time to readjust. When teams form, there is a development process that occurs: Tuckman expresses this as “Forming, Storming, Norming and Performing”. Any change (whether adding, removing, or replacing members) to the membership of a team forces the team to start over again.
  • Not only do new team members start with a low contribution due to their learning curve, but time is taken from other team members to support them. (If high time pressure also exists, there’s an incentive to let the new person struggle more – also meaning that more new bugs will be introduced, further slowing the overall effort.)
  • Spinning up a whole new team adds further complexity to a multi-team system. The team requires support from other teams. Also, if the new team has limited experience with the domain and/or specific technology and product, it is easy for them to inadvertently create new quality problems – not only bugs, but maintainability issues and duplicate code.
  • Providing access to a SME (subject matter expert) is of limited use: new teams don’t know what they don’t know (and don’t know when to ask for help); also if the team or team members are coming from a protectingmindset (not uncommon), asking for help feels like an unacceptable admission of weakness, which is to be avoided – even at the cost of building the wrong thing or creating quality and maintainability issues.
  • SMEs are sometimes people who become 100% utilized, and thus become bottlenecks to the work to be done. (See queueing theory).
  • Bringing in “low cost” offshore teams can introduce additional complexities:
    • Time zone offsets can make collaboration difficult.
    • In some environments, such teams have high turnover. The high turnover means that it is difficult to build up sufficient experience to be truly effective over time, and the team is frequently resetting to a Forming state.
    • Cultural and organizational forces may work against transparency and collaboration.
    • Cultural and organizational forces may cause the team members to favor “one person – one task” vs. collaboration. This high WIP/ low collaboration approach slows the work and reduces quality.
    • In some cases “low cost” can mean “low skill” – resulting in an impact to quality and maintainability and thus slowing down the overall effort.

What to experiment with:

  • Try to accomplish the mission with the smallest team possible.
  • Work on resolving organizational impediments first.
  • Work to minimize queuing. Eliminate cross-team queuing by using feature teams.
  • If adding new team members, ensure the team has enough bandwidth to adequately bring the new team member up to speed.
  • Encourage pair programmingand swarming to get work done more effectively with higher knowledge transfer and quality.
  • Add people and teams early, rather than once the project is already considered “late”.
  • If adding a new team:
    • Make sure they are going to be on the project long enough – as a stable team – to make the ramp-up cost worthwhile.
    • Consider including an experienced team member from another team as a member of the new team so that the new team is not contending with the limitations of external SMEs.
  • For all teams:
    • Ensure that the team has sufficient knowledge and skill to complete the work with high quality.
    • Emphasize and prioritize practices that maintain high quality and distribute knowledge: e.g. Automated Acceptance-Test-Driven-Development (ATDD), Behavior Driven Development (BDD), Test Driven Development (TDD).
    • Ensure fast feedback loops so that teams have the ability to self-correct quickly (e.g. get customer feedback in the same sprint; perform end-to-end integration in the same sprint).
    • Support cross-team collaboration so that impediments are discovered and resolved and so that the teams effectively create coherent cross-team solutions.
    • Support refactoring and technical debt reduction so that the work is not slowed down by a swamp of technical debt.

Now what?

As I wrap up this 3-part series, I want to leave you with a few key takeaways:

  1. Estimates are estimates – not commitments. Mixing these up has serious consequences.
  2. Learn Cynefin. Understand what part of the work is in the Complex domain and realize it may not be estimable.
  3. Well-intentioned interventions such as pressuring the team to “go faster” or adding teams / members can work against going faster.

With teams I’m working with I’ve started touting the goal “be able to quickly and safely develop and deploy valuable, high quality features to production customers at a sustainable pace”. This puts into focus both the short term and long term consequences of how team effort is spent, and where interventions help or hurt.


That’s a wrap on the Estimation Revisited series.  Have you seen similar issues in your organization?

Originally published December 12th, 2019 on the Innovative Software Engineering blog. Republished with permission.