This is so true!

P.

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!

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 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…

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.