1. 7
  1.  

  2. 7

    I don’t want to trash the article, but it sounds like they put blinders over the real problems. Ripping out the retrospective, and removing the goalposts is not the solution to poor estimates. Why would a person think they can handle literally 5 times what they can actually handle, the answer is they were not sufficiently exploring the complexity of the tasks at hand.

    1. 6

      It certainly doesn’t fix the poor estimates. But poor estimates are only a problem if the estimates themselves are providing value to the team/company. In my experience, they often aren’t. If you know that Feature X is the highest priority, taking time to estimate that it’s 1 day versus 5 days may be a total waste.

      The first couple of chapters of the Kanban book are instructive in this regard. In that situation so much time was being spent estimating that no one was ever able to actually do any real work.

      1. 0

        Why are your estimates taking so long and why are they so bad? Until you find the answers you are hiding problems.

        1. 4

          IME, it’s pretty common across many ‘agile’ teams to spend a substantial amount of time getting inaccurate estimates.

          I’ve met a few people who could accurately produce estimates in little time, but none of them could explain how they did it.

          1. 1

            Sounds like your scrum teams are too large, how many people do you have in the room? Working without estimates can mean spending a lot of time doing the wrong solution to the problem.

      2. 4

        Perhaps you are right that they have problems yet that they need to deal with. But I would like to invite you to take a look back at the Agile Manifesto, which is supposedly defining the guiding principles behind Scrum, Kanban, XP, etc. Ultimately, all the practices and techniques and tools are meant to be subservient to self-directed teams that are continually examining their progress and changing things to get any perceived roadblocks to their progress out of the way.

        There is little value in producing an estimate of the work to be done in some arbitrary amount of time if no one is asking for that particular fact and it’s not providing immediate value to the team in pacing their work. The relationship between developer and customer is different in various situations, and not all customers need precise work estimates at two-week intervals.

        Furthermore, placing arbitrary time/size constraints on granularity of estimation can wreak havoc on a developer’s intuition for how long things will take. It could be that they’re, as a team, relatively good at estimation via a continual process like Kanban, but terrible when forced to break things down in ways they’re not used to in Scrum. Could they improve their Scrum estimates over time? Probably. Is it worth it to deal with the demoralization of the team in the mean time? That’s their call to make! That’s the point of the agile manifesto, as I understand it.

        I am a firm believer in the value of processes, tools, and procedures. But I also believe just as firmly that there’s no “one size fits all” perfect set of processes, tools, and procedures that will fit every team and project. Ultimately, it’s the responsibility of development teams to be self-aware and self-directed enough to develop a set of these things that make them most effective. Kudos to the author for making an effort to do this!

      3. 2

        The biggest problem I find with Kanban is scope creep - or simply tasks that were never adequately scoped in the first place. The two-week deadlines in Scrum are artificial, but they do force you to break everything into two-week deliverables. You should never be estimating a “large feature on a large app”, you should be estimating the piece that you can deliver in two weeks, and then estimating the next piece two weeks later. You should be able to get within 20% on that easily, IME.