An Introduction to Agile

Overview
• The different types of project environments
• The different types of project lifecycles
• The four Agile values
• The twelve Agile clarifying principles
• Core Agile practices
• Agile and Lean frameworks
• Delivering in an Agile environment

Life Cycle Selection
Where does Agile fit in Product and Project Management?

Coincides with APG 3.1
Projects come in all shapes and sizes, and there are a
variety of ways to manage them.
Different organisational structures
Different lifecycles
Different management styles
Different sizes
Different customer needs
Different products or outputs
The list goes on…

An Introduction to Agile
There are different types of projects
You might have co-located teams or dispersed teams.
You might be governed by a supportive, controlling or directive PMO, or a functional manager.
Your sponsor or customer may want daily reports, or weekly reports.
You may have more than one customer group receiving the benefit of the project.
The project may be technically simple, or complex.
The project may have easily definable work, or high uncertainty work.

Definable Work Versus High Uncertainty Work
Project work ranges from definable work to high-uncertainty work.
• Definable: Clear procedures, similar to past projects
• e.g. Production of a car, appliance or home after the design is complete
• High-Uncertainty: High rates of changes, complexity and risk
• e.g. System or problem solving engineers, product designers, doctors, lawyers, teachers.

Definable Work Versus High Uncertainty WorkHighUncertaintyLowUncertainty
Requirements
Technical Challenges
Chaos
Simple
High UncertaintyLow Uncertainty
Complicated
Complex
Linear approaches work well here
Adaptive approaches work well here
Fundamentally risky

HighLow
FrequencyofDelivery
Degree of Change
HighLow
Predictive Iterative
Incremental Agile
No life cycle can be perfect for all projects.
Instead, each project finds a place on the
continuum that provides an optimum
balance.

Predictive life cycle
 The traditional “waterfall” approach, with the bulk of planning
done up front, then executing in a single, sequential process.
Iterative life cycle
 An approach that allows feedback for unfinished work to improve
and modify that work.
Incremental life cycle
 An approach that provides finished deliverables that the customer
may be able to use immediately.
Agile life cycle
 An approach that is both iterative and incremental, to refine work
items and deliver frequently

Characteristics of Life Cycles

Approach Requirements Activities Delivery Goal
Predictive Fixed
Performed once for
the entire project
Single delivery Manage cost
Iterative Dynamic
Repeated until
correct
Single delivery
Correctness of
solution
Incremental Dynamic
Performed once for
a given increment
Frequent smaller
deliveries
Speed
Agile Dynamic
Repeated until
correct
Frequent small
deliveries
Customer value
via frequent
deliveries and
feedback
Every project has characteristics around requirements, delivery, change and goals.
Understanding the different types of life cycle, you can choose the right one for the
circumstances of your project.

Predictive Life Cycles
Analyse Design Build Test Deliver
• Also known as “Waterfall” life cycles, predictive life cycles take advantage of high certainty around
requirements, a stable team, and low risk.
• As a result, project activities often execute in a straight forward, serial manner.
• As the team progresses through the detailed plan, they monitor and control changes that might affect
the Scope, Schedule, or Budget (cost).
• Projects typically do not deliver business value until the end of the project.

Iterative Life Cycles
• Iterative life cycles improve the product or result through successive prototypes or proofs of concept.
Each new prototype yields new stakeholder feedback and team insights.
• Teams may use time-boxing on a given iteration of two to four weeks to build, gather feedback, then put
that feedback into the next iteration.
• Useful when complexity is high, or scope is subject to change.
• Iterative life cycles take longer as they are optimised for learning, rather than speed of delivery.
Analyse
Analyse,
Design
Build,
Test
Deliver
Prototype Refine

Incremental Life Cycles
Analyse
Design
Build
Test
Deliver
Analyse
Design
Build
Test
Deliver
Analyse
Design
Build
Test
Deliver
• When businesses or initiatives cannot afford to wait for everything to be completed.
• In this situation the customer, business, or sponsor are willing to receive a subset of the overall solution
delivered in frequent small releases.
• You could provide a single feature at a time
• Increments are time-boxed in iterative methods, or pulled in flow based methods like Kanban.

