Agile Abuse
Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law
CTOs want less risk of something going off the rails and more predictability as to when something will be delivered.
If they ask a team when they can deliver project A, the team might say: 2 weeks. If they ask when they can deliver project B, the team will think that they probably need to pad the time to account for project A. If the CTO asks when they can deliver project C, they will pad the time with A & B. Chance of delivering project C when they say it will be delivered? That’s right, zero.
What Agile Is
There has to be a better way? Of course, there is Agile. Agile is to prevent projects from going off the rails and to give more predictability as to when something will be delivered.
Why are things time-boxed in Scrum? So that we can keep things from going off the rails by only committing to things within the sprint.
Why do we estimate story points and commit to delivering points in a sprint? To give predictability to when something will be delivered because we don’t commit to more than the team can deliver.
At some point the team will mature past the simplistics of a one-size-fits-all process (i.e. Scrum) and become truly agile based on the things they have learned about the work environment and the team.
It is a lot easier to plan the release of that next big project or feature if you know when it will be delivered. Most CTOs don’t want everything yesterday, they want to make a commitment and then be true to their word about what can be delivered when.
What Agile Is Not
If Agile is a way to reduce risk and provide predictability, then what is it not?
It is not a tool to measure team productivity. A story point doesn’t really mean anything outside of a local context. A super junior team and a super senior team may both deliver 20 story points in a week but you can be sure they don’t deliver the same business value.
It is not a way to understand how much work is being done in an organization for planning purposes. I’ve seen execs stand in front of a whiteboard for hours haggling over 20 points across an entire engineering organization based on what was done last quarter. If we worked in static systems, maybe this would make some sense, but people and contexts change constantly.
It is not a way for executives to keep track of how the organization is doing. As we said, at some point the team will mature and become truly agile. I’ve seen portcos where teams are allowed to mature only to the point where they can still provide metrics to the executive dashboards! Literally holding the teams back from doing their best work so the ELT can feel they are in command and control.
What then?
There are entire companies that sell tooling to help leaders visualize the work flowing through the engineering organization. But if Agile is about keeping things predictable, let’s start with that.
In your organization, what percentage of things are delivered when it is said they will be delivered?
Do you have a lot of escalations? Do you try to run the teams at 100% without any slack in the system? How does that affect these commitments?
Agile is not a weapon to be used to control, measure, or micromanage teams. Agile is a way to build high performing teams that can utilize the feedback loops built into our systems and maintain maximum advantage based on the information they receive. Understanding what teams are being held back, and why, and fixing the system to allow them to thrive is up to you.