MIlestoneDrivenAgileExecution.pdf

Milestone Driven Agile Execution
Dr. Eduardo Miranda, Teaching Professor
Carnegie Mellon University
2023 © Eduardo Miranda 1

Milestone Driven Agile Execution (MDAX)
• Milestone Driven Agile Execution is a hybrid
management framework where the empirical
control component of agile development is
retained but the prioritization of the backlog is
done according to a macro or strategic
(milestone) plan that drives the execution of
the project
• The macro o strategic plan is structured around
the results or states the project must deliver or
reach and not on the scheduling of every
minute task, which makes the plan easy to
produce and robust
• MDAX is method agnostic, in the sense that the
development approach is not embedded in the
execution mechanism but in the plan that
drives it. This allows organizations using it to
choose the development approach that suites
them most
E. Miranda © 2023 2

Why MDAX (1)? The need for a plan. Often, our sponsors need to know when
something will be ready
E. Miranda © 2016 3
Adapted from:
• Jeff Sutherland, Ph.D. and Ken Schwaber (Co-Creators of Scrum), The Scrum Papers:
Nuts, Bolts, and Origins of an Agile Process, 2007
• Project Management the Agile Way, J. Goodpasture, 2015
Completion contracts, the
supplier commits to a finished
product; typically the price is
fixed
Best effort contracts, the supplier commits
to making a good faith attempt to fulfill all
the requirements with quality work, but
makes no commitment to a finished product;
work continues as long as the contractor is
paid for progress
Focus on predictability Focus on responsiveness

Why MDAX (2)? The need for a plan. Team guidance
“The release plan serves as a guidepost toward which
the project team can progress. Without the concept
of a release, teams move endlessly from one iteration
to the next. A release plan provides context that
allows iterations to combine into a satisfying whole.
This is a fundamental concern with any iterative
process, not just agile ones”
– M. Cohn, Agile Estimating and Planning, 2006
“The team creates a coarse-grained project plan,
possibly from the project map or a set of stories and
releases. It might be done using the blitz-planning
technique described later in this chapter, or XP's
planning game. This plan is reviewed by the lead
designer, the executive sponsor, and the expert user
to make sure the project is delivering suitable
business value for suitable expense in a suitable time
period”
– A. Cockburn, Crystal Clear, 2004
“… projects need an organizing principle and structure to allow
everyone to contribute toward the shared outcome. The high-level
plan and structure of large projects usually take a few forms:
– A high-level vision for what the end product will be. This may include
a visualization, a list of capabilities and any constraints, a set of
targeted customer segments and supported scenarios, and even an
anticipated press release for when the project is complete.
– A high-level architecture that lays out how components and
contributions to the product fit and work together to achieve the
product vision.
– A high-level schedule for product development with milestones for
the key events (like conferences, press announcements, or launch),
key dates when major product capabilities come together, and
expected dates when target metrics (such as performance, scale, or
participation) are reached.
• Creating a high-level vision, architecture, and schedule prior to
starting a large project is essential to success, but it can be
overdone. Too much big upfront planning tends to be wasteful,
since there are many unknowns and requirements often
change. Unfortunately, too little planning can lead to chaos and
failure, even if some feature teams succeed in building their
individual parts.”
– E. Brechner, Agile Project Management with Kanban, 2015

Why MDAX (3): The need for agility
“As implied by the definition of a project, it is
doubtful whether project planners can foresee all
the activities at the beginning of the project. Some
may perhaps argue that this is feasible, if the
planning is done well. But the problem is not just to
identify the potential activities. We face an even
more formidable problem: the kinds of activities that
should be undertaken depend on the results, the
successes or misfortunes, of earlier activities. To
make an optimal choice among the alternative
activities in the latter part of the project, the
outcomes of preceding activities have to be known”
– E. Andersen, Warning: activity planning is
hazardous to your project's health!, 1996

The
Milestone
Driven Agile
Execution
(MDAX)
Framework

MDAX Roles

