Module 5

Implementing Agile:
Delivering in an Agile
Environment

Amr Elkhodary
Module Objectives
• Charter the Project and the Team
• Agile Project Challenges
Charter the Project
• An agile project charter answers these questions:

• Why are we doing this project? This is the project vision.

• Who benefits and how? This may be part of the project vision and/or project purpose.

• What does “done” mean for the project? These are the project’s release criteria.

• How are we going to work together? This explains the intended flow of work.
Charter the Team
• Here are some chartering ideas for team members to use as a basis for their social contract:

• Team values, such as sustainable pace and core hours

• Working agreements, such as what “ready” means so the team can take in work.

• what “done” means so the team can judge completeness consistently.

• Respecting the timebox; or the use of work-in-process limits.

• Ground rules, such as one person talking in a meeting.

• Group norms, such as how the team treats meeting times.

 Agile Pain Points + Solutions
Pain Point Troubleshooting Possibilities

Unclear purpose or mission for the team Agile chartering for purpose—vision, mission, and mission tests

Unclear working agreements for the Agile chartering for alignment—values, principles, and working
team Agreements

Unclear team context Agile chartering for context—boundaries, committed assets, and
prospective analysis

Unclear requirements Help sponsors and stakeholders craft a product vision. Consider
building a product roadmap using specification by example, user
story mapping, and impact mapping. Bring the team and product
owner together to clarify the expectations and value of a
requirement. Progressively decompose roadmap into backlog of
smaller, concrete requirements.
 Agile Pain Points + Solutions
Pain Point
Poor user experience
Inaccurate estimation
Unclear work assignments or work
progress
Team struggles with obstacles
Troubleshooting Possibilities
User experience design practices included in the development
team involve users early and often.
Reduce story size by splitting stories. Use relative estimation with
the entire team to estimate. Consider agile modeling or spiking
to understand what the story is
Help the team learn that they self-manage their work. Consider
Kanban boards to see the .ow of work. Consider a daily standup
to walk the board and see what work is where.
A servant leader can help clear these obstacles. If the team
doesn’t know the options they have, consider a coach.
Sometimes, the team needs to escalate stories the team
or servant leader has not been able to remove.
 Agile Pain Points + Solutions
Pain Point
Work delays/overruns due to
insufficiently refined product backlog
items
Defects
Work is not complete
Technical debt (degraded code quality)
Troubleshooting Possibilities
Product owner and team workshop stories together. Create
a definition of ready for the stories. Consider splitting stories
to use smaller stories
Consider the technical practices that work for the environment.
Some possibilities are: pair work, collective product ownership,
pervasive testing (test-driven and automated testing
approaches) and a robust definition of done.
Team defines definition of done for stories including acceptance
criteria. Also add release criteria for projects.
Refactoring, agile modeling, pervasive testing, automated code
quality analysis, definition of done
 Agile Pain Points + Solutions
Pain Point
Too much product complexity
Slow or no improvement in the
teamwork process
Too much upfront work leading to rework
False starts, wasted efforts
Troubleshooting Possibilities
For software and non-software encourage the team always to be
thinking “What is the simplest thing that would work?” and apply
the agile principle of “Simplicity--the art of maximizing the
amount of work not done”. These help reduce complexity
Capture no more than three items to improve at each
retrospective. Ask the servant leader to help the team learn
how to integrate those items.
Instead of much upfront work, consider team spikes to learn.
In addition, measure the WIP during the beginning of the project
and see what the team’s options are to deliver value instead
of designs. Shorten iterations and create a robust denition
of done.
Ask the product owner to become an integral part of the team.
 Agile Pain Points + Solutions
Pain Point
Inefficiently ordered product backlog
items
Rush/wait uneven flow of work
Impossible stakeholder demands
Unexpected or unforeseen delays
Siloed teams, instead of cross-functional
teams
Troubleshooting Possibilities
Rank with value including cost of delay divided by duration
(CD3) and other value models
Plan to the team’s capacity and not more. Ask people to stop
multitasking and be dedicated to one team. Ask the team
to work as pairs, a swarm, or mob to even out the capabilities
across the entire team.
Servant leadership to work with this stakeholder (and possibly
product owner).
Ask the team to check in more often, use kanban boards to see
the •
ow of work and work in progress limits to understand the
impact of the demands on the team or product. Also track
impediments and impediment removal on an impediment board
Ask the people who are part of projects to self-organize as
cross-functional teams. Use servant leadership skills to help the
managers understand why agile needs cross-functional teams.
 Module 6
