During an APM webinar on 10th March 2015, Steve Messenger explored how Agile Programme Management can lead to constant and incremental realisation of benefits, ensuring that the programme remains focussed on its vision and aligned to current business strategy and thinking. At the end of the webinar … [full recording available at: https://www.youtube.com/watch?v=YQa5YnqCHOE ] The remainder of the Q & A are included in this document. Steve is co-author of DSDM AgilePgM ™ that is described as offering an approach that provides the governance and rigour along with the agility and flexibility that organisations demand today. It can either be used as a stand-alone or combined with other recognised methods such as MSP or PMI’s PMP. Steve Messenger, DSDM Consortium Steve is the current Chairman of the DSDM Consortium, a role which entails setting the strategy for DSDM and leading the DSDM Board of Directors. He has been involved in Agile since its inception, DSDM being one of the signatories of the Agile Manifesto, and was also pioneering iterative approaches to software development from the mid-1990s. As well as managing many Agile projects, Steve has implemented DSDM into the highly regulated pharmaceutical industry, particularly during his leadership role in Mundipharma IT Services. More recently, Steve has been able to use his experience to help others. His reputation is strong, and he has been asked to speak at a number of conferences in Europe and the USA. He has also published articles and written blog entries on the topics of Agile Project and Programme Management and Scaled Agile. He was co-author of the DSDM Agile Programme framework and contributed to the DSDM Agile Project Framework. He now uses his experience to provide training and consultancy to large organisations, and this keeps him up to date on current Agile thinking, trends and problems.

1. pg. 1
QUESTIONS FROM WEBINAR – 10TH
MARCH 2015 [MESSENGER]
Agile Programme Management - Steve Messenger
1. Agile Programme Management: Is Agile the panacea to projects with weakly
defined project outputs?
I’ll answer this question from two aspects.
Firstly, Agile is NOT an excuse NOT to have a good Business Case for anything that
is undertaken in an organisation. It is still necessary to understand that the
project is worth doing based on the presumption that the benefits that will be
realised will outweigh the costs, risks and disruption of carrying out the project.
The Business Case will generally start at a high level – there is no point in going
into a lot of detail on the project outputs. However, it is a living document and
should be reviewed regularly and in particular after delivery of interim products.
As soon as the Business Case no longer makes sense, the project or programme
should be stopped.
Secondly, as long as the project outputs are defined at a high level, it is expected
in an agile approach that the detail of what that output is and how it is made up
will evolve and emerge through iterative feedback during the project. Hence, in
one sense it is weakly defined. The goal of the output is clear, however. For
instance, our output may be to get to Newcastle – the route we take to get there
and where we stop on the way can evolve, but at some point we need to get to
Newcastle.
2. Agile Programme Mgt: How do we ensure organisations trust the Agile concept
over the traditional command and conquer approach?
Trust is based on experience and seeing that something does actually work. Based
on that, an Agile implementation into an organisation should be undertaken as we
would undertake any other change programme. That is, in small steps, with the
ultimate vision clear. Trying to implement Agile as a “big bang” is likely to fail.
So one of the first steps is to choose a few projects that are important but not
critical to try out the agile approach. As these deliver successfully, people gain

2. pg. 2
QUESTIONS FROM WEBINAR – 10TH
MARCH 2015 [MESSENGER]
confidence in this way of working and the organisation itself starts to call for other
projects to be done in the same way. Choose good people to do these projects,
and also ensure there are people who have done agile before and understand
what works and what doesn’t.
You can also gradually implement techniques – for instance collaborative
workshops, Kanban boards, etc. – so that agile gets into the organisation in a
gradual but sustainable way.
3. At a time where people are busy with managing multiple projects. How do
Agile projects fit in whereby the expectation can often require for example a
full time 'Scrum Master'?
I think the key here is on the definition of a Scrum Master. In fact, this role really
operates at a single delivery team level and tends to be quite team focussed. It
can also change based on where the team is in a project. So it is NOT project
management at all. DSDM calls this a “Team Leader” (not in a management sense
but in being responsible for successful delivery within the team).
As soon as projects scale, or when there are multiple projects, good project
managers are required. The PM role is not command and control (and never was
in my opinion) but a facilitative and steering role. PMs can then often undertake
multiple projects.
As an aside, I have always found that trying to do too many projects at once
requiring the same resources actually slows things down – it is better and more
efficient to do fewer at the same time.
4. How do you make sure an agile programme ends? The temptation is often to
keep going and going!
Within the Agile Programme Management Framework, the Programme goals and
vision and Business Case are reviewed at regular intervals and certainly at the
enablement of capabilities. If the programme has delivered enough or if it no longer
makes sense based on the current Business environment and strategy, it should be
stopped. It is important to understand that this is NOT a team-level decision (even
though decisions are made at the lowest possible level). The decision needs to be
made by the Programme Management Team and possibly higher as it will require a
good understanding of the business strategy, the overall programme objectives,
budgets etc. This should make it easier to actually stop as those making the decision
are a little more removed from the excitement and momentum of actually doing it.

3. pg. 3
QUESTIONS FROM WEBINAR – 10TH
MARCH 2015 [MESSENGER]
5. How do you get the programme owner to be agile, ie open up comms, allow
decisions to be made lower down?
There are two answers to this.
Firstly, the AgilePgM guidance gives some characteristics of a good Business
Programme Owner and these should be taken into consideration when choosing the
person. They are basically John Eary’s “Theory Y” people. So they will naturally want
to be open and allow decisions to be made at a lower level.
Secondly, if the culture is such that the concept is totally alien then work needs to be
done to start changing the culture.
6. What is the difference between MSP and Agile Management?
Firstly, I will say that you can apply Agile Programme Management in an MSP
environment. Where they differ is in the approach and control.
Although in theory, the Blueprint in MSP can change, many implementations fix this
up front. MSP also expects a full project list up front. Agile Programme
Management makes it clear that the Business Architecture Model is a starting point,
and will change as experience grows. It also makes it clear that there is no point in
defining the projects and activities in very much detail beyond the immediate future.
Just in time planning is the norm as opposed to something you might decide to do.
Governance in Agile Programme Management is also focussed on the one goal of
successfully realising benefits and of leaving decisions as much as possible at the
point of impact – i.e. the lowest possible level. MSP governance tends to be more
bureaucratic and quite imposing.
Finally, the management and control philosophy in Agile Programme Management is
based on facilitation and steering towards the goal, and using the existing
information coming from the agile projects and activities to drive the reporting.
7. Are there any use cases we can look at which show the benefits of using an
agile approach?
There are cases studies on the DSDM web site – see dsdm.org.

4. pg. 4
QUESTIONS FROM WEBINAR – 10TH
MARCH 2015 [MESSENGER]
8. What needs to be in place if you're expecting the delegation of decision
making to the lowest possible level? It seems to require a huge leap of faith.
I think other answers cover this. Basically, this is a culture change and the leap of
faith will come from seeing positive experiences and choosing the right types of
people – i.e. “Theory Y” people
9. As there will only be 2 winners of the guidebook, how can the rest of us get
hold of it please as it will be very useful to have? Thank you
They are available via the DSDM web shop – dsdm.org, or via Amazon. You can
also take an AgilePgM foundation course via APMG - http://www.apmg-
international.com
10.In the five principles of Agile Management it states "Decision making powers
are delegated to the lowest possible level"
Yes
11.How do you ensure that individuals do not influence or make a decision due to
a personal desire/requirement and in turn compromise the first principle that
"programme goals are aligned to business strategy"?
Decisions are made at the lowest possible level. This doesn’t mean all decisions
are made at the lowest level. The guidance on Governance clearly states that
decisions that could affect the Programme vision or its alignment to business
strategy need to be made by those defining the Business Strategy. There are
specific roles that are responsible for highlighting inconsistencies in either
technical architectures or in the Business Architecture Model. The inconsistencies
can be escalated to the Programme Management level.
We have also removed separate Project Boards – this role is undertaken by
members of the Programme Management team, who understand the goals and
vision of the programme and its alignment to the Business Strategy.
12.In agile programme management, if you pushing responsibility for planning
down into the projects, how do you ensure that all the dependencies between

5. pg. 5
QUESTIONS FROM WEBINAR – 10TH
MARCH 2015 [MESSENGER]
projects are surfaced since escalation from individual projects won't
necessarily reveal all the critical dependencies?
Whilst responsibility for planning the internals of a project are “pushed down” to the
project teams, tranche planning is done at the Programme level. This will identify
the interdependencies between projects and activities. Also, the high level
requirements of each project are agreed by the Programme level, and any other
dependencies should be seen here.
13.Please could Steve Messenger kindly advise whether Agile to Programme
Management, is what PRINCE2 is to Project Management? The approach
appears similar.
Agile Project and Programme Management gives guidance in running programmes
and projects with an agile mind-set, and have been developed with agile at their
core.
14.Does a business have to be a certain level of 'maturity' before a successful agile
programme approach can be introduced?
I would say definitely for the Programme Level – see earlier answer.
15.How do you convince project sponsors that unplanned tranches are acceptable
and a good thing?
The problem actually goes away as the only planned and agreed tranche is the
next one. This means that whilst an idea of funding for the whole programme is
known, only funds for the next tranche are actually approved. Whilst the
roadmap in Programme Foundations may hint at future tranches, these are
uncertain and it is accepted that the next tranche will only become clear towards
the end of the running tranche.
The Tranche Review asks such questions as “have we done enough already?”; “is it
worth continuing?” It is at this stage that the next tranche (or tranches as parallel
tranches are possible) is planned and agreed that it is worth doing.
16.What about scalability with AGILE and avoiding a series of 'bolt-ons' where you
would have done things differently if you'd planned it from the start?

6. pg. 6
QUESTIONS FROM WEBINAR – 10TH
MARCH 2015 [MESSENGER]
Both Agile Programme Management and Agile Project Management are designed to
be scalable – in fact Agile Programme Management expects to manage many
projects and activities at the same time.
Even in Agile, there should be some up-front planning – it is the detail that changes.
Traditionally we might have tried to plan in detail well into the future. In Agile you
should plan the whole project or programme in outline and then the next immediate
stage in detail. Good agile also does “Enough Design Up Front” – this means
understanding the problem enough to check completeness and understanding and to
be able to prioritise.
Also to have a starting architecture (which will evolve) so that you can avoid the
problem in the question. The skill is knowing how much “Enough” is and not going
into too much detail that might change later.
17.What strap line would be useful to start to convince the strategic team that
Agile PGM is the way to move forward?
I would use the philosophy of Agile Programme Management:
“An Agile programme delivers what is required when it is required – no more no
less.”
Or
“Agility with appropriate governance and control”
18.Delivering continuous benefits would also mean delivering continual change,
would this not cause more disruption than an 'expected change' date as per
waterfall? Hope that makes sense! Thank you. Great session so far.
Yes – and the deliveries really have to be balanced with what the organisation can
actually cope with. Some agilists say “deliver every 2 weeks” – I think this is
unrealistic in many organisations. In programmes, much of the work is actually
done by the business areas (changing, creating new processes; organisational
change etc.) so this has to be planned in.
In organisations I have worked in we seemed to settle on release windows of
project outputs of about 3 months. In Agile Programme Management, we expect
major capabilities to take 6-9 months.