MDAX roles
Stakeholder
Product owner
Project leader
Team
member
• Stakeholder. Anyone who does not work for the project but could
be affected by its outcome and must be consulted regarding one
or other project decision. Stakeholders include, the project
sponsors, other teams, users, operators, regulators, support
personnel among others.
• Product Owner (PO). The person accountable for building the
right thing. Specifically, he or she defines, prioritizes and accepts
the work performed.
• Project leader (PL). A generic term that encompasses the project
manager and Scrum master roles. Although both have different
level of control over the project, in what respects MDAX, they
have the same responsibilities: represents management to the
project and vice versa, enacts the MDAX process, coordinates
with external actors, removes impediments, ensures that the
team is fully functional and productive, shields the team from
external interferences.
• Team Member. Any person working in the project on a regular
basis who is directly involved in the creation, maintenance or
disposition of the projects deliverables. Collectively team
members are referred to as the Development Team. This
definition aims to include all the people that needs to have a
shared understanding of the project goals and how to realize
them, in that sense excludes people that might be assigned to the
project, but whose contribution is largely independent of the
project specifics.

Roles responsibilities
Activity
Roles Release
Planning
Milestone
(re)Planning
Look
Ahead
Meeting
Work
Item
Refinement
Meeting
Iteration
Planning
Meeting
Daily
Meeting
Iteration
Review
Meeting
Iteration
Retrospective
Meeting
Project
Review
Meeting
Stakeholder
Influences,
informs
priorities
Sets hard
milestones
Informs
Provides
feedback
(optional)
Authorizes
continuation of
work, re-
prioritizes,
terminates
project
Product Owner
Prioritizes,
has final
word, works
with
stakeholders
Must
concur
Selects next
WIs within
plan scope
Clarifies
Selects WIs
for next
iteration
within plan
scope
Approves work,
review
performance
Raises issues,
makes
suggestions
Project Leader Must concur
Has final
word, works
with team
Drives and
follow up on
issues
Facilitates Facilitates Facilitates
Facilitates,
report progress
Facilitates Facilitates
Team Member
Challenges,
makes
suggestions
Builds the
plan
As needed
Raises
issues,
makes
suggestions
Designs,
breaks WI
into tasks,
estimate
Reports
progress,
selects new
tasks
Run
demonstrations
Reviews ways of
working,
monitors
existing risks,
identifies new
ones
As needed

MDAX Artifacts

The Project Backlog (WBS)
Project Backlog (WBS). A
hierarchical structure listing the
expected project’s outcomes,
major activities and effort
allocations for work that has been
identified but not yet defined.
Unlike the traditional Product
Backlog, its items are not
prioritized since the priority is
derived from the milestone plan

Iteration Backlog
Stories (From the PB) Tasks Estimates (hrs.)
As a member, I can
read profiles of other
members so that I can
find someone to date
Prototype … 12
Design UI … 4
Code the … 12
Test … 8
Code … 10
Test … 4
Update ABC to version
3.0
Configure … 16
Migrate data … 8
Conduct performance
test …
8
As a member I can
update my billing
information
Design UI 8
Review business rules 4
Code … 16
Development effort (hrs.) 110
Iteration Backlog. The list of PBIs
selected for the current iteration
together with the tasks to be
executed for their realization. It is
convenient to organize the
iteration backlog as a task board to
help the team manage their work
visually

The Look Ahead Backlog
Next iteration
Later iterations
Time
to
ready
WIs
Items satisfying the
Definition of Ready
(DoR). Can be
processed as soon as
selected
Items in the process
of being readied
Look Ahead Backlog. A precedence
ordered list of all the items ready, or in
the process of being readied, to be
executed in coming iterations. It will
usually contain from one to three
iterations worth of work, but more
precisely, its content will depend on the
lead time required to ready the items.
Its elements are called WIs

Milestone plan
* Features included
Milestone Plan. A plan written
in terms of the sequence of
states the project will go
through to its successful
conclusion, its outputs and the
commitments made to the
team by other parties and not
the activities that will need to
perform to achieve them

Work Packages Schedule: Creating spaces to perform the work
Work Packages Schedule. Defines
when the work associated with a
given milestone, called its work
package, will have to be executed

(Iteration or Project) Earned Value Chart
0
50
100
150
200
250
300
350
0 2 4 6 8 10
Hours
Day
Planned Work
(Value)
Accomplished Work
(Earned Value)
Actual Effort (Actual
Cost)
Iteration Earned Value Chart. A chart
showing the amount of work completed
in the current iteration vs. the amount
planned and the actual effort spent so
far. This chart is started anew for each
iteration
Project Earned Value Chart. A chart
showing the amount of work completed
so far vs. the amount planned and the
actual effort spent. This chart is kept
through the duration of the project and
only changed if required by a massive
replanning of it