Agile Life Cycles
Requirements
Analyse
Design
Build
Test
Requirements
Analyse
Design
Build
Test
Requirements
Analyse
Design
Build
Test
• In an Agile environment, the team expects requirements to change
• Iterative and Incremental approaches work together – to provide feedback for planning the
next iteration, and uncovering hidden or misunderstood requirements (using increments)
• For Kanban, or Flow based Agile, it is iterated for the number of features in the Work in
Progress (WIP) limit (on the board). The team pulls features from the backlog column on the
Kanban board based on their capacity.

Agile Life Cycles
Requirements
Analyse
Design
Build
Test
Requirements
Analyse
Design
Build
Test
Requirements
Analyse
Design
Build
Test
• Customer satisfaction increases with early and continuous delivery of value
• This incremental, functional deliverable that provides value is the primary measure of progress.

Agile Approach to Constraints
Scope
Time Cost
Quality
Scope
Time Cost
Quality
Fixed
Variable
Waterfall Agile

Hybrid Life Cycles
• Projects often combine elements of different life cycles in order to achieve their goals.
• A combination of predictive, iterative, incremental and agile approaches is a hybrid approach.
You might have:
• Largely agile, with some predictive
• Where you are integrating an external component developed by a
different vendor
• A single iteration might be required after their component is delivered
• Predominantly predictive, with some agile components
• Where you are delivering a straight forward project (a shed or patio), but
trialling a new roofing material.
• A combined predictive and agile approach
• A serial or linear project, where tasks are tracked using Kanban and daily
scrums are used for updating work.

Project Factors That Influence Tailoring
Project Factor Tailoring Options
Demand pattern: Steady or sporadic
Many teams find that using a cadence (like a regular time-box)
helps them demo, retrospect and take in new work. In addition,
teams can use flow-based agile with a cadence to bring
flexibility in acceptance of their work.
Rate of process improvement required
by the level of team experience
Retrospect more often and select improvements
The flow of work is often interrupted
by various delays or impediments
Consider making work visible using Kanban boards and
experimenting with limits for the various area of the
work process in order to improve flow.
The quality of product increments is
poor
Consider using the various test-driven-development
practices. This mistake proofing discipline makes it difficult
for defects to remain undetected.
More than one team is needed to build
a product
To scale from one to several agile teams with minimal
disruption, first learn about agile program management or
formal scaling frameworks. Then craft an approach that fits the
project context.
The project team members are
inexperienced in the use of agile
approaches
Consider starting by training the team members in the
fundamentals of the agile mindset and principles and an
overview of the approaches. If the team decides to use a
specific approach like Scrum or Kanban, provide a workshop on
that approach so they can learn how to use it.

The Agile Manifesto and Mindset
In 2001, a group of individuals, representing the most widely used
lightweight software development methodologies, agreed on a common
set of values and principles which became known as the Agile Manifesto.
The Agile Manifesto contains four statements of values:

The Agile Manifesto and Mindset
The Four Values
Individuals and interactions over Processes and Tools
Working software over Comprehensive documentation
Customer collaboration over Contract Negotiation
Responding to change over Following a plan
The Agile Manifesto argues that although the
concepts on the right have value, those on the
left have greater value.

The Twelve Clarifying
Principles

The Twelve Clarifying Principles
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer’s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.

4. Business people and developer must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a
development team is face to face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances quality.

10. Simplicity – the art of maximising the amount of work not done – is essential.

11. The best architectures, requirements, and designs emerge from self organising
teams.

12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behaviour accordingly.

Core Agile Practices
• Whole team approach
• Early and Frequent Feedback
• Daily stand-ups
• Retrospectives
• Release and Iteration Planning
• Collaborative User Story Creation
• Demonstrations / Reviews
• Continuous Integration
• Servant Leadership

Whole Team Approach
• The whole-team approach means involving everyone with the
knowledge and skills necessary to ensure project success.
• The team should be relatively small (successful teams have been
observed with as few as three people and as many as nine).
• Ideally, the whole team shares the same workspace (as co-location
strongly facilitates communication and interaction)
• Teams are often 100% dedicated to the delivery, because when
switching or multitasking people make more mistakes and
experience between 20% and 40% loss of productivity.

