Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

24
Managed Agile Development Framework

THE MANAGED AGILE DEVELOPMENT FRAMEWORK described in this chapter is different from the Scaled Agile Framework (SAFe^®) and the Disciplined Agile^® approach. Both of those are designed for full‐scale enterprise‐level Agile implementations. The Managed Agile Development framework is a project‐level framework that is intended to provide a balance of agility combined with some level of predictability and control.

It is intended for companies that are unable or not ready to move to a more complete top‐to‐bottom Agile model such as the Scaled Agile Framework.
It is a hybrid project life cycle model consisting of a blend of an adaptive Agile development approach based on Scrum at the micro‐level and a more classical plan‐driven approach at the macro‐level, as shown in Figure 24.1.
It can easily be customized to fit a given project and business environment and can be adapted to companies that have more classical plan‐driven business and project/portfolio management approaches at a higher level.
It generally requires no significant transformation of those higher‐level processes.

I created this approach initially when I was managing a large government project. In order to meet government contractual requirements, we were required to commit to some plan‐driven milestones at the program level, and we were required to report earned‐value metrics to measure progress against those milestones. On first glance, it may sound impossible to make an Agile approach work in that environment, but it worked quite well.

Naturally, there are trade‐offs between the level of agility and flexibility to adapt to change at the micro‐level and the level of predictability and control at the macro‐level. It is important that both the client or business sponsor and the development team agree on those trade‐offs. The framework provides a mechanism for making those trade‐offs by making the macro‐level as thick or thin as you want to fit a given situation.

Schematic illustration of Managed Agile Development Framework macro-level and micro-level. — **FIGURE 24.1** **Managed Agile Development Framework macro‐level and micro‐level.**

Source: http://en.wikipedia.org/wiki/scrum_(development)

Instead of having an either‐or choice between a fairly rigidly controlled Waterfall approach at one extreme and a completely adaptive approach with very limited or no control over costs and schedules at the other extreme, you can customize an approach that provides the desired balance to fit a broad range of situations. The example process flow shown here is intended for large, complex projects because it is easier to scale down a process and to decide to eliminate or minimize activities that are not important to a project than it is to scale up and add activities.

MANAGED AGILE DEVELOPMENT OVERVIEW

This framework consists of two layers, as shown in Figure 24.1:

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 designed to be adaptive to user needs.

The combination of these two layers is designed to provide a balance of predictability/control and agility:

The macro‐level process provides a high‐level framework for achieving some level of predictability and control in the project.
The micro‐level process provides a more flexible and adaptive approach designed to accelerate the development process and optimize the solution to meet user needs.

These two different levels will need to be synchronized with each other. This framework is intended to be customized and/or scaled up and down to fit particular projects:

For small, simple projects, the macro‐level can be simplified or eliminated.
Larger, more complex projects may require more emphasis on a plan‐driven approach at the macro‐level with more detailed requirements.

The Macro‐Level

At the macro‐level, a Project Charter document is created to define the major deliverables and estimated project milestones based on high‐level project objectives. Optionally, a Project Plan could also be created with more detail on the project plan. Once that high‐level plan is established, it provides a basis for ongoing management of the project. Changes to those macro‐level requirements can be controlled as necessary to manage the overall scope of the project.

The Micro‐Level

At the micro‐level, requirements are further defined and elaborated in more detail in an iterative approach, with direct participation by the users in an environment that provides more flexibility to adapt to their needs. At a detail level, changes are not finalized until the design has been reviewed and approved by the users at the end of each sprint.

If the work being done at the micro‐level results in a change to the higher‐level requirements and plan at the macro‐level, those changes are fed back to the macro‐level process, and the macro‐level plan should be adjusted as necessary for the impact of those changes.
However, if the process is implemented as it should be, there should be sufficient slack in the macro‐level plan to absorb minor changes in requirements at the micro‐level so that only significant changes in the micro‐level should require replanning at the macro‐level.

OBJECTIVES OF MANAGED AGILE DEVELOPMENT

