State of the ALM art
Xeau's Barry Gilbert speaks with David Norfolk
Interview I've been an enthusiast for ALM (Application Lifecycle Management) since the days of AD Cycle in the 1980s – but I can't help noticing that universal adoption still seems to be some way off. Perhaps it's the "hero culture" we have in IT: the ALM promises of "getting it right first time, good alignment with the business and no surprises" don't offer much scope for a hero to save the day, riding in on a white charger when the brown stuff hits the fan.
Perhaps no one really wants what ALM promises...
But I may be out of touch these days, so I welcomed a chance to interview Barry Gilbert, a current ALM practitioner with the consultant Xeau.
Barry Gilbert from Xeau: I first started work as a systems analyst for an operations and management consultancy, moving up the ranks to become one of those who told the 50 year old guy "look upon redundancy as a new start". At which point, I setup a development shop producing turnkey applications back in the late 80s and early 90s.
More recently, stints at Atria-Rational and Starbase-Borland gave me insights into the SCM [Software Configuration Management], ALM and requirements management areas of the whole software lifecycle.
Today, I'm co-founder of Xeau, setup in 2002, specialising in requirements management and all that it touches within the ALM space. We help organisations of all sizes and types to select effective Requirements Management solutions. We also help other organisations re-evaluate their use of requirements management tools.
Reg Dev: I'm interested in your view of the state of the art in RM. For instance, I suspect both of us think that RM is a 'no brainer' and could argue about market shares in this space – but isn't the real "market leader" the large group of developers who don't do formal RM at all?
Gilbert: Despite what the tool vendors would like to tell us, MS-Office is still the leading requirements management tool. The fact is, everyone uses a requirements management solution of sorts – for some organisations, documents, spreadsheets, and email work well.
Typically, these organisations will spend more time doing requirements management and, therefore, incur invisible overhead costs in it, but if it works for them, then who can criticise? However, with the increasing pace of software development the tolerance for delivering the wrong functionality, and delivering it late, is ever-diminishing.
Reg Dev: Given that many effective developers don't use formal RM tools, why might this make sense to them?
Gilbert: When I was directly involved in development, many years ago, end users were grateful for what they were given. Today, end users are more astute, more aware of what software can do, and simply demand more. Tie this together with easier and faster communications channels (email, etc) and users will fire off new design ideas, change requests and bug fix requests incessantly, to business analysts, designers, and developers. Little wonder end users shout and scream at deployment teams when a crucial change has been omitted from a release, simply because an email went astray or was simply forgotten.
Perhaps the 10cc lyric should have been "disorganised and unstructured communication is the problem to the answer". That's what requirements management tools provide – structure and method to the capture and management of requirements; and a subsequent flow of crucial information for the ALM cycle.
Gilbert: The great thing about a tool, if deployed and used correctly, is it promotes discipline.
Wrong. That is definitely putting the cart before the horse, facing each other. The horse is the discipline, the tool is the cart. Without a horse no cart is going anywhere.
A tool used correctly implies that there are rules in the use of that tool which are followed by people that are trained to use it within those rules. If a trained person does not follow those rules then that person exhibits ill-discipline. If the owning authority of those rules does not exert discipline then there is no authority, no discipline.
A tool should make it it easier for a person to follow those rules; this is not saying the tool is making it easier for the person to be disciplined.