Whole Team Approach
• Agile teams are cross-functional, “generalising specialists”, or “T-
shaped” people, with one focus specialty and then a breadth of
experience across multiple skills.
• The team includes representatives for the Product Owner, the Team
Facilitator, and Cross Functional team members.

Whole Team Approach
• To overcome organisational silos, work with the various managers of
team members you need and have them dedicate the necessary
individuals to the cross-functional team.
• This creates the team synergy you need, and allows the organisation
to see how leveraging its people will optimise the product being
built.

Whole Team - Cross Functional Team Member
Role Description
Cross Functional Team Member
Cross functional teams consist of team members
with all the skills necessary to produce a working
product.
In software development, cross functional teams
are comprised of designers, developers, testers,
and any other required roles.
These teams deliver small, releasable products on
a regular basis.
The are critical because they can deliver finished
work in the shortest possible time, with higher
quality, without external dependencies.

Whole Team – Product Owner
Role Description
Product Owner
The Product Owner represents the customer, and generates,
maintains, and prioritizes the product backlog to ensure the
highest business value without creating waste.
This person is not the team lead.
They may work with stakeholders, customers and the teams
to define the product direction, and rank the work based on
its business value. Typically, product owners have a business
background and bring deep subject matter expertise to the
decisions.

Whole Team – Team Facilitator
Role Description
Team Facilitator
The Team Facilitator, or servant leader, can be
called a project manager, scrum master, project
team lead, team coach, or team facilitator.
The whole team approach is supported through
the daily stand-up meetings, facilitated by this
servant leader role.
All agile teams need servant leadership on the
team , and team members need to build their own
servant leadership skills of facilitation, coaching,
and removing blockers.

Whole Team Approach
• The use of a whole-team approach to product development is one
of the main benefits of Agile development. Its benefits include:
• Enhancing communication and collaboration within the team
• Enabling the various skill sets within the team to be leveraged
to the benefit of the project
• Making quality everyone’s responsibility
• The whole team is responsible for quality in Agile projects.

Early and Frequent Feedback
• Agile projects have short iterations enabling the project team to
receive early and continuous feedback on product quality
throughout the development lifecycle.
• By getting frequent customer feedback as the project progresses,
Agile teams can incorporate most new changes into the product,
and the development process.

Early and Frequent Feedback
• The benefits of early and frequent feedback include:
• Avoiding requirements misunderstandings, which may not have
been detected until later in the development cycle when they
are more expensive to fix.
• Clarifying customer feature requests, making them available for
customer use early. This way, the product better reflects what
the customer wants.
• Discovering (via continuous integration), isolating, and resolving
quality problems early. Providing information to the Agile team
regarding its productivity and ability to deliver.
• Promoting consistent project momentum.

Daily Standups
Teams use standups to micro-commit to each other, uncover and remove
blockers, and ensure work flows smoothly through the team.
• Timeboxed to 15 minutes
• Walk through the Kanban or task board
• Team facilitator / Scrum master or anyone in the team can facilitate
• Ideally in person, but can be virtual

Daily Stand-ups
In iteration-based agile, everyone answers the following questions in a round-
robin fashion:
• What did I complete since the last stand-up?
• What am I planning to complete between now and next stand-up?
• What are my impediments (or risks, blockers, problems)?
If problems do arise, take them “offline” – put them in
an issue parking lot and don’t try and solve them during
the stand-up.

Retrospectives
In Agile development, a retrospective is a meeting (often held
at the end of an iteration of around two weeks) to discuss
what was successful, what could be improved, and how to
incorporate the improvements and retain the successes in
future iterations.
• What worked well?
• What didn’t work well?
• What have I learned?
• What still puzzles me?

It meets Agile principle 12:
“At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behaviour accordingly.”
The Retrospective is seen as one of the most important practices because it helps
the team learn about and improve their process over time.

You can also hold Retrospectives at any other time, such as:
• When the team completes or ships something new
• When more than a few weeks have passed since the previous retrospective
• When the team appears to be stuck and completed work is not flowing
• When the team reaches any other milestone

