Hybrid Agile Project Management

Learn How to Get the Best of Both Worlds

Managed Agile Development Process Overview

1
 Managed Agile Development
Process Overview

© 2014-2020 High Impact Project Management, Inc. 2

In addition to the inception planning that should happen on the front end of a hybrid Agile project,
there needs to be a way of integrating some level of plan-driven project management with an Agile
development approach as the project is in progress. That’s what we’re going to talk about in this
lesson.

2
 Managed Agile Development Process

Originally created
for a large The program The customer wanted
had a fixed-price some flexibility in
government contract requirements
program

© 2014-2020 High Impact Project Management, Inc. 3

Some years ago I was responsible for managing a very large program for the US government.

The program had a fixed-price contract to deliver a major software system for a mission-critical
application for the government agency that was the primary customer. In fact, the program was
large enough that it required some level of congressional oversight over the costs and schedule of
the program. If the program went over budget or was delivered late, it would get a high level of
congressional attention.

However, the customer wanted to have some flexibility in defining the details of individual
requirements as the project was in progress. There is naturally a big challenge in balancing the
need for overall control of the costs and schedule for the program and still providing some level of
flexibility to make changes as the project was in progress.

3
 Managed Agile Development Process
Traditional
“Macro” Layer:
Project Management Layer
Project Charter Limited Form of Change Management
Project Schedule On-going Project Management

“Micro” Layer: Development Layer

Based on Scrum

2-4 weeks

SOURCE: HTTP://EN.WIKIPEDIA.ORG/WIKI/S CRUM_(DEVELOPMENT)

Cobb, Charles, Managed Agile Development – Making Agile Work for Your Business, Outskirts Press, 2013

© 2014-2020 High Impact Project Management, Inc. 4

To meet that challenge, I created a framework which I have called the Managed Agile
Development framework. This slide shows what the Managed Agile Development process looks
like.

• The macro-level framework is a plan-driven approach, designed to provide a sufficient level

of control and predictability for the overall project. It defines the outer envelope (scope and
high-level requirements) that the project operates within

• Within that outer envelope, the micro-level framework utilizes a more flexible and iterative
approach based on an Agile Scrum approach that is designed to be adaptive to user needs

In the particular government program that this was originally created for, we had to meet some
schedule and cost milestones within the project which defined the “outer envelope” that the
project had to operate in, but within that “outer envelope”, there was enough slack to be fairly
agile and adaptive at the micro layer.

If there is sufficient slack in the outer envelope, minor changes can be absorbed in the micro
layer without impacting the overall cost and schedule milestones for the project at the macro
layer. Naturally; however, if there is a big enough change in the micro layer, it would need to
trigger a change in the costs and schedules of the project at the macro layer.

4
 Managed Agile Development Process
“Macro” Layer: Traditional
Project Management Layer
Thick Macro Layer
With Fairly Well-defined Limited Form of Change
Project Charter
Requirements Management
On-going Project Management
Project Schedule

“Micro” Layer: Development Layer

Based on Scrum
Limited Flexibility in the
2-4 weeks
Micro Layer

SOURCE: HTTP://EN.WIKIPEDIA.ORG/WIKI/SCRUM_(DEVELOPMENT)
Cobb, Charles, Managed Agile Development – Making Agile Work for Your Business, Outskirts Press, 2013
© 2014-2020 High Impact Project Management, Inc. 5

This model can be very flexible and adaptable. For example, the “Macro” layer can be as thick or
thin as you want it to be. In one situation, you can have a fairly thick and well-defined macro layer
that specifies requirements in a greater level of detail as shown here and allows for less flexibility in
the Micro Layer

5
 Managed Agile Development Process
Traditional
Thin Macro Layer “Macro” Layer: Project Management Layer
Limited to High-level
Requirements Only Project Charter Project Schedule

“Micro” Layer:
Development Layer
Based on Scrum
Greater Flexibility for 2-4 weeks
Further Defining
Requirements in the
Micro Layer

SOURCE: HTTP://EN.WIKIPEDIA.ORG/WIKI/SCRUM_(DEVELOPMENT)

