This is the first in a series about Rebooting ALM. I’m going to present this next at Agile Slovenia in a week, don’t miss it.
I’ve started thinking about how Application Life Cycle Management has changed over the years. It’s funny, because what’s the first thing they teach you in agile class (I hope)?
“Individuals and interactions over processes and tools”
Now, I won’t say that this is a complete lie, but too much experience has shown that people would rather have processes and tools. If we have those, we can solve any problem without the pesky humans.
By the way, what we call ALM, today is wrong. The Application is now a completely different thing than what we thought in the 90s. What we build today are Products. Unfortunately, PLM was already taken. We’ve built PLM software before we built ALM software. Back then, Products were about inventory, supply chains and contracts. All these tangible things that you can create Products with. Unlike the A word.
Back to ALM. We’ve already started working on big projects in the 80s, and needed tools for management. While the scope of development tool has grown large, other parts remained the same.
If we look at any product life cycle, regardless if it’s lean start up or waterfall, it looks roughly like this:
Because of its origins and other factors, the ALM tools covered the “Build” circle. Over time, tools were added, to support testing, and bug management, and tracking requirements. But they still centered around the “Build” area.
In time ALM covered more and more functionality, but never went outside the Build part.
Next time, we’ll discuss what makes ALM tools a helpful ally to the builders. And after that we’ll discuss why they can improve by making builders life horrible. Why else would we want to reboot?
Stay tuned.
| Reference: | Rebooting ALM Part I: Evolution from our JCG partner Gil Zilberfeld at the Geek Out of Water blog. |