Release and Iteration
Planning

Release and Iteration Planning
For Agile lifecycles, two kinds of planning occur, release planning and iteration planning.
In release planning, business representatives establish and prioritize
the user stories for the release, in collaboration with the team, refining
larger user stories into a collection of smaller stories.

Backlog Preparation
The Backlog is the ordered list of all the work, presented in “story” form, for a
team. The facilitator encourages the team to work in triads of a developer,
tester, and product owner/business analyst to discuss, write, and then place
enough stories into an iteration, and enough features for a first release.

In iteration planning, the team selects user stories from the
prioritized release backlog, elaborates the user stories,
performs a risk analysis for the user stories, and estimates
the work needed for each user story.
The number of stories selected is based on established team
velocity and the estimated size of the selected user stories.
“Velocity” is the rate a team can complete work (e.g. 16
medium sized cards per iteration)

Collaborative User
Story Creation

Collaborative User Story Creation
Poor specifications are often a major reason for
project failure.
In Agile development, user stories are written
with the developers, testers, and business
representatives, with frequent informal reviews
to ensure they are right.

A user story:
• Addresses both functional and non-functional
requirements
• Includes acceptance criteria for these characteristics,
which must be:
• Estimable, Small, and Testable
• See Behaviour Driven Development (Given, when,
then)

Three C’s of User Stories:
• Card:
• The physical media describing a user story. It identifies the
requirement, its criticality, expected development and test
duration, and the acceptance criteria for that story
• Conversation:
• Explains how the software will be used, evolving in
conversations with the product owner and developers.
• “As a” - “I want” - “So that I can” or Given, When, Then.
• Confirmation:
• The acceptance criteria, discussed in the conversation, are
used to confirm that the story is done.

Demonstrations / Reviews
As the team completes features, usually in the form of user stories, the
team periodically demonstrates the working product to the
customer/business and product owner.
Often occurs at the end of an iteration (2 weeks), or when enough
features have been completed into a set that is coherent.
Team members can get feedback that prevents them from heading in a
wrong direction.

Continuous Integration
and other execution practices

Continuous Integration
Delivery of a product increment requires reliable, working,
integrated software at the end of every sprint.
Continuous integration addresses this challenge by merging
all changes made to the software and integrating all
changed components regularly, at least once a day.
Configuration management, compilation, software build,
deployment, and testing are wrapped into a single,
automated, repeatable process. Since developers integrate
their work constantly, build constantly, and test constantly,
defects in code are detected more quickly.

Other execution practices
• Test at all levels
Applying end-to-end testing and unit testing (of an individual story or feature). Agile
teams have a preference for automated tests.
• Acceptance Test-Driven development (ATDD)
Creating end-to-end user acceptance tests by feature, as a team. These tests then
feature as reusable “regression tests” for overall functionality, once that feature goes
live.
• Test-Driven Development and Behaviour Driven Development
Writing automated tests before writing the product code helps people mistake-proof
the product. For non-software teams, consider prototyping with customers as a test.
• Spikes
Are timeboxed research or experiments. Useful for estimation, acceptance criteria
definition, or learning some critical technical or functional element.

Servant Leadership
Agile approaches emphasise servant leadership as a way to empower teams.
Servant leadership is the practice of leading through service to the team,
understanding and addressing the needs and development of the team
members to enable to highest performance possible.

Servant leaders approach project work in this order:
• Purpose
Work with the team to define the “why”
• People
Creating an environment where everyone can succeed
• Process
Look at the results over the process – if a team delivers value
often and reflects on the product and the process, it is agile.

Characteristics of a servant leader:
• Promoting self-awareness
• Listening
• Serving those on the team
• Helping people grow
• Coaching versus controlling
• Promoting safety, respect, trust
• Promoting the energy and intelligence of others

Servant leader responsibilities:
• Servant leaders facilitate
• Servant leaders remove organisational impediments
• Servant leaders pave the way for others’ contribution
• Educate stakeholders on agile, mentor the team and
encourage career development, help with technical project
management activities like quantitative risk analysis, build
bridges between external teams or groups.
A project manager in an agile environment uses servant
leadership.