Cobb, Charles, Managed Agile Development – Making Agile Work for Your Business, Outskirts Press, 2013

© 2014-2020 High Impact Project Management, Inc. 6

In another situation, you can have a fairly thin and loosely-defined macro layer that is limited to
high-level project requirements or objectives and rely much more heavily on defining more detailed
requirements in the micro layer as shown here.

6
 Levels of Planning

Project-level Planning

Release-level Planning

Sprint-level Planning

© 2014-2020 High Impact Project Management, Inc. 7

There are many ways to implement this model – it’s intended to be only a flexible framework and
not a prescriptive methodology. However, I would like to walk through a general example of how it
might be implemented. The full implementation of this model might have three different levels of
planning:

• Project-level Planning

• Release-level Planning

• Sprint-level Planning which might be called Iteration-level Planning

We will discuss each of these levels in more detail in the following slides

7
 Project-level Planning
Project Charter: Product Backlog:
Background Epics and themes
Problem statement User stories
Product vision
Goals and objectives
Business justification
Scope, constraints
Development process
Risks, assumptions
Project-level Solution overview
Planning
Estimated costs and schedule
Project-level
Review/Approve Integration/Test
Customer
Project Charter/Product Backlog

Final UAT and Customer Release

Release to Production
© 2014-2020 High Impact Project Management, Inc. 8

The highest level would be the project-level planning which would start with a joint project
inception with the customer to complete at least a high-level project plan.

As I have mentioned, that level of planning could be as “thick” or “thin” as necessary depending
on the level of uncertainty in the project and the relationship with the customer and the
customer’s expectations. The output of the project-level planning might be a project charter
defining:
• The background behind the project
• The problem statement of the problem the project is intended to solve
• The vision for the solution to the problem
• The goals and objectives the project is intended to accomplish from a business
perspective
• The business justification for the project
• The scope of the project and any constraints on the project
• The development process
• Any significant risks and assumptions
• An overview of the solution
• The estimated costs and schedule for completing the project
As well as a Product Backlog containing epics and themes and user stories.

At the end of the project, there might be some level of overall final integration and testing and a
final user acceptance test and review of the solution prior to release to production.

8
 Project-level Planning Objectives
Defining the overall scope of the project and defining critical business objectives

Organizing the project team and kicking off the project

Defining a Project Charter

Defining and ordering the Product Backlog required for the project

Tentatively allocating the user stories in the Product Backlog to releases if necessary

Developing a high-level roadmap for the project

Identifying and resolving any significant issues, and uncertainties

© 2014-2020 High Impact Project Management, Inc. 9

This slide shows some objectives that might be appropriate for the project-level planning
process:
• Defining the overall scope of the project and critical objectives to be accomplished
• Organizing the project team and kicking off the project
• Defining a Project Charter that includes the business objectives to be accomplished, risks,
assumptions, and dependencies, and key milestones to be accomplished (See Project Charter
Document Template)
• Defining and ordering the Product Backlog required for the project and developing a high-
level estimate of the effort required for each product backlog item in terms of story points
• Tentatively allocating the user stories in the Product Backlog to releases if necessary
• Developing a high-level roadmap for the project
• Identifying and resolving any significant issues, and uncertainties that must be resolved prior
to starting the project and mitigating any significant risks

9
 This is not intended to be a prescriptive
approach and it can be easily simplified

© 2014-2020 High Impact Project Management, Inc. 10

If you did all of the project-level planning I just discussed, that would be a fairly “thick” or robust
level of planning; but, of course, this is not intended to be a prescriptive approach – it is only
provided as an example and it can be easily simplified.

In the next lesson, we will go through the release-level and sprint-level portions of the process in
more detail.

10
 NEXT LECTURE…
MANAGED AGILE DEVELOPMENT
RELEASE-LEVEL AND SPRINT-LEVEL
PLANNING

© 2014-2020 High Impact Project Management, Inc. 11

In the next lesson of the course we’re going to start a new section on an Agile Project Management
Overview and the first lesson in that section is “What’s Really Different About Agile Project
Management?”

11