Is ALM a useful term?

I was asked this question by Robert Myers for a “paper” and I think that it is an important one. I started to answer in that little textbox that LinkedIn give you and I got a little carried away. I guess I am an writing mode Smile

>>Do you think ALM is a useful term?

Yes, I do think that it is. The old way of looking at an SDLC was just a little too narrow and allowed us as software professionals to ignore what happed after we chuck our software over the wall to our deployment and support teams. ALM brings these ideas and the dependencies together to highlight, and work together, to solve some of the resultant problems. It is unlikely that any team/organisation that look only at an SDLC would ever be able to get to a state of continuous delivery. This is due to them washing their hands of any of these problems well before their software ever gets to production. Delivering software to the next stage gate is not enough any more, we need to be able to deliver to production and adapt our innovatory of features yet to be implemented to reflect stakeholder feedback.

>>There is such a big difference between the way a huge organization would do ALM  and the tools they would use and a small software company doing Agile ALM to try and lump them together doesn’t seem helpful to me.

Apart from scale there should not be a difference in the way that companies deliver software. In order to deliver high quality and production ready software to our customers we need to do and take care of the same things wither we are small (Arnold Clark) or large (Boeing). Even if we are a couple of developers building software for internal use at our company we still need to have quality in our software and do our best to prevent bugs reaching production. If we build poor software that is riddled with technical debt are we not doing our customers (wither internal or external) a disservice at best and perpetrating fraud at worst.

If I hire a Professional Software Developer I expect to get one. That means Source Control, Work Item Tracking automated build and likely automated deployment. I expect well tested software that can be easily maintained and is adaptable to my business needs. I also expect Agile practices as it has been proven time and again that waterfall (serial development) results in poor quality inflexible software and that the only way to build high quality software in the modern world is to use agility.

Caveat: I am not saying that it is impossible to build high quality software with waterfall, just that in practice it is unlikely.

Large companies that do not practice agile more often than not suffer from atrophy of software as well as an inability to adapt to the changing world. Most large companies (Microsoft | Boeing | Ford) have already gained an understanding of this and are on the long road to agile.

In sort… everyone should be building software using agile methods.

>>I have collected some data that suggests interest in ALM in northern Europe is comparable to that in the USA but that interest in Agile ALM is much lower in Northern Europe compared to USA. Does that sound right? Do you have any idea why that might be.

That does sound right and is one of the reasons that I am working in the US and not in Europe. Don’t get me wrong, Agile is catching on there as well, but the companies tend to have been around for longer with entrenched management that does not often see new blood. With the “old boys club” mentality it will be a generation before we see swaths of change there, but it is starting.

We are on the crest of the waves of change in Europe and the next 10 years will be interesting in-deed as agile sweeps across it. It will be interesting to see which companies adopt first as they will run rings around their competitors by delivering more value to their customers. I think we will be surprised who end up on top.

>>Forrester talk about ALM 1.0, ALM 2.0, ALM 2.0+ and single and multi vendor solutions. How much significance do you think the users place in these kinds of distinctions?

If you are Infosys, with is number of project under way then this is something to consider, but most don’t even realise these debates exist. Forester reports are not light reading and empty your pockets quickly. The shift is really about maturity of the tools (preceded by maturity of the space) finally showing users that they need to be leading the way rather than the vendors. The reality of ALM 2.0+ is that it will make it easier for all users to get benefit. More will be automatic and initiative and is driven less by what the tools can do but by what you can achieve. Amusingly the tools have driven this understanding and have now tipped the balance over to the customer driving what is required. If you read Agile Software Engineering with Visual Studio: From Concept to Continuous Feedback  you can see that happening with the Visual Studio ALM toolset already and the Visual Studio 11 beta release will be a marked push in that direction. It helps when the vendor becomes also the consumer.

So while users don’t put any onus on these distinctions, the ALM community does.