Agile and Lean Frameworks
Scrum
XP
Kanban
Behaviour Driven
Development
Agile Unified Process
Dynamic Systems
Delivery Method
A single team management framework
“Sign-board” from the Toyota Production System
eXtreme Programming a software development method
Crystal
Scaled Agile
Framework
Core Methods
Many Auxiliary
Methods
Scrum of Scrums
Large Scale Scrum
Disciplined
Agile
Coincides with Agile Practice Guide 3.0
Feature Driven DevelopmentFDD

Scrum
Scrum Scrum is a single-team framework for managing product development.
The Scrum team consists of a:
• Product Owner
• The customer - responsible for maximising the value of the product
• Development Team
• Develops and tests the product. They are cross functional, self
organising and have all the roles needed to deliver the product.
• Scrum Master
• Responsible for ensuring the Scrum processes (i.e. stand-ups and
retrospectives), and coaches the team on removing blockers.

Scrum Events and Artefacts
Events
Sprint A time-boxed project “iteration” of two to four weeks
Sprint Planning
At the start of each sprint, the scrum team selects the highest
priority items.
Daily Scrum
A short (15 minute) stand-up meeting to walk through project tasks
(often on a Kanban board).
Sprint Review
The development team gives a demo on the product to the product
owner for sign-off (or rework or change)
Sprint Retrospective
A retrospective at the end of the sprint, to improve the way of
work for the next iteration.
Artefacts
Product Backlog The product owner manages a prioritized list of planned product
items which evolves from sprint to sprint.
Sprint Backlog The items selected in Sprint Planning for the upcoming sprint.
Increments The Increment is all the Product Backlog items completed during a
Sprint - a step toward the main vision or goal.

Kanban Kanban translates to “visual sign” or card, in Japanese.
Kanban
It is a form of Visual management from Lean Manufacturing, for monitoring Work in Progress, and enabling
“Pull” and “Flow”.
Here is an example of a
simplified Kanban board.
You could use any
columns you like to
represent your work.

Kanban
Kanban
• Pull is where people or teams “pull” work only when they are ready, instead of
work or inventory building up.
• Flow is where work flows effortlessly through the value chain, with no rework.
Kanban does not prescribe “iterations”, but works very well with them (i.e. Scrum).
It is helpful when you need:
• Increased efficiency
• Visibility of each task and ensuring it adds value.
• Team member focus
• Limited work in progress allows the team to focus on the current work.
• Variability in the workload
• Reduction of waste
• Transparency makes waste visible so it can be removed.

Kanban
Kanban
• Additionally, the board acts as an information radiator to anyone who sees it,
providing up-to-date information on the status of work to the team.
Defining Principles Core properties
Start with current state Visualise the workflow
Agree to pursue incremental,
evolutionary change
Limit work in progress
Respect the current process Manage Flow
Lead at all levels Enable “Pull”
Make process policies explicit
Implement feedback loops
Improve collaboratively

eXtreme
Programming
eXtreme Programming
XP is a software development method based on frequent cycles, known for popularising a holistic set of 12
primary practices (later expanded to other secondary practices).
XP Practice Area Primary Secondary
Organisational • Sit together
• Whole Team
• Informative workspace
• Real customer involvement
• Team continuity
• Sustainable pace
Technical • Pair programming
• Test-first programming
• Incremental design
• Shared code/collective ownership
• Documentation from code and tests
• Refactoring
Planning • User stories
• Weekly cycle
• Quarterly cycle
• Slack
• Root cause analysis
• Shrinking teams
• Pay per use
• Negotiated scope contract
• Daily stand-ups
Integration • 10-minute build
• Continuous Integration
• Test-first
• Single code base
• Incremental deployment
• Daily deployment

Feature Driven Development
Feature driven development is an iterative model for developing software. It focuses on:
• Developing an overall model
• Building a features list
• Plan by those features
• Design by those features, and;
• Build by those features.
Develop high-
level model
Develop
features list
Plan by
feature
Design by
feature
Build by
feature
Iterate after feedback