The objectives that this framework is intended to achieve are a combination of the benefits of a classical plan‐driven approach with the benefits of a more flexible and adaptive Agile approach.

Plan‐Driven Benefits

A well‐defined process is consistently implemented and is somewhat predictable.
High‐level milestones provide a framework for managing user expectations and integration with other activities outside the Agile development environment.
Scope and cost of projects can be easily and effectively managed.
There is improved capacity planning and resource allocation.
The process provides a basis for learning and continuous improvement.

Agile Benefits

1. User Satisfaction and Operational Business Results

Users are engaged more collaboratively in the effort to define requirements.
There is earlier and more direct feedback on design alternatives from iterations and prototyping.

2. Time‐to‐Market

Requirements are ordered and grouped into releases and iterations.
Efforts can be more concurrent and less sequential where possible.

3. Productivity and Efficiency

The team is empowered to tailor the process to fit the project.
The process can be optimized for the project.
Unnecessary paperwork is reduced (more emphasis on direct team involvement and face‐to‐face communications).
The process is a collaborative, cross‐functional approach.

Key Differences from a Typical Waterfall Approach

There are several aspects of this framework that are significantly different from a typical Waterfall approach.

1. Partnership with the Business Sponsor and Business Users

The typical Waterfall model is based on a contractual type of relationship between the Business Sponsor/users and the development team. A collaborative, partnership approach is much more suited to an uncertain environment where it is necessary for the customer to take a more active role in working with the project team to define and evaluate the work that is in progress.

Typically, with the Waterfall model, the business commits to well‐defined requirements upfront, and the development organization commits to well‐defined schedules, costs, and plans to deliver against those requirements. The Project Manager then takes full responsibility for delivering a solution to meet those agreed documented project requirements.
In the Managed Agile approach, a high level of understanding of the project scope and high‐level requirements exist in the form of user stories at the macro‐level. The level of detail in the requirements definition may vary, depending on the nature of the project; however, it is normally not necessary to specify all the details of how a solution will be developed in the project‐level planning.
Factors that might impact the level of detail that goes into the requirements definition in the project‐level planning include:
- the level of uncertainty in the requirements and the level of confidence needed in the cost and schedule estimates
- the level of risk in the project
- the need for coordination with other groups outside of the Agile development environment.

Project‐level planning should define the project to a sufficient level to develop an estimate of the project costs and schedule to whatever level of accuracy is required (provided, of course, that the desired level of accuracy is realistic and consistent with the level of uncertainty in the requirements).

- The project‐level planning in the macro layer simply establishes the outer envelope that the project is expected to operate within.
- It isn’t intended to be a rigid contractual agreement. It is essential to have a level of trust and partnership between the business users and the development team to make that work.

Within that envelope established at the macro‐level, the Business Sponsor/users and the project team will jointly own responsibility for further defining the details of the solution, as well as optimizing it to make it successful in the micro‐level process. This approach will provide more flexibility to adapt to business requirements as the project progresses and provide a much higher level of assurance that the final solution will meet operational business needs with very high levels of quality and user satisfaction.

2. Cross‐Functional Team Approach

With a typical Waterfall approach, functional managers might primarily manage the efforts of the functional departments that contribute to the project, such as development and QA. Their efforts are typically sequential, and the Project Manager works to coordinate those efforts into the overall plan. A cross‐functional team approach is more suited to maximizing the productivity of the team and encouraging creativity and innovation.

Implementation of this framework requires more of a cross‐functional team approach, where the various functional participants in the team (Developers, Business Analysts, testers, etc.) work concurrently as an integrated team with the business users to jointly define, develop, and test the solution throughout the project.
The entire project team will also be involved in making collaborative, cross‐functional decisions as part of the project‐level planning and release‐level planning activities, together with the Business Sponsor, Product Owner, and business users.

3. Rolling‐Wave Planning Approach

With a typical Waterfall methodology, an attempt is made to develop a detailed plan for the entire project at the front end of the project. A rolling‐wave planning approach allows for the project plan to be further elaborated as the project is in progress and provides a higher level of flexibility and adaptivity for an uncertain environment.

