Original URL: https://www.theregister.com/2007/08/11/barry_gilbert_xeau/
State of the ALM art
Xeau's Barry Gilbert speaks with David Norfolk
Posted in Software, 11th August 2007 08:02 GMT
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.
David Norfolk for Reg Dev: You are an experienced ALM expert and a consultant with Xeau , which also resells the Contour requirements management tool. What is your background in this space?
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.
Reg Dev: And what are the possible consequences of this?
Gilbert: Risk mitigation should be the keystone to effective requirements management and that's what requirements management tools help deliver. Having all the information at hand ensures that the right decisions can be made more effectively and more quickly. Of course, making the right decision is still down to the users – so when a tool delivers up all the information needed for a decision, some users may feel daunted – perhaps with nowhere to go if their decision is questioned later.
Reg Dev: I'd suggest that RM could even be seriously career limiting in some companies: it can highlight areas where the business doesn't really understand its own business process and can expose innocent developers to the shark-infested waters of company politics. In your experience, us this a real issue?
Gilbert: The sad fact is we live in a blame culture and especially in larger organisations we do see evidence of requirements management failing; not because of the tools, but because of users not wanting to use them or not using them effectively. We have to ask the question why? In the latter case, typically, training is the issue; in the former, politics. Too often users will simply not want to put their name against a feature request. Perhaps a throwback to the old notion of Business vs IT; perhaps an element of mistrust or misunderstanding of what each group does still exists. How often is the development team blamed for not understanding what the users wanted? Quite often, we've seen development teams coding away without a fully agreed specification.
Reg Dev: So, how does one address these issues?
Gilbert: For Xeau, we first have to understand where the problems lurk. Whether the client organisation is on the first rung on the ladder of ALM and requirements management or whether it's a mature organisation. We need to understand the structure, the culture of the organisation and also its goals and aspirations. These need to be placed in context with the resources available within the organisation. Once we have this understanding, we can look at a project and attempt to pin point the weak spots and where it went wrong – since sadly we are mostly called in when the project has or is about to fail. In essence, we have to get everyone involved and not just paying lip service.
Reg Dev: And do people address them? How often does RM software end up as 'shelfware'?
Gilbert: Sadly, too much software ends up on the shelf. Some of the reasons being cited include: too complicated, too prescriptive, too unstructured, and too inaccessible. All legitimate reasons in many cases, but in a minority of cases, they mask the political issues within organisations. Not surprisingly, when organisations look to deploy ALM and Requirements Management tools, many realise that their processes and working methods may need overhauling.
Reg Dev: Well, then, how would you claw something back from this situation?
Gilbert: Firstly, we need to understand why it failed - people, process and technology – are the three bedrocks. For issues within the people and process areas, consultancy works. If technology (the toolset) is the problem, then we look to either redeploy the current tool with revised training or, in extreme cases, suggest a replacement. Wherever possible we look to use the initially purchased toolset, but if it was a bad purchase then it has to go.
Reg Dev: It seems to me that many successful ALM implementations generally, and RM adoptions in particular, follow on from a crisis and address specific 'pain points'. But does RM, say, by itself deliver real benefit? Don't you need config management (for requirements as well as code etc), requirements-based testing and generation of code from requirements too?
Gilbert: You never need to dig too far to find a "pain point"; it seems a fact that many requirements management/ALM tool vendors market their wares on fear, uncertainty and doubt, portraying doom and gloom for those who don't spend many thousands on their offerings.
The reality for many is they neither can afford the whole gamut of ALM tools nor simply cannot deploy all facets of the ALM toolset in one go. Hence, requirements management tools languish on shelves.
Don't get me wrong, I'm a strong advocate for ALM, but buyers need to be aware of the full cost of ownership, which may include redefining processes and methods as well the simple administrative costs of tools for SCM and requirements management.
In terms of the directly attributable benefits of requirements management, the developer, the tester, the project lead (to mention just a few of the stakeholders) need to ask these questions every day – "Why am I writing/testing this code?", "Who is going to use this code?", "Do they still need this?", "What is this code going to be used for?", "When is this expected to go live?" – if any of this information changes then all involved in the project need to know it and know it in a timely manner.
Reg Dev: And is any of this necessary, or even feasible, for small companies?
Gilbert: The core questions of who, what, when, why, and how apply regardless of size of company or project team. Do smaller companies need requirements management or an ALM solution? Then, if the answer is yes, do they need a toolset to assist? Well, that depends. Small doesn't mean simple – many a small company run into the complexities of remote development and perhaps outsourced testing. In which case, a cohesive communicative repository of information is essential and that's what requirements management gives them.
Reg Dev: I suppose we should get onto RM tools before we finish. For a start, are tools always necessary? Is there work that users can do on developing/organising the way they run RM planning meetings (perhaps using white boards, a camera and a Wiki) that can make them more effective - without buying (and learning) an RM tool?
Gilbert: The great thing about a tool, if deployed and used correctly, is it promotes discipline. Requirements management can, to a certain degree, be achieved without using a tool; but referring back to the leading requirements management tool – Office – would you truly want to invest the time and effort needed to get it to collect and audit your essential company's needs. Let alone expect it to notify all stakeholders of any changes they may have a stake in. Not to mention, expect to it to produce impact analysis and traceability matrices and be available to all on the web.
Reg Dev: OK, fair enough - is there a single 'best of breed' RM tool?
Gilbert: Not as such, the number of requirements management tools available has broadened significantly in recent years with some of the tools specialising in particular areas of requirements management, for example requirements capture. Our job at Xeau is to marry out knowledge of the marketplace with the needs of our clients to assist them select the right tool for their requirements management needs. As always, solving the requirements management need isn't just about buying a tool; after all a fool with a tool is a "less well off" fool.
Reg Dev: As well as Contour, Xeau has experience with users of Caliber (now with Borland), Steeltrace (now Compuware OptimalTrace, Telelogic Doors and IBM Rational Requisite Pro. How do you distinguish the 'purpose each of these tools is fit for'?
Gilbert: The tools mentioned are exceptionally good and invariably end up on the short list of many potential buyers. To differentiate them here would take too long. But users should look at the maturity of the tools, whether the tool suffers from [the use of] aging technology, what user interfaces are needed, who will actually use the tool and in what context, what integrations are required with the tool (with test tools, for example) and of course, which tool fits your budget.
Reg Dev: What do you think of Telelogic FastTrack? And what do you think will be the effect of the IBM takeover of Telelogic on this, and on Doors?
Gilbert: Telelogic clearly realised a gap in the requirements management market had arisen. For something web based, easy to deploy and use; but more than just a web based repository for line items. The customer base for Doors means it will carry on being used for many years to come. As for FastTrack, I hope IBM continues developing the product because we feel this addresses an ever increasing requirement in the requirements management tool sector, much the same as Contour does. We'd relish the competition.
Reg Dev: Finally, how do you see RM and ALM developing over the next, say, 10 years?
Gilbert: Ten years ago I remember organisations questioning the merits of using configuration management tools, today you struggle to find development teams who don't use them. Much the same will happen with the ALM/Requirements Management toolsets. ®
Jama Software, which writes the Contour RM tool resold by Xeau, is trying to crystallise a requirements management community around it here. Early days yet, but it could grow into a useful resource.