Agile: Or how to show how bad you are at your job

Just completed another sprint. Doing our retro we didn't have too many issues. It was an odd two weeks, a few days where all developers worked on "fun" projects unrelated to normal day to day so our velocity was going to be messed up. On the bright side, we are deep in the middle of a green service so there is all new APIs and UX work to be done that we couldn't help but be super productive.

And yet, when it came to our burn down chart it didn't look good. As with most teams, we under estimate the points for new work and we could have broken down our stories into smaller steps in some cases. Some stories didn't get closed out until the end of the sprint and we brought in a few new stories and didn't remove others. But the biggest issue with our chart was it didn't show the 1/3 of our sprint points that were currently in flight. Some were pending pull requests, a few were having issues with edge case unit tests. We rolled over a lot of points that should have been given to this sprint. We did all the work this sprint but due to the way our tools work, we couldn't account for them until next sprint when the stories finally moved to Done.

Now I know what all you Scrum Masters out there are saying, velocity is calculated as a rolling average and the points that roll over will all work their way out. Yes, we can estimate roughly what our team can do in a given two weeks. But that assumption is based on what we'd consider a "good" sprint. We can create epics and give a ball park answer to management on how many weeks or months it will take to get this out the door. That is, assuming that we don't have to deal with catastrophe.

But that's the thing. We don't try and figure out how often catastrophes occur nor how devastating they are. We work hard during retros to figure out ways to reduce the likelihood of the problems we hit this sprint from happening again, but we ignore the fact that in the future we will hit new issues. The fact that most of the people driving strategic planning aren't in the day to day meetings, and many times are a few degrees of separation from them, it can sometimes feel like the only thing we take into account is how well the teams do with regards to when a project can be completed.

If you have very flexible release dates that isn't a problem. If your deployment can roll over a sprint just like your points then you have nothing to worry about. It just feels like there is a very important metric being missed here that no one likes to talk about. How often do we miss the end of a sprint on a task? Its very apparent when you have a ton of points rolling over for an extremely small amount of work still needing to be done. But we will just let those points average themselves out over the next few sprints and forget about the fact that we didn't hit our deadline. Maybe had this been a hard deadline the team would have put in more time, worked a little harder to get something finished on time, but that feels like a solution to a problem that ignores the underlying issue.

We don't track how bad our estimates are. We just hope that they average out due to other bad estimates in the opposite direction. We don't track how often we have to introduce stories due to fires that must be put out today. We just hope that they average out with work we get done early. We don't track how much the velocity is impacted in a given month based on the likelihood of extra meetings or new Proof of Concept projects or any other chaos that we know will happen. For a methodology that likes to push metrics, it seems to me like Agile only shows how bad you are at your job. It doesn't help warning about how bad you will be in the future.

$ published: 2022-11-05 10:06 $

$ tags: programming, rant $

-- CC-BY-4.0 jecxjo 2022-11-05

back