The Managed Agile Development framework is based on progressive elaboration and rolling‐wave planning. Requirements are generally defined only to a high level in the initial project planning, and then requirements are progressively elaborated in more detail as the project progresses. The advantages of that approach are:

It expedites the upfront project planning process.
It allows the user to defer decisions about detailed requirements until a point where more information is available to make better decisions. In Agile terminology, this is called the last responsible moment, because it is the latest point possible that a decision can be made without having an adverse impact on the delivery of the solution.
More direct communication with the users minimizes misunderstanding and miscommunication of requirements, and user requirements can be better integrated with the design effort to optimize the design.
It minimizes the effort required to document requirements along with translation errors that might result from misunderstanding documented requirements. (Note that this approach does not eliminate the need for documented requirements.)

4. Incremental and Iterative Approach

With a typical Waterfall methodology, the entire solution is usually designed, developed, and tested sequentially. The disadvantages of that approach are:

Slow overall development time due to the sequential nature of all activities.
Feedback on problems and defects may not be discovered immediately.
Opportunities to get early user feedback and inputs may be limited because users are not involved at all in the development effort to provide feedback, and user acceptance doesn’t occur until the very end of the project.

The advantages of a more incremental and iterative approach are:

Using a more iterative approach will provide earlier realization of business benefits and greater ROI.
Using a more iterative approach will provide faster overall development time because more activities can be overlapped and concurrent.
Defects and problems can be detected and corrected much earlier.
The user is much more directly engaged in the project as it progresses. This provides direct and immediate feedback and will result in a higher level of assurance that the project will meet user needs.
Some efforts can be performed concurrently rather than sequentially, based on a risk assessment by the project team. For example, the planning phase for each release can typically be overlapped with the execution phase of the previous release.

FRAMEWORK DESCRIPTION

Project Organization and Work Streams

This approach is dependent on using relatively small teams of approximately 8 to 10 people each to perform the design, development, and testing of the solution.

For larger projects, the overall project can be broken up into work streams, and each work stream can be assigned to a team with a team leader/Scrum Master.
Each team will consist of the minimum core team required to design, develop, and test the requirements associated with that particular work stream (Developers, testers, and Business Analysts).
Specialized resources such as data architects, database developers, and system architects can be centralized as needed to provide support to all work stream teams.

High‐Level Process Overview

Each project or work stream will normally be broken into releases and iterations, and each release will typically result in a deliverable product to production, as depicted in Figure 24.2.

The purpose of breaking the project into releases is to accelerate the delivery of critical features.

FIGURE 24.2 Managed Agile Development high‐level framework overview
The features and user stories to be included in each release should be prioritized to deliver the functionality that provides the highest level of value as early as possible.
That allows critical functionality to be delivered quickly, without waiting for 100% of the total functionality required for the ultimate implementation of the system.
An important assumption in this is that the deliverables within each release are sufficiently independent of each other that they can be delivered to production in increments.

Project‐Level Planning

Project‐level planning will normally consist of:

Breaking up the project into work streams if necessary for large projects.
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 in Appendix C.
Defining and ordering the Product Backlog required for the project or work stream 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 plan with resource requirements for completing all of the requirements of that work stream, including identifying any dependencies on shared resources outside of the project team.
Identifying and resolving any significant issues and uncertainties that must be resolved prior to starting the project and mitigating any significant risks.

Project‐level planning will normally be performed once at the beginning of the project, and that plan will be updated as the project progresses. The project‐level planning process is shown in Figure 24.3.

Release‐Level Planning

Release‐level planning will normally consist of tentatively allocating the user stories in the release to iterations, estimating the schedule required to complete each of the iterations required for that release, and resolving any major questions or issues that must be resolved prior to beginning the effort required for that release.

The results of the release‐level planning in each project or work stream will normally be fed back into the macro‐level process to ensure that the micro‐level release‐level planning is consistent with macro‐level project goals and deliverables.

The release‐level planning process is shown in Figure 24.4.

Iteration‐Level Process

