Agile requirements management saves you from trouble, doesn’t it?
Around two thirds of projects apparently fail because of poor requirements engineering. In this article Thomas Spielhofer ponders the question of whether agile projects are any different by looking at a true case.
Requirements engineering appears to be the nemesis of IT projects: “Poorly defined applications have led to persistent miscommunication between business and IT. This contributes to a 66% project failure rate for these applications, costing U.S. businesses at least $30 billion every year (Forrester Research). 60% – 80% of project failures can be attributed directly to poor requirements gathering, analysis, and management (Meta Group).”1
One of the pillar stones of agile development is that it helps circumvent this risk in software development projects altogether: instead of specifying a huge software monster in depth you just build it piece by piece. Instead of discussing what each side of the negotiation table believes this monster to be, you agree on its essence and start to actually build it step by step. The propinquity of customer and team engenders trust, which opens leeway for both sides to learn and adapt. Suddenly both sides find out that they no longer need a humongous requirements management arsenal: no elaborated artefacts and processes to shepherd the customer’s requirement along the long and unforeseeable process chain until (a year or so later) something emerges like a jack-in-the-box that is supposed to meet the customer’s requests. The customers are delighted, productivity boosts and billion-dollar projects going down the drain become a myth with which to frighten your grandchildren in front of the cosy fireplace of your Colorado skiing hut (built with the millions you made with successful software projects).
Sounds like a fairytale made up by a Scrum evangelist? It might well be. And as with any fairytale it may carry a seed of truth, but there are also many chances to go astray. The following story is not fair at all, yet it actually happened in a multi-national company that had been running Scrum for more than a year at that time. They had their staff trained by a certified Scrum trainer, had been accompanied by a Scrum coach in the transition and then … then they tried to build an iPhone app:
In a board meeting the CEO announced that the current iPhone application of the company group was “rotten”. The COO pushed that message down the line requesting an immediate re-launch of the iPhone app within a few months. Some details regarding what were considered ‘necessary features’ by the board were passed on through the line. The message soon reached the IT team, where other projects were dropped in favour of the iPhone app re-launch. The allegedly best external company around was hired to design the app; the internal team responsible for the backend was tasked to develop the backend interfaces with top priority. This team worked according to Scrum. Their product owner got his requirements from a representative of ITO (a different organizational entity), who got his requirements from the business units (yet another organizational entity).
The project initially took off well. The initial sprints met their targets. The timeline became more specific and a special marketing event with large media attention was planned, at which selected board members would personally present the new app. This deadline seemed feasible both for the product owner and the vendor. Time passed on. At some point the product owner received more and more input that some new features “definitely had to be implemented to meet the desires of the board”. As the marketing event drew closer, however, it became less and less possible to implement all these features. The management considered shortening the QA activities, even entirely dropping the security review. The situation escalated when the external vendor declared that he would no longer be held liable for the product under these conditions, as the agreed QA prerequisites were no longer met. The vendor believed its reputation was in jeopardy and refused to add any more features. As the ITO and business units’ representatives learned that their previously agreed features would not be delivered for the marketing event, they demanded that “heads should roll”.
What I ask myself: What went wrong here? What could have been done otherwise?
Ideas are warmly welcome 
1: Kathleen Hass, “The Blending of traditional and Agile Project Management”, www.pmworldtoday.net, 2007
Sounds to me as if the idea of having a business value (which represents the core to rely on) got lost somewhere as it was always evolving but never sufficiently defined. It seems that the “nice-to-have” features have been given way too much importance and significance.
I agree, one point is the loss of business value. And I would think the way the communication chain is set up in this organization contributes to that loss. Yet I wonder if that’s the only impediment o requirements management here…
There is no one size fits all solution. But I sounds like two obvious misconceptions:
First the start phase sounds like board rushed into a decision, while communication sunds not at it’s best, simply following the waterfall without too much think time about the whole case up-front. Something good old pma’s would call environment analysis, pmi would talk about a scope statement.
Second they turned on the Scrum machine. But requirements management got out of control. Was there a prioritized / ordered backlog right from the beginning? Was there clarity about the ground rules of Scrum? Did they every consider status quo during reviews and retrospectives? Did they think the Scrum machine would make any capacity and team considerarions obsolete?
Two dysfunctionas of the organization and maybe a third one when they dropped external support for coaching during their transition too early. Had they verified what had been reached already? Did they have a commited management for Agile? Did they have enough experience with some Scrum pilots? Did they inspect & adapt?
Well, now the have a final chance. Don’t let any head role, but step back, get your hands dirty and learn. Otherwise simply fail by destroying final bits of trust of your organization.
Well, I am not a SCRUM expert but am familiar with other agile approaches like UP. Having spent the last 14+ years in IT-related positions with various international organisations, this sounds all too familiar to me: Delegations and/or Member States setting deadlines or requesting features that meet a political/external agenda but do not necessarily serve a business purpose.
I guess my point is that any process or methodology is only as strong or as good as the people and organisational structure behind it. And I agree, there is no ‘one size fits all’ solution. But equally there is also no ‘works once works always solution’, not even with SCRUM, it seems. Introducing an agile methodology, getting commitment at all levels, training your staff, specifying responsibilities, duties, etc. will not eliminate the need to deal with power struggles, hidden agendas and people’s egos, which to me seems to be one of the key aspects here.
I wonder if improved stakeholder management (including a proper risk/impact analysis) could prevent such things from happening or at least help mitigate such problems? Are there any measures, figures, PKIs that one could use to prevent the powers that be to push requirements/features from the top? Based on my experience, highlighting the consequences by attaching a price tag to ‘nice-to-have’ features can help convince senior management.
Like Thomas, I also think that improved communication management could be another aspect to consider in this context. For instance, was senior management made aware of the implications of their requests?
Finally, as pointed out before, the organisation’s exposure to SCRUM may have been too limited. And I would question senior management’s commitment to the methodology. Do they really understand what SCRUM is about and what their roles are? And how do you translate the basic principles of SCRUM into senior management lingo? I guess this is a problem that is common to any kind of new methodology, programme or standard that you want to introduce…
Of course that’s just my two cents worth…
Philipp,
you hit two nails on the head which I find particularly disturbing in this case study:
1.) how well has Scrum been adopted by the organization and
2.) stakeholder management
as for 1: Personally, I don’t know any large company (let’s say with more than 10.000 employees) that adopted agile values and methods throughout the organization. And since Scrum appears to me as a revolutionary change, it seems conclusive that this leads to a friction between the “new” and “old” way to work. I have heard Scrum coaches say that Scrum is like a virus that is either fully infectious or rejected by the body. Staying with that metaphor, I have the feeling larger organizations are more like a group of people where the virus is more or less contagious for each individual (=organizational entity). The organizations would have to learn to live with partial infection -and cultural and organizational diversity enriched (or complicated?) by Scrum.
as for 2: It appears to be so plain and yet is so often poorly taken into consideration: a project is successful if the stakeholders are satisfied, not if some internal (IT-)KPI is met. Or does anybody think otherwise?
I like this case study and it kept me thinking for some time, here some of my thoughts:
1. I know only a bit about agile methods, especially SCRUM, but it sounds like they are incapable to handle changes properly. In the “classic” project management world the project manager would write a change request after the boards request including
Objectives of changes
Reasons for change request
Change details
Impact on time, cost and other sub projects as marketing launch if the change is accepted
Impact if change request is denied
All project stakeholders must review and add to the document. The project steering comittee must accept or decline the change. If the project steering comitte feels incapable to decide it can escalate to the board, which then must make a decision accepting the consequences of acceptance or decline.
This rather bureaucratic process works very well in my experience as it involves all stakeholders, discusses the consequences and makes the decision very transparent, even to a board with not much project management know-how.
2. In this case the board has not much know-how of project management – adding to the scope without considering time tells everything.
3. As the board knows not much of project management it will know even less of agile methods, I am pretty sure. Furthermore other parts of the organization like marketing will not know much about agile methods either.
4. Agile methods were developed to manage software development, not to manage projects in general. Many organizations introduce agile methods in software development and other areas working together with it but other areas still run their projects with classic approaches as e.g. in Project Management: A Systems Approach to Planning, Scheduling, and Controlling by Harold Kerzner. This leads to a conflict I started to think of many years ago when Extreme Programming was en vogue. Up to my humble knowledge there is nothing addressing this issues, new books on agile management (and project management in most cases!) address software development only, never construction, engineering or marketing projects. There are not many new books on general project management and if so they focus on some specific topics or try to beat Kerzner, which ends most times in failure.
I see two directions for future developments:
Applying (and probably adopting) agile methods to many more areas, removing potential conflicts between areas.
Integrating agile processes into the classsic project management, so that parts of the projects can be run either classical or agile.
I am pessimistic that first direction will lead to success as I cannot imagine how agile should work when building your own little house but I am optimistic that the second will work. It will require at minimum:
Training of all project managers and staff on both approaches to understand each others way of working and thinking.
Definition of interfaces between both worlds, most important rules of communication between them: what, when, how and who communicates with whom both regularly and event driven.
Finally, the case study is titled with “Agile Requirements Management”. Why? In my humble opinion the topic is “Agile Management”, there is no specific problem with the management of requirements.
Looking forward to read or listen to your comments!