Why is “When will you be done?” so hard to answer reliably?

The question “When will you be done with X?” is asked a lot at work. It often creates tension, because it’s hard to give a reliable answer. Why is that, and what can we do about it?

Imagine it’s 10:00 on a weekend morning and you’re full of energy and motivation to clean your kitchen. You look around and decide exactly which parts you’ll clean and to what extent. When will you be done?

It’s probably easy for you to produce an answer. However, what might delay your actual finish time?

  • Running out of a critical cleaning supply
  • Cleaning one more thing while you’re at it
  • Getting called away to help a family member with something
  • Stopping midway to run an important errand
  • Toiling (and resting) more than anticipated, then having to clear out of the kitchen and continue after preparing lunch
  • Mopping the floor with too much water, then waiting a while for it to dry up

Now let’s look at your professional/paid work. It is susceptible to similar challenges: interruptions, scope changes, switching to other important tasks, inefficient sequencing, and missing resources. In addition, some tasks require learning, approvals, and waiting for colleagues to free up. This is what happens when your work exists within a much bigger and more complicated context (and, you’re not a machine).

Say you manage your work using Kanban or Scrum. Did you realize they deal with these matters quite differently? Importantly, they make different assumptions.

Kanban expects these delays to occur. Therefore, a Kanban system includes mechanisms to minimize their impact, such as limiting work in progress and managing flow. It includes mechanisms for noticing delays easily, such as work visualization and specific metrics. And its primary orientation is to services, not teams.

Scrum aims to eliminate these delays by creating a certain structure:

  • All of the team’s immediate body of work is in the sprint backlog.
  • There shouldn’t be dependencies on other roles/specialties because the whole team (including PO) is right there.
  • Sprints are disturbance-free.
  • There’s a strong emphasis on getting to “done,” with swift management of impediments.

Establishing a reliable approach to work takes time and effort and, importantly, fulfilling the right conditions of the method you base it on. If a Scrum team, for example, consistently struggles to finish work by sprint end, the likely reason is that one or more of Scrum’s expectations isn’t met properly. Perhaps the team doesn’t have all the skills and knowledge for completing all needed work, or some members are not always available, or interruptions are excessive, or impediments are not removed. (The reasons these occur belong in a separate discussion.)

Whatever approach you use, people will continue asking “When will you be done?” because they want or need to know. So be aware of your approach’s assumptions about managing or preventing delays. And when you answer the question, also articulate the conditions that must be met for your answer to be reliable.

Yuri Sokolovski

Software engineering, management and technical leadership

2 年

"Cleaning the kitchen" analogy is probably more applicable to a very well-defined work scope with very little possible surprises (depends on the kitchen of course ??). I find that in a "green field" new development it is usually much harder to get the accurate date estimates because it's not only about delays but also about "iterating" and "discovering" the actual solution that works. Additionally, the meaning of Done also often tends to get re-adjusted as we get closer to the product we want.

回复

要查看或添加评论,请登录

Gil Broza的更多文章

  • Why your process needs slack

    Why your process needs slack

    Let's say you and the team keep a sustainable pace, are productive, and always have enough useful tasks to keep you…

    1 条评论
  • Simple techniques for minimizing legacy code

    Simple techniques for minimizing legacy code

    Legacy code..

  • What does designing an Agile way of working look like?

    What does designing an Agile way of working look like?

    This client is a tech company with a pronounced engineering culture. When I started working with them recently, they…

    10 条评论
  • Agility Takes More Than Practices

    Agility Takes More Than Practices

    Your organization has an Agile way of working. Your previous company probably did too, but theirs was different.

    5 条评论
  • How to Maintain Agility During Rapid Growth

    How to Maintain Agility During Rapid Growth

    If you're a senior leader in a fast-growing tech company, this is for you. Agility was a vital strategy for getting…

  • Are Your Agile Planning Meetings Strategic Enough?

    Are Your Agile Planning Meetings Strategic Enough?

    Does your team frequently get together to plan the next sprint or some other cycle of work? In those meetings, do the…

    9 条评论
  • Do you have Waterfall in Agile clothing?

    Do you have Waterfall in Agile clothing?

    Recently, a project director at a client company asked me for help with sprint planning and retrospectives. He said: “I…

    2 条评论
  • How to Achieve Meaningful Agility

    How to Achieve Meaningful Agility

    Agile seems to be everywhere now, but I still see too many implementations that don’t produce meaningful agility…

    4 条评论
  • Are Your Agile Planning Meetings Boring?

    Are Your Agile Planning Meetings Boring?

    Does your team frequently get together to plan the next sprint or some other cycle of work? In those meetings, do the…

    2 条评论
  • Is your Agile process *really* feedback-friendly?

    Is your Agile process *really* feedback-friendly?

    Feedback is a fundamental principle in Agile. Do you truly get enough actionable feedback about your deliverables, and…

    1 条评论

社区洞察

其他会员也浏览了