Each release may be further broken down into iterations. (If a project contains only releases with no iterations, the release‐level planning and iteration‐level planning will be combined.)

An iteration is a portion of a release that is segmented from the rest of the release for the purposes of optimizing the delivery of the overall release.
An iteration normally produces some deliverable functionality that can be demonstrated to the user to show progress and also to get user feedback and inputs; however, an iteration may not be releasable to production.
The major benefit of segmenting a release into iterations is to provide a mechanism for getting early user feedback and inputs on the results of each iteration.

Fixed‐length iterations are preferred because they allow the team to establish a cadence, but iterations may or may not be fixed‐length time‐boxes. They may be sized to fit the level of effort required to complete the user stories that the team included in that iteration. The length of iterations should be kept relatively short to demonstrate progress and get user feedback quickly.

Schematic illustration of project-level planning — **FIGURE 24.3** **Project‐level planning**

Schematic illustration of release-level planning — **FIGURE 24.4** **Release‐level planning**

The project team will be responsible for planning and performing each iteration. Iteration‐level planning will typically consist of:

Clearly identifying all user stories to be included in that iteration.
Resolving any major questions that need to be resolved prior to starting the iteration and identifying the level of user input required for completing each task during the iteration. If there are significant uncertainties that cannot easily be resolved prior to the start of the iteration, a special iteration or spike should be planned if necessary to resolve those uncertainties prior to beginning the normal development iteration.
Defining user acceptance criteria for each user story to be included in the iteration.
Identifying the development tasks required for completing that iteration, including testing and allocating the tasks to individual developers.
Estimating the effort required for completing each development task in the iteration. The estimate must include all activities required for development and testing of the task (see definition of “done”).

The results of each iteration will normally be as fully tested as possible and accepted by the user prior to completion of the iteration:

Developers will be responsible for designing, developing, and unit‐testing as the software is developed.
QA testers who are an integral part of the development team will be responsible for any system testing to verify that the results of the iteration meet requirements.
The users will be asked to perform limited user acceptance testing at the completion of the iteration to validate that the results of the iteration meet user needs.

The iteration‐level planning process is shown in Figure 24.5.

Requirements Management Approach

The users will be heavily and directly engaged in the development effort as the project progresses to provide direct feedback and inputs. In cases that require a significant amount of user input, a prototyping approach may be used to further define and elaborate user inputs as the design effort progresses. An example of a situation that would require a significant amount of user input might be the design of a graphical user interface (GUI).

A progressive elaboration approach will be used to define requirements in more detail as the project is in progress.

At the beginning of the project, a planning session such as a joint application development (JAD) session is normally held jointly with the business users, the project team, and all major stakeholders.

FIGURE 24.5 Iteration‐level planning
The result of that session is typically a vision for the solution and a list of high‐level features for the solution, usually in user story format. That feature list will become the Product Backlog, which will be used to plan and drive the development effort.
The Product Backlog will be ordered and broken down into releases and iterations, primarily based on the relative importance of the items in the backlog to the users. However, other factors such as the stability of the requirements associated with the items might be important considerations. (For example, some items that are known to have unstable requirements may be deferred to allow more time for the requirements to stabilize.)

The requirements definition effort for the project will normally be organized as follows:

Project‐level: During the project‐level planning of the project, the high‐level requirements for the entire project will be identified to the extent necessary to define the requirements at a feature or user‐story level. Those requirements will be tentatively assigned to releases.
Release‐level: The release‐level planning for each release will primarily focus on:
- Resolving any outstanding questions and issues associated with the release backlog to the extent necessary to start design and development of each iteration in the release. The release backlog is the subset of Product Backlog items included in the current release.
- Defining the requirements for subsequent releases only to the extent that they might impact the implementation of the current release. For example, during the development of the detailed requirements for release 1, the detailed requirements for releases beyond release 1 will only be defined to the extent that they might impact release 1. As an example, hooks might need to be put in the architecture required for release 1 to accommodate features that are expected later in releases 2 and 3.
Iteration‐level: At an iteration level, the detailed requirements for each iteration will be elaborated only to the extent needed to complete the design and development effort for that iteration.
- Depending on the functionality included in that iteration, the requirements elaboration might be completed prior to the design and development effort, or it might be completed concurrently with the actual design and development effort.
- It is important to note that requirements elaboration means clarification of details of how a requirement should be implemented. Major changes to requirements should not be allowed once an iteration is in progress.