Organizational
Consideration for
Project Agility
Module Objectives
• Organizational Change Management
• Organizational Culture
• Procurement and Contracts
• Agile and the Project Management Office (PMO)
• Organizational Structure
Organizational Change Management
➢Drivers for Change Management:
• Changes associated with accelerated delivery:

• Agile approaches emphasize delivering project outputs early and often.

• However, the receiving organization may not be fully prepared to incorporate those outputs
at an increased pace.

• Accelerating delivery will test the organization’s ability to accommodate that delivery.
Organizational Change Management
➢Drivers for Change Management:
• Changes associated with agile approaches:

• Organizations just beginning to use agile approaches also experience high degrees of change.

• Higher degrees of collaboration may require more frequent handoffs between teams,
departments, or vendors.

• Decomposing work into iterative prototypes involves rework that could be viewed negatively.
Leaders should consider change management techniques to address the hurdles of
transitioning to the use of agile approaches.
Organizational Change Management
➢Readiness for Change:
• Executive management’s willingness to change;

• Organization’s willingness to shift the way it views, reviews, and assesses employees;

• Centralization or decentralization of project, program, and portfolio management functions;

• Focus on short-term budgeting and metrics versus long-term goals; and

• Talent management maturity and capabilities

Organizational Culture
• Creating an Environment of Safety

• Assessing Culture : a project leader initiates a conversation about organizational priorities with
stakeholders, team members, and senior management. Those priorities are then recorded as
positions on a sliding scale between two extremes. The results are then used to find agile
techniques that best fit with those priorities.
Procurement and Contracts

• The agile contract is different from traditional contracts in

• Scope : detailed description is not present in the agile contract because of frequent changes.
• Costs
• amount of value to be delivered are somewhat tricky to calculate up front.

• agile methods are flexible which allows for changing requirements and priority levels.

• Agile contracting based on trust between parties and mutual collaboration, Projects incur more
risk when those involved in the contract take the perspective of winners vs. losers.
Procurement and Contracts - techniques
• Multi-tiered structure:
• Rather than formalizing an entire contracting relationship in a single document, project parties can
achieve more flexibility by describing different aspects in different documents.

• Mostly fixed items (e.g., warranties, arbitration) can be locked in a master agreement

• all parties list items subject to change (e.g., services rates, product descriptions) in a schedule of
services. The contract can reference them in the master services agreement.

• Finally, more dynamic items such as scope, schedule, and budget can be formalized in a lightweight
statement of work.
Procurement and Contracts - techniques
• Emphasize value delivered:

• milestones and payment terms can be structured based on value-driven deliverables in order to
enhance the project’s agility.

• Fixed-price increments:

• Rather than lock an entire project scope and budget into a single agreement, a project can
decompose the scope into fixed-price micro-deliverables, such as user stories.
Procurement and Contracts - techniques
• Not-to-exceed time and materials: (Similar to Dynamic scope option)

• Customers suffer unwanted risk from a traditional time and materials approach.

• One alternative is to limit the overall budget to a fixed amount. This allows the customer to incorporate new
ideas and innovations into the project not originally planned.

• When customers want to incorporate new ideas, they will have to manage to a given capacity, replacing
original work with new work (dynamic scope)

• Additional contingency hours could be planned into the maximum budget if considered helpful.
Procurement and Contracts - techniques
• Graduated Time and Material: The hourly rate is based on
• finishing early (highest rate)
• finishing on time (second highest rate)
• finishing late (lowest rate).
• For example, the rates are graduated as $120/hour, $100/hour, and $90/hour.
Agile and the Project Management Office (PMO)
• An Agile PMO is Value-Driven

• An Agile PMO is Multidisciplinary: Some organizations transformed their PMOs into agile centers of
excellence that provide services as:

• Developing and implementing standards. Provide templates for user stories, test cases, Provide agile tools and
educate supporting groups on iterative development concepts.

• Developing personnel through training and mentoring.

• Multi-project management. Coordinate between agile teams by communicating between projects.

• Facilitating organizational learning.

• Recruiting, selecting, and evaluating team leaders. Develop guidelines for interviewing agile practitioners.