Milestone Slip Chart
Reporting date
Planned date
Milestone Slip Chart. A chart
showing the actual or currently
forecasted date of completion
of each milestone vs. the
originally planned date

MDAX Activities & Meetings

Release Planning
Release Planning. The process of
deciding what
functionality/components will be
released together such as the
delivery has value to its sponsors,
e.g. MoSCoW rules

Milestone Planning
Milestone Planning. The process of
planning the project in terms of its
outcomes and other relevant events
instead of the tasks that made it up

Look Ahead Meeting
Look Ahead Meeting. The process
of selecting PBI’s for execution
during the next two to three
iterations and readying it, e.g.,
making sure the resources and
materials required by them will be
available when needed

Work Item Refinement Meeting
Work Item Refinement Meeting.
The process of breaking down work
items that do not fit in an iteration
into smaller chunks of work and
clarifying any work requirements

Iteration Planning Meeting
Iteration Planning. In this process
work items are selected in the order
dictated by the milestone plan and
decomposed into the tasks necessary
for their realization in the next
iteration. This decomposition into
tasks might require the performance
of a detailed design for the portion
of the work to be accomplished as
part of the planning meeting

Daily Meeting
Daily Meeting. The meeting serves
two purposes: coordination and
control. At this meeting, which, as it
names implies, takes place every day
of the iteration, members of the team
discuss the work done, the obstacles
faced, and the tasks to be undertaken
next by whoever becomes available

Iteration Review Meeting
Iteration Review Meeting. The goal
of this meeting is twofold: to get
approval and feedback on the work
done and to maintain stakeholders’
engagement through their continued
involvement. It is conducted at the
end of each iteration

Iteration Retrospective Meeting
Iteration Retrospective Meeting. The
goals of this meeting are to assess
what was done and how much it took
to accomplish it, so that this
information could be used in the
planning of new iterations and to
reflect on what worked well, what did
not work, and to give team members
the chance to change it. During
retrospective meetings, the team also
evaluates the evolving system, review
areas that may be lagging behind, and
discuss areas with problems and
concerns regarding the remaining
work to be done. New project risks
are identified and existing ones
reevaluated

Project Review Meeting
Project Review Meeting. The
purpose of the this meeting is to go
over the progress of the team
against the plan, keeping all
interested parties abreast of any
change in the milestones’ due dates
and triggering a replanning or
termination in case of major
deviations or changes in the
business context. The meeting
frequency would be half or a
quarter of that of the iteration
review meetings, at the discretion
of the stakeholders

MDAX and risk management
• Risk management is a process which includes the deliberate identification,
assessment, response planning and monitoring of conditions that might,
somehow, harm the project
• The word deliberate is intentionally used to differentiate the risk management
process from the serendipitous realization that something might go wrong
• There is a prevailing belief among agile practitioners, that simply selecting an
agile method, like Scrum or Xp, suffices to manage risk. This is certainly not
the case, for agile projects, least for hybrid ones, that aim to bring
predictability to the development process
• Risk management activities
– Those leading to the project formulation, which deal with project goals, means and
context – Performed during project formulation, release and milestone planning
– Those that repeat during the execution of the project and focus on risks that could
deviate the project from its selected approach – Performed during the retrospective
meeting

Milestone Driven Agile Execution summary
• Separates planning from scheduling
– Release plan, number and content of incremental deliveries
– Milestone plan
– Iteration planning
• Makes the planning process participatory
– The people responsible for the execution of the plan is actively involved in its formulation:
– Helps develop a common understanding
– Promotes team involvement and commitment
• Retains the empirical process control philosophy of agile methods
– Task identification, task assignment and scheduling are made at the last responsible
moment
– Tasks are not started if all necessary preconditions are not present
– Execution is organized in short, fixed length time intervals, usually of two to four weeks,
called iterations, which give the project the opportunity to correct course before too much
effort is wasted in case things go awry

More Information
Bridging the Gap Between
Agility and Planning

MIlestoneDrivenAgileExecution.pdf

More Related Content

Similar to MIlestoneDrivenAgileExecution.pdf (20)

Recently uploaded (20)

MIlestoneDrivenAgileExecution.pdf