It is assumed that detailed requirements will continue to evolve as the project progresses without formal change control; therefore, formal change management will normally not be done at the micro‐level, except for changes that impact the high‐level requirements.

The business user representative (Product Owner) can approve at the micro‐level any changes to the detailed project requirements that do not significantly impact the high‐level project plan.
Any change that significantly impacts the high‐level scope and direction of the project should be approved by the project sponsor.

Project Scheduling Approach

An implication of breaking the project up into releases and iterations using a rolling‐wave planning approach is that, at the onset of the project, only an estimate of the overall project schedule will be known.

For example, at the beginning of release 1, an estimate of the schedule for completing the release 1 requirements will be made, but normally only a rough estimate of the schedule for subsequent releases and iterations will be available.
As each release and its iteration are completed, the schedule for subsequent releases and the overall project schedule will be progressively defined and updated.

At the macro‐level, an overall project schedule will be developed and maintained throughout the project, but it is understood that because the requirements will be progressively elaborated only at the micro‐level within each release and iteration, those estimates of the project schedule are likely to change. Adjustments to the scope of what is included in each release and iteration may be needed to synchronize the deliverables with the macro‐level project schedule.

Project Management Approach

The following is a description of the project management approach:

The high‐level Project Charter document defined at the macro‐level will typically define the overall scope and vision for the project and will also include milestones for measuring progress. This high‐level Project Charter document defines the envelope that the project is expected to operate in; however, it is understood that the scope may change as the project progresses.
The high‐level Project Charter document will normally be prepared by the Project Manager, with close collaboration with the business user and approved by the project sponsor. Once approved, any significant deviations from these high‐level artifacts must be approved by the project sponsor.
At the micro‐level, a business user representative (Product Owner) and the project team will jointly take responsibility for the execution of the project as long as the project stays within the envelope defined by the high‐level Project Charter document. The business user representative (Product Owner) must be a knowledgeable subject matter expert in the area being developed and must be empowered by the project sponsor to make decisions on how the detailed requirements associated with how the functionality will be implemented. This might be implemented in different ways:
- In the simplest case, the project sponsor, Product Owner, and business user representative could be the same person.
- In a more complex case, you might have a project sponsor who has ultimate approval authority for the project and a Product Owner who has decision‐making authority on the details of how the project is implemented.
- You might or might not have business user representatives in addition to the Product Owner to represent different stakeholder needs. (The Product Owner may serve as representing all business needs.)
The project team will normally track progress against the high‐level milestones at the macro‐level and periodically publish status reports to the project sponsor.
At the macro‐level, the major milestones to be tracked might include completion of:
- project‐level planning
- release‐level planning for each release
- completion of each iteration within the release
- limited UAT for the deliverables for each iteration
- User Acceptance Test (UAT) for the deliverables for each release.
  At the micro‐level, the activities to be tracked might include:
- sprint burn‐down charts to monitor completion of development tasks and team velocity
- release burn‐down charts to monitor completion of development and testing for all project requirements
- test plan progress to monitor progress of completing test cases required by each test plan
- resolution of any bugs.

Communications Approach

Most of the communications within the project team and with business user representatives will rely heavily on direct communications (either face‐to‐face or remote conferencing). Table 24.1 is a suggested format that can be used for managing project communications.

In large projects requiring multiple work streams, there will naturally be a need for additional weekly meetings to coordinate the efforts of multiple teams.

TABLE 24.1 Format for managing project communications