Feature driven development activities are supported by a core set of software engineering
best practices:
• Developing by Feature
• Feature teams
• Inspections
• Regular builds
• Visibility of progress and results
• Configuration management
• Individual class ownership
• Domain object modelling

Auxiliary Agile and Lean
Frameworks

Crystal
Crystal
Introduced by Alexander Cockburn in his book “Crystal Clear” and created at IBM in 1991,
Crystal is an agile framework focusing on individuals and their interactions, as opposed to
processes and tools (the first Agile principle). It is not a set process, but a guideline for
team collaboration and communication.
Three core beliefs:
Technologies change techniques
Cultures change norms
Distances change communication

Crystal
Crystal
Crystal is designed to scale, and realises that each project may require a slightly tailored
set of practices based on size and complexity.
Core Values Common Properties
People Frequent delivery
Interaction Reflective improvement
Community Close communication
Skills Personal safety
Talents Focus
Communications Easy access to expert users
Technical environment with automated
tests, configuration management and
frequent integration.

Crystal
Crystal
Sizing framework:
Life (L) L3 L10 L30 L80
Essential
Money (E)
E3 E10 E30 E80
Discretionary
money (D)
D3 D10 D30 D80
Comfort (C) C3 C10 C30 C80
Number of people
involved +- 20% 1 - 4 6-20 20-40 5-100
Crystal clear Crystal yellow Crystal orange Crystal red
Crystal is designed to scale, and realises that each project may require a slightly tailored
set of practices based on size and complexity.

Dynamic Systems Delivery Method
Dynamic Systems Delivery
Method
DSDM was designed to add more rigour to the rising iterative methods of the
1990s. It is most known for its emphasis on constraint-driven delivery, which
sets Cost, Quality and Time at the beginning, then uses formalised prioritisation
of scope to meet those constraints.

Dynamic Systems Delivery Method
Dynamic Systems Delivery
Method
Eight principles guide the use of the DSDM framework:
1. Focus on the business need
2. Deliver on time
3. Collaborate
4. Never compromise quality
5. Build incrementally from firm foundations
6. Develop iteratively
7. Communicate continuously and early
8. Demonstrate control (use appropriate techniques, prioritisation of
scope, etc)

The intent of AUP is to perform more iterative cycles across seven key
disciplines, and incorporate the associated feedback before formal delivery.
Discipline within a release Principles guiding the disciplines
Model The team knows what it’s doing
Implementation Simplicity
Test Agility
Deployment Focus on high-value activities
Configuration management Tool independence
Project Management Tailoring to fit
Environment Situationally specific

Behaviour Driven Development
Behaviour-driven development allows a developer to focus on testing the code
based on the expected behaviour of the software. It is a method of writing user
stories.
Specific behaviour-driven development frameworks can be used to define
acceptance criteria based on the given/when/then format:
• Given some initial context,
• When an event occurs,
• Then ensure some outcomes.
Behaviour Driven Development

Scaling Frameworks
Scrum of Scrums
SoS
Large Scale Scrum
LeSS
Scaled Agile Framework
SAFe
Enterprise Scrum
Disciplined Agile
DA

Scrum of Scrums
Scrum of Scrums
Similar to Projects, Programs and Portfolios, a “Scrum of Scrums” is conducted
when two or more teams of three to nine members need to co-ordinate their
work. A representative from each team attends a meeting with other team
representative around three times a week.
A representative from each team attends a meeting with other
team representative around three times a week, to report on:
• Completed work
• Next set of work
• Current blockers
• Potential upcoming blockers
The goal is to ensure teams are coordinating work and
removing blockers across teams.

Scrum of Scrums
Scrum of Scrums
Scrum of Scrum
of Scrums
Scrum of Scrums
Scrum Teams
Notice how this aligns with the view of Projects, Programs and Portfolios in the PMBOK
Guide.

Scaled Agile Framework (SAFe)
Scaled Agile Framework
SAFe focuses on a detailing practices, roles and activities at the portfolio,
program and project levels, and focuses on organising the enterprise around
value streams that provide value to the customer.
Principles:
• Take an economic view
• Apply systems thinking
• Assume variability, preserve options
• Build incrementally with fast, integrated learning cycles
• Base milestones on objective evaluation of working systems
• Visualise and limit work in progress, reduce batch sizes, manage
queue lengths
• Apply the cadence for synchronising with cross-domain planning
• Unlock the intrinsic motivation of knowledge workers
• Decentralise decision making

