Recently, I’ve been part of few conversations regarding predictability and commitments. It is the opinion of some that Agile teams should be able to make and keep their Sprint commitments as it pertains to outputs (points, stories, card counts). It has also been suggested that measuring a team’s consistency on delivering on committed deliverables (outputs) is a good metric. After all, the thing our businesses values the most is predictability.
Here is the challenge I have with these assertions. They are based on the premise that the team should know enough about how they will address problems such that they can make a highly confident prediction on what they will complete before they actually start the work i.e. pull it into a Sprint (or do something equivalent). Is this the case for the problems your teams solve? Is your team highly certain on how to solve problems (both functionally and technically) before they actually start solving them?
The Chinese restaurant around the corner from my house is very good at telling me how long it will take for my vegetable fried rice order to be ready because they do that multiple times a day. My barber is very good at telling me how long it will take to cut my hair because he’s done it for me for the last five or so years (and I haven’t changed my style). The folks who change my oil are pretty good at letting me know when to come and pick up my car. They’ve been changing my oil for almost eight years. Are your teams solving the same (or similar) problems from Sprint to Sprint?
I often find teams spending a ton of time (days) upfront trying to determine what needs to be done so that they can make and meet their commitments. If they discover that they will not be able to meet their commitments,they take shortcuts (specifically in code quality) to ensure the commitment is met. When they don’t meet their commitments, they begin to look for someone on the team to blame. If they can’t find someone on their team, they look for someone on some other team. Are these the behaviors you want on your team(s) and in your organization? To be fair, with a heavy dose of upfront planning, a set of stable requirements, stable technology, stable team (and a bunch of other stable factors), you may be able to achieve such predictability in a non-damaging manner. What are you willing to pay to reduce uncertainty to a point where your team always deliver output targets?
I believe some of the mass movement to Kanban is as a result of the commitment pressure uninformed leaders place on their teams. The distortion of Scrum – Dark Scrum – has led teams to look for alternatives. Unfortunately, this is the wrong reason to make process changes but people will do what they need to do to feel safe (and in the process mask real problems).
My tone so far probably leaves you thinking that I believe we need to punt on predictability in its entirety in software development and just let things evolve as they may. That’s not the case. However I do strongly believe that it’s critical that we (especially business leaders) appreciate the uniqueness of software development and the challenges around predictability that it presents.
What does predictability really mean in software development? Is it that a team consistently completes a certain number of points or stories in a given Sprint? Would that make them predictable? Possibly, but that’s not my opinion.
Agile is concerned with managing the unpredictable nature of software development and delivering on business outcomes ergo Agile teams that are “predictable” are teams that consistently deliver solutions that enable desired business outcomes. My next post will look into this further.