Irrelevant Changes

Why would anyone waste time making irrelevant changes?

Photo by Alex Bunardzic

Earlier today I was discussing the issues related to deadlines in software development. My rationale goes like this: the reason management tends to come up with deadlines lies in the fact that they don’t seem to have sufficient confidence that the teams will be able to deliver. So, they fabricate an artificial urgency (i.e., a deadline), in the hopes of nudging the teams to pick up the slack and deliver.

My observations are that if the team has matured to the level of Continuous Delivery (CD), where changes to the system get delivered more than once per day, the concept of deadlines evaporates. How can someone put an artificial deadline on a team that delivers few times a day? Would it then make sense for the management to urge the teams that they must deliver the change “before the brunch”?

And wouldn’t you know it, I immediately received a pushback. Here is what one person commented on my post:

What caught my eye is the introduction of the concept he calls “irrelevant changes”. Now, what are irrelevant changes?

To me, irrelevant changes are nothing but waste. Why would anyone invest any time and money into making changes that are not relevant? That would make zero sense, in any world (well, maybe not in the bizarro world).

But obviously, to that person, irrelevant changes seem like something real, something that maybe he has experienced more than once or twice. Which brings up the question: again, who in their right mind would get involved in making and managing irrelevant changes? What can possibly be gained by doing that?

Is there an answer to this conundrum? Can someone please shed more light on this?