Meeting	Description	Frequency
Daily Scrums	A Daily Scrum is an Agile practice and is used at the team level within each work stream. The team leader (Scrum Master) responsible for each work stream will facilitate these meetings In a pure Agile environment, the agenda for this meeting is very simple and follows standard Scrum guidelines. Everyone on the team answers three questions: What did you accomplish yesterday for the project? What are you planning to work on today? What obstacles are in your way? In some cases, such as when an offshore development team is involved, there may be a higher need for communications, and going beyond these basic questions may be necessary To keep these meetings short and focused, the rule should normally be not to attempt to resolve issues and questions in this meeting unless they are very simple things to resolve. If anything comes up that requires a significant amount of discussion, another meeting should be scheduled to discuss it outside of the Scrum.	Daily
Scrum meetings	The micro level will include normal Scrum meetings such as Sprint Planning, Sprint Review, and Sprint Retrospective
Other project meetings	Other meetings will be scheduled as necessary to resolve specific issues that cannot be resolved in the Daily Scrum meetings.	As needed
Weekly status meeting	This will typically be a weekly meeting to review project status with the project sponsor. This meeting is primarily focused on reviewing macro‐level progress with the project sponsor, where the other meetings are more at the micro‐level. For small projects, this meeting might not be necessary.	Weekly

ROLES AND RESPONSIBILITIES

Table 24.2 is a suggested description of the major roles and responsibilities of the key participants in this process. Note that some of these roles may be combined in actual practice. These roles and responsibilities are intended to be customized as necessary for a given business and project environment.

TABLE 24.2 Roles and responsibilities of key participants

Role	Responsibility
Business Sponsor	The business sponsor has the ultimate responsibility for the success of the project or program from a business perspective, including: Providing direction on business objectives that the project or program must achieve to maximize the benefits of the project or program to the business Ensuring that the appropriate business personnel are fully engaged in defining and prioritizing requirements for deliverables Reviewing and approving all deliverables prior to implementation Resolution of any issues that cannot be resolved by the project team
Business Process Owner(s)	Business process owners are responsible for the execution of the business processes that are affected by the project. Business process owners are responsible for: Planning and implementing any business process changes that may be required by the solution Ensuring that the solution is consistent with new business processes Planning the cutover of the solution to ensure that any business process changes and other important requirements outside of the development effort, such as user training, are synchronized with the implementation of the solution
Subject Matter Expert (SME)	Subject matter experts provide domain‐specific knowledge in an area that is relevant to the project, including: Representing user needs Clarifying project requirements as necessary Reviewing and signoff on business‐related project documents
Stakeholder	A stakeholder is a person, group, organization, or system that affects or can be affected by an organization's actions. A stakeholder is identified as someone who has a direct or indirect interest in a project. Stakeholders can range from the project sponsor to an end user, and a stakeholder can be any person who can affect or be affected by the products of a project, either during the project or after the project has been completed. Stakeholders are responsible for: Representing their area of interest and providing inputs to the project requirements and project planning effort to ensure that there is no unexpected impact to their area of interest Ensuring that the solution is consistent with the requirements in their area of interest and validating that the solution has no unexpected impact during the testing and implementation of the solution Stakeholders would also include “passive stakeholders” such as regulatory authorities or government who do not directly participate in the project but might need to be managed by the project to keep them satisfied
Project Manager	The Project Manager has overall responsibility for the success or failure of the project and is responsible for: Leading the development of an overall Project Charter and developing and implementing the project plan for the project Integrating the activities within the scope of the project into the overall project plan and ensuring that they are well aligned with the project's business objectives Tracking and reporting the status of all activities within the scope of the project Resolving issues or escalating any issues that cannot be resolved within the project manager's responsibility Taking full responsibility for the management of their assigned project(s) in accordance with any relevant processes, including: Monitoring and guiding each project through to completion, using specific techniques and procedures to establish the framework and structure of the project Keeping project stakeholders informed and involved in project decisions Anticipating changes required in project plans and processes and recommending alternative approaches if necessary Considering impacts to and from other projects and coordinating the planning and implementation of their project(s) with other project teams via project managers as necessary Taking the initiative to achieve value‐added results, within scope of the PM responsibility Leading the project team in taking accountability for work products and ensuring quality and timely delivery of end results
Scrum Master	The Scrum Master: Serves the team, not the reverse Is responsible for maintaining Scrum values and practices Facilitates most meetings Removes impediments Tracks metrics (i.e. burn‐down chart) Communicates with management (status, impediments) Shields the team from external interferences
Product Owner	The Product Owner: Creates and maintains the Product Backlog Prioritizes and sequences the backlog according to business value or ROI Assists with the elaboration of epics, themes, and features into user stories that are granular enough to be achieved in a single sprint Conveys the vision and goals at the beginning of every release and sprint Represents the customer; interfaces and engages with all customer stakeholders Participates in the daily Scrums, sprint planning meetings, and sprint reviews and retrospectives Inspects the product progress at the end of every sprint and has complete authority to accept or reject work done Can reorder and redefine the Product Backlog at the end of every sprint to reflect additions and changes that do not impact the macro‐level scope of the project. (Significant changes that impact the macro‐level scope may need to be approved by the project sponsor.) Terminates a sprint if it is determined that a drastic change in direction is required
Business Analyst	The Business Analyst (if required) is the primary resource for the day‐to‐day efforts of eliciting, analyzing, documenting, and validating the business requirements. The Business Analyst: Analyzes and scopes the project solution and works with Project Managers, Product Owner, and Business Sponsors to clarify the level and complexity of the business analysis effort needed for the project. (Note that on some projects, the Business Analyst may also play the role of the Product Owner.) Selects the appropriate elicitation technique to efficiently identify critical requirements and asks the right questions through the use of interviewing techniques developed specifically for business analysis elicitation Plans an approach for analyzing, categorizing, and managing requirements; determines the level of formality required and considers options for documenting and packaging requirements based on project type, priorities, and risks Analyzes and refines business and functional requirements from a business perspective, identifying any issues and questions that must be resolved and verifying that requirements are testable Builds strong relationships with project stakeholders and conducts effective requirements reviews to improve the quality of requirements deliverables Anticipates issues, thinking proactively and using critical‐thinking skills to plan stakeholder elicitation sessions May also perform the role of a Business Systems Analyst Analyzes and refines business and functional requirements from a systems perspective, identifying any issues and questions that must be resolved and verifying that requirements are testable

