The core Agile practices described in the document include whole team approach, early and frequent feedback, daily stand-ups, retrospectives, release and iteration planning, collaborative user story creation, demonstrations/reviews, and continuous integration. Some key benefits are enhancing communication, leveraging various skill sets, making quality everyone's responsibility, avoiding requirements misunderstandings, and promoting consistent project momentum.

1. Core Agile Practices

2. Core Agile Practices
Coincides with APG 4.0
• 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

3. Whole Team Approach

4. Coincides with APG 4.3
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.
Core Agile Practices

5. Coincides with APG 4.3
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.
Core Agile Practices

6. Coincides with APG 4.3
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.
Core Agile Practices

7. Coincides with APG 4.3
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.
Core Agile Practices

8. Coincides with APG 4.3
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.
Core Agile Practices

9. Coincides with APG 4.3
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.
Core Agile Practices

10. Coincides with APG 4.3
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.
Core Agile Practices

11. Early and Frequent
Feedback

12. Core Agile Practices
Coincides with APG 2.2
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.

13. Core Agile Practices
Coincides with APG 2.2
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.

14. Daily Standups

15. Core Agile Practices
Coincides with APG 5.2
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

16. Core Agile Practices
Coincides with APG 5.2
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.

17. Retrospectives

18. Core Agile Practices
Coincides with APG 5.2
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?

19. Core Agile Practices
Coincides with APG 5.2
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.

20. Core Agile Practices
Coincides with APG 5.2
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

21. Release and Iteration
Planning

22. Core Agile Practices
Coincides with APG 5.2
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.

23. Release and Iteration Planning
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.
Core Agile Practices
Coincides with APG 5.2

24. Release and Iteration Planning
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)
Core Agile Practices
Coincides with APG 5.2

25. Collaborative User
Story Creation

26. 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.
Core Agile Practices
Coincides with APG 5.2

27. Collaborative User Story Creation
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)
Core Agile Practices
Coincides with APG 5.2

28. Collaborative User Story Creation
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.
Core Agile Practices
Coincides with APG 5.2

29. Demonstrations / Reviews

30. Core Agile Practices
Coincides with APG 5.2
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.

31. Continuous Integration
and other execution practices

32. 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.
Core Agile Practices
Coincides with APG 5.2

33. 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.
Core Agile Practices
Coincides with APG 5.2

34. Servant Leadership

35. 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.
Core Agile Practices
Coincides with APG 5.2

36. 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.
Core Agile Practices
Coincides with APG 5.2

37. 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
Core Agile Practices
Coincides with APG 5.2

38. 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.
Core Agile Practices
Coincides with APG 5.2