• Managing stakeholders. Provide product owner training, guidance on acceptance testing.

Organizational Structure
• The structure of an organization key characteristics:

• Geography: Geographically distributed and dispersed project organizations may find several challenges
impeding their work on any project. Project leaders and regional managers may have alternative or
even competing goals. Additionally, cultural differences, language barriers, and lower visibility can slow
down productivity.

• Fortunately, the use of agile approaches can encourage more collaboration and confidence than would
otherwise exist.

• Functionalized structures: Some organizations are structured on a spectrum ranging from highly
projectized to matrixed to highly functionalized. Projects with highly functionalized structures may find
general resistance to collaboration across its organization.
Organizational Structure
• Size of project deliverable: Reducing the size of a project deliverable will motivate more frequent handoffs
across departments, and thus more frequent interactions and a faster flow of value across the organization.

• Allocation of people to projects: Another approach is to ask for a single person from each department to be
temporarily, yet fully allocated, to the highest priority project.

• Procurement-heavy organizations: Some organizations choose to implement projects primarily through

vendors. Although project goals may be clear, vendors have a responsibility to look after their own financial
viability. Moreover, once vendors complete their obligations and leave the engagement, the associated
project knowledge goes with them.
Additional Agile
Methods
Additional Agile Methods

• Dynamic Systems Development Method (DSDM)

• Crystal Methods
• Lean Development
• Kanban
• Just-In-Time (JIT)
• Feature-Driven Development (FDD)
 Dynamic Systems Development Method (DSDM)
• Rather than fixing the amount of functionality in a product and then adjusting time and resources
to obtain that functionality,
• A better approach is to fix time and resources and then adjust the amount of functionality as
necessary.
• The DSDM –Originated in UK- is defined as an agile project management and delivery framework.
This methodology is designed for tailoring and can be used with traditional methods such as
PRINCE2.

• DSDM supports the use of proven agile techniques including:

• Facilitated workshops
• Modeling and iterative development
• MoSCoW prioritization scheme
• Time-boxing
Dynamic Systems Development Method (DSDM)
DSDM is based on nine principles:

1. Active user involvement is essential.

2. DSDM teams must be empowered to make decisions.
3. The focus is on frequent delivery of products.
4. Fitness for business purpose is essential for acceptance of deliverables.
5. Iterative and incremental development is necessary to converge on an accurate business solution.
6. All changes during development are reversible.
7. Requirements are baselined at a high level.
8. Testing is integrated throughout the life cycle.
9. This method believes in the Pareto principle (80–20 rule): 80% of an application can be delivered
in 20% of the time it would take to deliver 100% of the application.
 Crystal Methods
• Crystal is an agile methodology for software development. It places focus on people over
processes, to empower teams to find their own solutions for each project rather than being
constricted with rigid methodologies
• Unlike more fixed frameworks like scrum, crystal recognizes that different teams will perform
differently depending on team size, criticality, and priority of the project and encourages users to
adapt the framework for their individual situation.

• For example, a small team can keep itself aligned with regular communication, so it doesn't need
much status reporting and documentation, whereas a large team is likely to get out-of-sync and
would benefit from a more structured approach.

• These are categorized by color, according to the number of people in the project;
• Crystal clear - Teams with less than 8 people
• Crystal yellow - Teams with between 10 and 20 people
• Crystal orange - Teams with between 20-50 people
• Crystal red - Teams with between 50-100 people
 LEAN
• Lean development was originally derived from Lean manufacturing based on the Toyota
Production System (TPS) at Toyota Motor Corporation
• The method’s goal is to deliver the maximum amount of value to the customer in the shortest
amount of time while providing the highest quality and value to the customer, people, and society
• The way that the Lean development method intends to meet its goals is to attain continuous flow,
isolate interruptions and activities that don’t add value, and by consistently decreasing or
eliminating obstacles.

• There are seven principles behind Lean:

1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity
7. See the whole
KANBAN
 Just In Time (JIT)

• The just-in-time refers to producing:

“only what is needed, when it is needed, and in the amount needed.”

• In order to be effective when producing a large number of cars, the requirement is to create a
detailed production plan that includes parts.