SUMMARY OF KEY POINTS

Overview of the Managed Agile Development Framework

The Managed Agile Development Framework is a project‐level framework that is intended to provide a balance of agility combined with some level of predictability and control. It is a hybrid Agile approach that is intended for companies that prefer a hybrid management approach over a pure Agile approach or are unable or not ready to move to a more complete top‐to‐bottom Agile model such as the Scaled Agile Framework.

It consists of two layers:

Macro‐level: 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.
Micro‐level: Within that outer envelope, the micro‐level framework utilizes a more flexible and iterative approach based on an Agile Scrum approach designed to be adaptive to user needs.

These two different levels will need to be synchronized with each other. This framework is intended to be customized and/or scaled up and down to fit particular projects.

Objectives of the Managed Agile Development Framework

The objectives that this framework is intended to achieve are a combination of the benefits of a traditional plan‐driven approach with the benefits of a more flexible and adaptive Agile approach.

Plan‐driven benefits
- A well‐defined process is consistently implemented and is somewhat predictable.
- High‐level milestones provide a framework for managing user expectations and integration with other activities outside the Agile development environment.
- Scope and cost of projects can be easily and effectively managed.
- There is improved capacity planning and resource allocation.
- The process provides a basis for learning and continuous improvement.
Agile benefits
- User satisfaction and operational business results
  - Users are engaged more collaboratively in the effort to define requirements.
  - There is earlier and more direct feedback on design alternatives from iterations and prototyping.
- Time‐to‐market
  - Requirements are ordered and grouped into releases and iterations.
  - Efforts can be more concurrent and less sequential where possible.
- Productivity and efficiency
  - Team is empowered to tailor the process to fit the project.
  - The process can be optimized for the project.
  - Unnecessary paperwork is reduced (more emphasis on direct team involvement and face‐to‐face communications).
  - The process is a collaborative, cross‐functional approach.