Large Scale Scrum (LeSS)
Large Scale Scrum
LeSS aims to organise several development teams toward a common goal by
extending the Scrum method across teams.
Similarities of LeSS and Scrum LeSS Techniques Added to Scrum
One single product backlog
Sprint planning is more formally divided
into two parts – what and how.
One definition of done for all teams Organic cross-team coordination
One potentially shippable product
increment at the end of each sprint
Overall cross-team refinement
One product owner
Overall retrospective focused on cross-
team improvements
Complete, cross-functional teams
One sprint

Enterprise Scrum
Enterprise Scrum
Enterprise Scrum is a framework designed to apply the Scrum method at an
organisational level, not just a single product development effort.
It advises leaders to:
• Extend the use of Scrum across all aspects of the organisation
• Generalise the Scrum techniques to apply easily at those various levels
• Scale the Scrum method with supplemental techniques as necessary

Disciplined Agile (DA)
Disciplined Agile
Disciplined Agile is a process decision framework that blends various Agile
techniques based on the following principles:
People First Enumerating roles and organisation elements at various levels
Learning-oriented Encouraging collaborative improvement
Full delivery life-cycle Promoting several fit-for-purpose life cycles
Goal-driven Tailoring processes to achieve specific outcomes
Enterprise awareness Offering guidance on cross-departmental governance
Scalable Covering multiple dimensions of program complexity

Delivering in an
Agile Environment

Delivering in an Agile Environment
Charter the Project and the Team
A typical project using the Project Management Body of Knowledge (PMBOK) will initiate with a Project
Charter.
In addition using Agile, cross functional teams initiate with a Team Charter.
The Team Charter Includes:
• The project vision or purpose
• A clear set of working agreements
It answers these questions:
• Why are we doing this project?
• Who benefits and how?
• What does “done” mean for the project?
• How are we going to work together?
A servant leader may facilitate the chartering process.

Charter the Project and the Team
A team charter is also a “social contract”. It can include:
• 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 time-box and WIP limits.
• Ground rules, such as one person talking in a meeting,
• Group norms, such as how the team treats meeting times.
And other behaviours the team wants to work with or address.

Agile Teams Measure Results
Agile favours value-based measurements instead of predictive measurements (like earned value
management).
By measuring what is done and replanning at each iteration by iteration, there is less room for error
and more room to correct course.

Agile Teams Measure Results
Some iteration-based projects use burndown or burnup charts to show where the project is going
versus where it was planned.
Many agile teams use story points to estimate effort.
0
10
20
30
40
50
60
1 2 3 4 5 6 7 8 9 10
Burn up chart
(Story Points Done)
Points Planned Actual
0
10
20
30
40
50
60
1 2 3 4 5 6 7 8 9 10
Burn down chart
(Story Points Remaining)
Points Planned Actual

Organisational Considerations for Project Agility
Evolving the Organisation
When implementing a new hybrid or agile approach, it is
recommended to undertake the work incrementally.
Treat the change as an agile project, with its own backlog of
changes that could be introduced by the team based on perceived
value.
Each of the changes can be treated as an experiment, tested for a
short period of time to determine suitability or the need for further
refinement.
Use Kanban boards to track progress, showing new approaches in
use as “done”, and things being tried as “in progress”.

Organisational Considerations for Project Agility
Evolving the Organisation
You can assess the current culture and its readiness for agile, and tailor a
solution to suit. One model you can use is below, but others exists and the main
idea is to work with and understand the team. Often an agile approach will
enable both ends of the priorities below.
Exploration Execution
Speed Stability
Quantity Quality
Flexibility Predictability
(Other factors)

An Introduction to Agile

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to An Introduction to Agile

Similar to An Introduction to Agile (20)

More from DavidMcLachlan1

More from DavidMcLachlan1 (20)

Recently uploaded

Recently uploaded (20)

An Introduction to Agile