• The idea to supply only what is needed, when it is needed, and in the amount needed,
characterizes a method that can eliminate waste, discrepancies, and irrational requirements. This
will result in overall value-added productivity levels.
 Feature-Driven Development (FDD)
• Feature Driven Development (FDD) is an agile framework that, as its name suggests, organizes
software development around making progress on features.
• Features in the FDD context, though, are not necessarily product features in the commonly
understood sense. They are, rather, more akin to user stories in Scrum. In other words, “complete
the login process” might be considered a feature in the Feature Driven Development (FDD)
methodology.

• There are five iterative phases in the life cycle for FDD:
1. Develop an overall model: An object model plus notes
2. Build a features list: A list of features grouped into sets and subject area
3. Plan by feature: A development plan; class owners; feature set owners
4. Design by feature: A design package
5. Build by feature: Complete client functionality
Questions ?
• You are managing a project in which you intend to respond to high levels of
change and ongoing stakeholder involvement. The most suitable project life cycle
for your project is the:

• A. Predictive life cycle.

• B. Adaptive life cycle.
• C. Waterfall life cycle.
• D. Configuration management life cycle.
• You are managing a project in which you intend to respond to high levels of
change and ongoing stakeholder involvement. The most suitable project life cycle
for your project is the:

• A. Predictive life cycle.

• B. Adaptive life cycle.
• C. Waterfall life cycle.
• D. Configuration management life cycle.
• Iterative, agile, and adaptive approaches track, review, and regulate progress and
performance by maintaining:

• A. A detailed to-do list

• B. A backlog.
• C. A work breakdown structure.
• D. Work packages.
• Iterative, agile, and adaptive approaches track, review, and regulate progress and
performance by maintaining:

• A. A detailed to-do list

• B. A backlog.
• C. A work breakdown structure.
• D. Work packages.
• life cycles develop a set of high-level plans for the initial requirements and
progressively elaborate requirements to an appropriate level of detail for the
planning cycle.

• A. Predictive
• B. Adaptive
• C. Plan-driven
• D. Program
• life cycles develop a set of high-level plans for the initial requirements and
progressively elaborate requirements to an appropriate level of detail for the
planning cycle.

• A. Predictive
• B. Adaptive
• C. Plan-driven
• D. Program
• A project life cycle that is iterative and incremental.

• A. Waterfall.
• B. Adaptive life cycle.
• C. Predictive life cycle.
• D. Progressive development.
• A project life cycle that is iterative and incremental.

• A. Waterfall.
• B. Adaptive life cycle.
• C. Predictive life cycle.
• D. Progressive development.
• An adaptive project life cycle in which the deliverable is produced through a
series of iterations that successively add functionality within a predetermined
time frame. The deliverable contains the necessary and sufficient capability to be
considered complete only after the final iteration.

• A. Incremental life cycle.

• B. Waterfall life cycle.
• C. Critical path life cycle.
• D. Program life cycle.
• An adaptive project life cycle in which the deliverable is produced through a
series of iterations that successively add functionality within a predetermined
time frame. The deliverable contains the necessary and sufficient capability to be
considered complete only after the final iteration.

• A. Incremental life cycle.

• B. Waterfall life cycle.
• C. Critical path life cycle.
• D. Program life cycle.
• An adaptive project life cycle in which the deliverable matures through a series of
repeated cycles. The deliverable contains the necessary and sufficient capability
to be considered complete at the end of each cycle. Each repeated cycle further
enhances the capability of the deliverable.

• A. Project life cycle.

• B. Iterative life cycle.
• C. Product life cycle.
• D. Business analysis life cycle.
• An adaptive project life cycle in which the deliverable matures through a series of
repeated cycles. The deliverable contains the necessary and sufficient capability
to be considered complete at the end of each cycle. Each repeated cycle further
enhances the capability of the deliverable.

• A. Project life cycle.

• B. Iterative life cycle.
• C. Product life cycle.
• D. Business analysis life cycle.
• A form of project life cycle in which the project scope, time, and cost
are determined in the early phases of the life cycle.

• A. Program life cycle.

• B. Product life cycle.
• C. Predictive life cycle.
• D. Adaptive life cycle .
• A form of project life cycle in which the project scope, time, and cost
are determined in the early phases of the life cycle.

• A. Program life cycle.

• B. Product life cycle.
• C. Predictive life cycle.
• D. Adaptive life cycle .
Amr Elkhodary