Rebooting ALM PartIII : Weakness

This is the 3rd part of Rebooting ALM series. You can find the others here:

Part I: Evolution

Part II: Power

Obviously, I wouldn’t call this series “Rebooting ALM” if the tools didn’t have their weaknesses. Let me count the ways.

The first problem of ALM tools starts with the customer. The end-user  of the system (developers, testers, business analysts) is NOT the customer.

Who Are The Customers?

The real customers are the managers, VPs and CTOs that sign the cheques. These products are optimized for them. That’s why you see more dashboards and reports in those demos. The tools aren’t useless, but cater for the money.

And once we bought them, we’re done. Since someone high and mighty has already made the decision that we should by this tool, we should continue using it, as is, and never ever change it. Vendors love lock-in, users less so.

The vendors know their customers for a long time. They learned what made them succeed. Good product managers turn that into more money, with new customers.

Walk The Line

Let’s say your organization is working in the same way many successful others are working. (Let’s call those “best practices”). You expect to benefit from the collective wisdom of hundreds and thousands of guinea pigs.

But ask yourself: What are your chances of coming up with innovation in product and process, if you’re following in their footsteps (which places you far behind them)? What about your business, problems and all other contexts? How do they fit into these templates?

Newsflash: Following prescriptive templates, is not really agile.

Besides, does following “best practices” result in successful products? Nothing is more wasteful then working productively on a product nobody wants, (misquoting Drucker).

In fact, the recipes are not just guard rails. They are too limiting. Many times we assume that because tools “work like that”, we feel we are locked and cannot change it. Even if the tools allow it, we limit our freedom of change, putting constraints on ourselves. Suddenly the organization is locked into a single way of working, without the ability to change, all because of our mental model. Limiting the way we work, means less agility to handle business challenges.

ALM Vs Real Life

ALM tools excel at hiding the complexity and uncertainty of life. For example: Requirements. In the “known” world, without any surprises, requirements can be managed splendidly. The tools ignore the rest of the knowledge we discover on the way. The problem occurs when we continue to work on the known, ignoring the unknowns. Does this result in the best product?

There’s also an elevated sense of done-ness in these tools. 100% stories done is ok, when 80% is obviously not ok. The same is with coverage. In both cases, we see the done-ness as a binary, and less than 100%  never seems good enough. We are compelled to reach the 100% even when it doesn’t make business sense. When we decide to release a feature with a known bug, is it done or not? ALM tools don’t have 50 shades of Done. Only two.

And then these numbers are evaluated by the managers. Which causes a clash of expectations, and sometimes disappointment, blame and suffering.

Another thing that bugs me today (pun intended), is how huge these things turned out to be. They support gigantic code solutions, bottomless bug repositories, more powerful debuggers and everything XXL.

We know that less code is better, so why allow the codebase to expand? We know that every bug in the system costs us money. In reviewing and re-reviewing, in fixing and creating another two bugs as time goes by. Instead of telling us to “fix it now”, tools tell us to store now and waste our time later. The more we work with them, the tools create even more work for us.

And yet we’re continuing to feed the trolls.

Next time, we’ll talk about getting out of this mess.