AGILE

FUNDAMENTALS
Workbook

1
Copyright 2019
 Australian Institute of Management Education and Training
All rights reserved
Version: 1.0
Date Modified: 26/07/2019
No part of this publication may be reproduced, stored in a retrieval system or transmitted in
any form or by any means, electronic, mechanical, photocopying, recording or otherwise
without the prior written permission of Australian Institute of Management Education and
Training.
Disclaimer:
AIM does not invite reliance upon, nor accept responsibility for, the information it provides.
AIM makes every effort to provide a high quality service. However, neither AIM, nor the
providers of data, gives any guarantees, undertakings or warranties concerning the accuracy,
completeness or up-to-date nature of the information provided. Users should confirm
information from another source if it is of sufficient importance for them to do so.

www.aim.com.au

2
 Agile Fundamentals: Workbook

CONTENTS

INTRODUCTION ....................................................................................................................... 2
Learning Outcomes .............................................................................................................. 2

WHAT IS AGILE?....................................................................................................................... 3
Origins of Agile ...................................................................................................................... 3
The Manifesto for Agile Software Development ................................................................. 4
Do Agile or Be Agile? ............................................................................................................ 6
Applying Agile Outside of Software Development ............................................................. 9

AGILE SUCCESS ENABLERS................................................................................................... 10

Agile Teams ........................................................................................................................ 12
Communication and Collaboration ................................................................................... 14
A Collaborative Workspace ................................................................................................ 16
Have a Shared Vision.......................................................................................................... 18
Understand the Customer ................................................................................................. 20
Learn and Adapt ................................................................................................................. 23

AGILE PLANNING ................................................................................................................... 25

Value Based Delivery ......................................................................................................... 25
Prioritisation........................................................................................................................ 27
Estimation ........................................................................................................................... 29
Planning and Scheduling ................................................................................................... 31
Ensuring Quality ................................................................................................................. 33

AGILE DELIVERY .................................................................................................................... 34

Work in Progress ................................................................................................................ 35
Status Reporting ................................................................................................................. 37
Dealing with Changes ......................................................................................................... 39
Agile – Always Learning ..................................................................................................... 41

LEARNING JOURNAL ............................................................................................................. 43

GLOSSARY ..............................................................................................................................44

REFERENCES ..........................................................................................................................46

3
 Agile Fundamentals: Workbook

Introduction

Originally starting as a set of management practices focused on software development, Agile

is now being applied across all organisational functions and teams. This rapid expansion and
appreciation comes down to one thing: Agile frameworks and practices are an effective way
for organisations to leverage and master continuous change. Agile will allow you and your
organisation to thrive in a business world that is constantly shifting in its complexity.
This introductory Agile course explores the Agile mindset, values, principles, and
foundational concepts.

Learning Outcomes
• Define the origins of Agile and its values, principles and mindset
• Identify the key success factors for Agile projects
• Understand Agile team roles and responsibilities
• Facilitate collaborative approaches to define project vision and identify customer
needs
• Apply Agile project planning and adaptation techniques
• Monitor Agile projects and manage value-driven delivery

2
Agile Fundamentals: Workbook

What is Agile?

Origins of Agile
“Agile is the ability to create and respond to change. It is a way of dealing with and
ultimately succeeding in, an uncertain and turbulent world”
Agile Alliance, 2019

In today’s fast-paced everchanging environment, organisations everywhere are looking for

ways to work more efficiently, respond to change and deliver greater value to customers.
Many of these organisations are turning to Agile; a way of working that originated in the
software development industry.
The term Agile was coined by the creators of the ‘Manifesto for Agile Software Development’
to describe working in a way that was adaptive and able to respond to the change that so
often occurred during software development.
However, many people were working in an agile manner well before the Manifesto was
developed. Software developers and software development organisations were looking for
more effective ways of working. They started exploring the ideas of collaboration between
developers and business functions, short delivery cycles that focused on delivering
something of value quickly and frequent face-to-face to conversations between team
members, to name a few. Over time these approaches were formalised into frameworks such
as Scrum, Crystal and Extreme Programming that are commonly associated with Agile today.
The Manifesto for Agile Software Development came about 2001 when a group of 17 thought
leaders who were already using these approaches came together. Their intention was to
discuss the commonalities and differences in their approaches. They did indeed find common
ground (along with many differences) and collectively settled on the term Agile to describe
their connected ideas. They also agreed on a set of common values that underpinned each of
their approaches, consequently creating the Manifesto for Agile Software Development.
Since the Manifesto was originally documented, agile frameworks and practices have
continued to be developed to meet the changing needs of users, for example LeSS (Large
Scale Scrum) and SAFe (Scaled Agile Framework). This itself is an example of Agile in
practice, learning and adapting to respond to change. And it’s expected that over time new
frameworks will continue to be developed as new users adopt the Agile values into their ways
of working.

3
 Agile Fundamentals: Workbook

The Manifesto for Agile Software Development

We are uncovering better ways of developing

software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

Kent Beck James Grenning Robert C. Martin

Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick

© 2001, the above authors this declaration may be freely copied in any form, but only in its
entirety through this notice.

4
Agile Fundamentals: Workbook

Activity: The Agile Manifesto – Values

Work with your group to describe how each value could manifest in your workplace.

Individuals and interactions over processes Working software over comprehensive

and tools documentation

Customer collaboration over contract Responding to change over following a plan

negotiation

5
 Agile Fundamentals: Workbook

Do Agile or Be Agile?
One of the biggest challenges for people and organisations in adopting Agile is the change in
mindset that is required. Many organisations and teams are quick to adopt Agile processes
such as stand up meetings, sprints, Kanban boards and retrospectives in the hope that it will
deliver projects more efficiently and with greater quality results. And whilst they may
experience some efficiency gains, they never realise the full potential of Agile or worse, they
end up exactly where they started albeit with some new jargon.
To fully realise the benefits of Agile, a mindset shift needs to occur. When talking mindset,
you are looking at the attitudes and beliefs that shape your behaviour. When talking
organisational mindset, you are looking at culture; the attitudes and beliefs that shape
behaviour when no one is watching.
Attitudes and beliefs in turn are built on principles. Principles are the general rules or
propositions that form the foundations of a how a person reasons. Recognising this, the
creators of the Agile Manifesto came up with 12 principles that form the foundation for
reasoning from an Agile perspective – hence creating the Agile mindset.

Principles behind the Agile Manifesto

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 developers 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 agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing
teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behaviour accordingly.
Source: https://agilemanifesto.org/principles.html

6
Agile Fundamentals: Workbook

Activity: Applying the agile mindset

Review each of the scenarios and referring to the Agile Manifesto values and principles
determine if the person is responding from an agile mindset or not. Explain why.

Asha is a Project Manager for a large retail organisation. She has been asked to manage a
new initiative to enhance the in-store experience of shoppers to encourage them back into
the store and to combat competitors and online shopping. For the kick off meeting, Asha has
arranged an online conference call for all the stakeholders to dial into from their desks. Some
stakeholders are interstate, while others are located in the same building, but on different
floors.

Peter is a key stakeholder for a customer service re-development project. The project has
been running smoothly for a few months and the solution is scheduled to go live in the next
few weeks. At the last meeting, Jiang from the contact centre discovered that the solution
didn’t have a way for team members to record or update notes against each customer call,
which was a major requirement that the solution couldn’t be deployed without. The solution
development team indicated that adding this requirement would take a week or so to
implement and test, which would set back the expected release date. Peter argued that the
requirement should have been known earlier and was concerned about the change in the
release date.

Kate was managing a compliance project to enhance the invoicing processes in line with the
latest federal legislation. The team has been developing the updates to the finance system
for the past 8 weeks. Danny, the Accounts Receivable Supervisor, is now scheduled to review
the system changes to ensure they meet the requirements for the new laws. The first time
Danny logged into the system, he noticed that the main menu had been modified making it
hard to navigate.

Raj is a HR Manager working on a project to create a new employee health and wellness
program. Each week, he attends a demonstration meeting where the project team walk
through the work that has been completed in the previous week. Sometimes there are some
improvements that can be made, which Raj discusses with the team. Most of the time, Raj is
delighted by how well the team have managed to implement the requirements and he feels
confident that the project will deliver the benefits envisioned.

7
 Agile Fundamentals: Workbook

Activity: The Agile Mindset

Work with your group to identify the characteristics of an Agile mindset.

Which characteristics do you need to further develop in order to build your own agile
mindset?

8
Agile Fundamentals: Workbook

Applying Agile Outside of Software Development

Agile may have originated in the software development industry however today it can be
found in all types of organisations across all types of functions.
In some organisations it’s an organic movement; one department adopts Agile practices
(often the IT department) to run their projects and have great success with it. Another
department sees this success and in turn decides to trial Agile in their work practices. You
can now see Agile methods being used in departments such as Learning and Development,
Human Resources, Legal and Compliance, Marketing, etc.
For others it’s a whole of organisation transformation, where the leadership team makes a
decision to reorganise the whole organisation to adopt Agile. You can see this today in
Australia as large banks, telecommunication companies, retailers, publishers and insurers
are all “going Agile”.

Discussion: The Agile Movement

What has been your experience with Agile in your current workplace? How has it come about
that you are attending this course?

What benefits can you see in using Agile for non-software development work?

Can you see any organisations or specific work functions where Agile wouldn’t work?

9
 Agile Fundamentals: Workbook

Agile Success Enablers

Before getting into what enablers are required to make Agile a success in your work
environment, it’s important to look at how Agile presents in practice and how it differs to
other approaches.
Agile is based on delivering products (and projects) using an incremental development
approach. Incremental development means “that each successive version of a product is
usable, and each builds upon the previous version by adding user-visible functionality” (Agile
Alliance, 2019).

Example: Incremental development

Melanie wanted to set up a co-working space in a regional town. The vision was to deliver a
space where people could work, connect with others and grow businesses together. This is a
large undertaking and Melanie recognises the need to start earning income quickly to fund
the project. So, for the first increment Melanie sources an office space in town, adds second
hand furniture and ensures there is high speed internet available. This enables Melanie to
start renting out desk space, earning income and building awareness of her project.
In the next increment Melanie kits out an office kitchen so that people using the co-working
space don’t need to leave to get a coffee or have some lunch. It also creates a social space
for people to connect.
As the co-working space starts to get regular users, Melanie adds two meeting rooms and
furnishes them for different size groups. These rooms give users of the space a place to
conduct client meetings, deliver presentations and conduct training.
With more regular users, Melanie starts to get feedback that the office can get quite noisy and
some users have asked for a semi-private space where they can make phone calls. Melanie
decides to set up designated break out spaces that can be used for conversations and phone
calls. She purchases some comfy couches and sets up partitions to create soundproofing
around certain areas of the office.
With the co-working space fully established Melanie starts to host regular networking
functions and short training sessions for the space’s regular users after hours. These events
help users connect and upskill to grow their businesses.

Incremental development aims to deliver something of usable value to the customer upon
completion of each increment. This differs from activity-based planning where deliverables
are based on tasks. Whilst each task may build on the previous, they aren’t delivering a
product that a customer can use. To enable this most Agile projects are structured around
iterations. Iterations are a fixed period of time (also known as a timebox) during which project
work takes place. These periods are short—between one to four weeks—and sequenced
consecutively (Agile Alliance, 2019).

10
Agile Fundamentals: Workbook

Contrast this to how projects are often run in an organisation:

The value to project teams of working in iterations includes:

• Customer feedback can be gained early and continuously throughout the project. This
means if the customer changes their mind, learns something new or identifies a
critical issue it can be addressed in the next iteration, rather than finding out at the
end of the project.
• Changes to the operating environment (e.g. competitor activities, new technology,
changing business priorities) can be responded to in a timely manner to ensure that
the team deliver the required business outcomes.
• As teams work together throughout the project, they will find better ways of working.
These can be actioned in the iteration of the current project, rather than waiting until
the next project where they can implement their lessons learned.

11
 Agile Fundamentals: Workbook

Agile Teams
Core to the Agile way of working is people and how they collaborate through teams to get
work done. Agile teams differ from traditional structures, where teams are made up of people
who do a functionally similar role, for example Marketing, Human Resources, Compliance, IT.
In these traditional teams, members may contribute to a project or multiple projects from the
perspective of their area of expertise and then return to their ‘day job’.
Effective Agile teams in contrast share three key characteristics:
• Cross-functional
• Dedicated to the project
• Self-organising

Cross-functional
Agile teams are structured so that they have all of the skills required to complete the work
end-to-end. This can mean that on your next Agile team you could find yourself working with
people who are developers, lawyers, copywriters, customer experience specialists and
instructional designers. These people will each bring a unique skill set to the team however
their roles are not defined by their areas of specialisation. Rather, tasks are completed by
whoever has the appropriate skillset. So, you may find yourself on an Agile team where a
lawyer is testing the functionality of a new piece of software because they have a great eye
for detail.

Dedicated to the project

Team members on an Agile team are working on a specific project on a full-time basis. This
means the team can focus on delivering value and completing work with no competing
demands on their time from business-as-usual tasks.

Self-organising
Agile teams are self-organising. This means that they self-organise to get tasks completed
between themselves and track their own progress. The team works together to prioritise
work, estimate how long the work will take and identify who will complete the work. This
doesn’t mean there is no place for a manager or leader in Agile teams, it means that the role
of the manager/leader is focused on making sure the team has everything they need to
achieve their objectives. This includes making sure the team has the right skills, that
roadblocks are removed as they arise and that the team has access to the resources they
need.
This is the difference between self-organising and self-managing teams. Self-managing
teams would also handle the management tasks such as recruiting team members,
managing performance and accessing resources (Calabrese, 2018)

12
Agile Fundamentals: Workbook

Video: Agile way of working at ING Belgium

Watch the video showing how teams are organised in an Agile organisation. Note anything
that resonates with you.

Source: https://youtu.be/TaV-d7eKWFc
Operating as a self-organising and cross functional team requires team members to
collaborate in a way that can be unfamiliar to many. In a command and control environment,
the manager delegates work, sets deadlines and holds team members to account. In an Agile
environment, the team takes on these responsibilities. This requires open, honest
conversations between team members. It requires team members to be disciplined in
delivering work as agreed, it also requires self-awareness and courage to be able to ask for
help as needed.

Discussion: Building Agile Teams

What cultural factors do you think need to be present for an agile team to be successful?

13
 Agile Fundamentals: Workbook

Communication and Collaboration

It’s the first value in the Manifesto that establishes the next key enabler.
Individuals and interactions over tools and processes
Effective products and projects that deliver value for their customers do so because of the
individuals on the team and how they collaborate and communicate; not because of the tools
and project management framework they use.
If you put together a team of skilled individuals that can’t or won’t communicate and
collaborate effectively, it’s highly unlikely that the project will deliver on all its desired
outcomes; even if you give them training on the latest Agile framework and provided fancy
project management tools to use. In teams like this, team members will be working to their
own agenda. They won’t share useful information or question the decisions that are being
made, even if they have concerns. This leads to rework, poor decision-making and ultimately
low team morale.
On the other hand, if you put together a team of skilled individuals who can collaborate and
communicate, hold each other accountable, are willing to discuss differing views and who
trust each other; its highly likely that the project will be successful; regardless of the tools
available to them or the project management methodology that they use.
Many people, when hearing that increasing team communication is necessary for effective
collaboration, instantly envisage more structured team meetings, more all-in group emails
and long-winded group chats. However, in effective Agile teams the focus is on more informal
conversations; in particular face-to-face conversations. The types of conversations that occur
because you overhear a team mate sighing in exasperation because they are stuck on a piece
of work and you ask them ‘What’s up?’. Or when two people are in discussion next to you
about a particular product feature on the project and ask for your opinion.
Face-to-face conversations are considered to be the most context-rich method of
communicating. In the Agile principles it actually states “The most efficient and effective
method of conveying information to and within a development team is face-to-face
conversation.” This is because of all of the additional information that is conveyed when
talking to someone who is in front of you and the option for quick question and answers.
Face-to-face you don’t just receive the words of the message; you can interpret the tone, the
body-language and the surrounding environment which may be influencing the message. You
can ask questions and get an immediate response. You can add to your message as you gain
new information. Consider having the same conversation via email. You might send an email
asking a quick question that you know the receiver knows the answer to, the receiver only
receives the words of the message – sure you might add some emojis for emotional context
but it’s not quite the same. You then need to wait for a response. This could be 5 minutes or
could be 5 hours. Once you finally receive a response you realise that you left out a piece of
important information that could change the answer so you send another email and then you
wait.
There are potential costs to the project in these types of situations. You might decide that
instead of waiting for a response to your email you’ll make an ‘executive decision’ and it turns
out to be wrong. This can lead to potential rework and corrective costs. Alternatively, you

14
Agile Fundamentals: Workbook

might decide to wait for a response and it takes 5 hours, in those 5 hours you are not
producing work costing the project 5 paid hours with nothing to show for it.

Discussion: Addressing team communication barriers

List the barriers that distributed teams can face in an Agile environment.

What are some practical strategies that teams can put in place to overcome these barriers?

15
 Agile Fundamentals: Workbook

A Collaborative Workspace
With a way of working that requires easy communication and constant collaboration, the
working environment of the Agile team is a key success enabler. Truly Agile teams need a
work environment that facilitates four elements:
• Impromptu conversations, assistance seeking and collaboratively working together
on specific elements of the project.
• The visual display of tools such as user stories, progress boards, customer journeys,
etc
• Stand up daily meetings – these usually need to occur around the visual displays
mentioned above.
• Larger meetings such as project planning, demonstrations and retrospectives that
require the participation of additional stakeholders.
In an office environment this translates into a dedicated space where the entire team is
located for the duration of the project. If the team is distributed across multiple locations
then technology needs to be in place that enables the above elements.

Video: 360° Agile way of working by ING

Watch the short video showing how ING have set up their offices to facilitate agile working
and make note of any interesting ideas.

https://www.youtube.com/watch?v=cxGXQxsaPy8

16
Agile Fundamentals: Workbook

Case study: The Annual Team Conference

KeyPalm Utilities is a state-wide organisation with over 700 employees. In recent years
KeyPalm has undergone a number of changes as they struggle to stay profitable in the wake
of new competition and government regulations. One of the biggest changes was the
appointment of a new CEO – Leslie Green. Leslie has been given some big strategic targets by
the Board and although achievable, Leslie knows that it will only be possible with the support
of a motivated and engaged workforce. Leslie is a big believer that if you take care of your
employees, they will take care of your customers.
To kickstart this process Leslie has decided to change the theme of the annual team
conference to be focused on employee wellbeing and engagement.
In the past the conference has been viewed as an inconvenient mandatory day away from
usual duties. It always followed the same format – the CEO gets up and talks about the
strategic direction for the organisation, gives team members a not so subtle hint that they
need to work harder, then departments split off for team planning sessions, perhaps with a
cheesy team-building activity or two. The day always concludes with a motivational speaker
that most employees enjoy (although last year’s speaker was diabolical – after a 20 minutes
summary of their resume they spent the rest of the time implying that the only way to achieve
success was to work 12-hour days and take work home from you). Most employees who have
attended the conference in the past agree that the cakes at morning tea and the free lunch
are the highlights of the conference.
Leslie has heard this feedback and decided to do things differently. This year the conference
will be created by a team of employees from across the business and Leslie will be the
project sponsor to help clear any obstacles. The team will have representatives from Human
Resources, Sales, Operations, Finance, IT, Customer Service, Compliance and Marketing. The
team will be seconded from their usual roles for a period of 3 weeks and the conference
project will be their sole focus.
Leslie is keen to leave the majority of the details up to the team however does have a set of
requirements for the team to work towards:
• The conference theme is employee wellbeing and motivation
• The strategic objectives of the conference are to increase employee engagement,
reduce absenteeism and reduce attrition
• The conference has a one-day duration
• The conference needs to have a mix of keynote and breakout sessions on topics
related to theme of wellbeing and motivation
• There needs to be an exhibition space where external businesses and internal groups
can host booths that team members can explore between sessions
• Leslie would like 15 minutes to deliver a keynote presentation to all employees at
some point during the day.
• The project needs to be managed in accordance with the values and principles
espoused in the Agile Manifesto.

17
 Agile Fundamentals: Workbook

Have a Shared Vision

Despite the common myth that Agile projects involve no planning, one of the first things done
to kick off an Agile project is a collaborative vision planning session. The vision planning
session ideally involves the whole team and sets about establishing what success will look
like for the project. It sets out:
• The product vision – an overarching desired outcome for the customer that everyone
on the project is working towards.
• The objectives and expected return on investment – the specific business metrics that
the project will be measured against.
• The project constraints – all projects have three constraints—scope, schedule and
cost—identify what is fixed and what is flexible when faced with change.
• The risks involved – what could unfavourably impact the project and how you can
mitigate it.
Depending on the size of the project, the planning may span several sessions or be done in
just one. What is key in creating a shared vision is that it is a collaborative effort that involves
the whole project team. A collaborative approach at the beginning helps with creating team
member buy-in and ensuring that everyone is starting the project on the same page.

Creating the Product Vision

All Agile projects start with a product vision. It provides direction for the whole project. As
and when future planning activities take place, they will cascade from the vision. As and
when changes to plans are necessary, the vision will guide the actions taken.
In talking about the ‘product’, you are looking at the desired output at the end of the project.
All projects produce products, whether or not they are for an external customer (Highsmith,
2009). Your product may be a new app, an improved customer service experience, your
wedding, a car or an employee onboarding process. By creating a vision that focuses on the
end product, you are in turn focusing attention on the customer who will use the product.
The real benefits in creating a product vision as a team are the discussions and debates that
are generated. There may already be a product brief created as part of a product roadmap
and the team can use this as their starting point. In this session team members can clarify
their understanding of the product, it’s intended benefits, why it’s being created and the
intended customer. This shared understanding creates the foundations for the project
moving forward.
There are a number of collaborative techniques that can be used to create a shared
understanding in the team. One of the most common is to create a product vision box.

18
Agile Fundamentals: Workbook

Product vision box

The product vision box was developed by Bill Shackelford (Highsmith,
2009) initially for software products however it can be applied to all
products. In this activity team members create the packaging (or box) for
the final product. Think to the last packaged product you bought, it could
be a DVD, mobile phone, breakfast cereal or the latest anti-aging beauty
product. The packaging gave you a clear understanding of what the
product was, what it could do for you and why you should buy it. This
encapsulates the product vision.
To create a product vision box, the project team breaks into small groups and
each group designs the front and back of the product box. On the front is a
product name, graphic and three to four selling points. On the back is a
detailed description of the features and any specific use requirements. The
groups then present their boxes back to the other teams creating an
opportunity to discuss differences and together create a shared
understanding of what the final vision for the product is (Highsmith, 2009).

Activity: Create a Project Vision

Work in your project teams to create a product vision for the Annual Team Conference. Take a
photo of the completed box for your records and use the space below to take notes on the
process.

19
 Agile Fundamentals: Workbook

Understand the Customer

An important enabler for a successful Agile project is the continuous involvement of the
customer throughout the project or product development.

Who is the Customer?

Agile project teams can have multiple customers, and each of these customers have different
needs. Customers include:
• Sponsor: This is typically a senior leader in the organisation who provides the team
with the vision for the project and is responsible for authorising the resources for the
project.
• Buyer: This is the person who acquires the product or outputs of the project. This
customer could also be the sponsor or the user.
• User: The end user of the product. It’s important to recognise that there are often
different categories of end users each with their own needs. By segmenting end users
into like-groups you can better understand their specific needs.
For example:
Wedsale develops software that streamlines common business processes. Within Wedsale is
a sponsor who commissions the development of a payroll system that can be used by
organisations to manage payroll and employee entitlements.
A Human Resources Manager from ILDA Resources purchases Wedsale’s payroll software to
manage payroll within their organisation. The Human Resources Manager is the buyer.
The employees of ILDA Resources are the end users of the product as they will be using the
system on a regular basis. However, the end users can be segmented into groups as their
needs will be slightly different. All employees need a system that is easy to log in to and
allows them to view their payslips, leave balances, employee details and to apply for leave.
Managers are also end users and will need to be able to view their team’s employment
details, approve leave and generate reports on leave balances. The Finance team is also a
customer as they need to be able to gain a company-wide view of payroll and outstanding
employee entitlements so that they can be included in financial reports.
The project or product team that are developing the Wedsale payroll system need to consider
all of these users and their needs in their work.
It’s often not possible to have the end users as part of the project team (particularly if they
are external to the organisation) so they are typically represented by a Product Owner. This is
an internal business role who acts as a liaison between all customers and the project team.
The focus of the Product Owner is understanding customer needs, seeking continuous
feedback and communicating this to the project team. The Product Owner is the person who
will prioritise the features to be delivered based on what is most valuable to the customer.

20
Agile Fundamentals: Workbook

Gaining Customer Feedback

Central to the design of Agile projects is short feedback loops. Iterations are relatively short
(in comparison to linear project lifecycles) with scheduled checkpoints to gain customer
feedback on the value that has been delivered thus far. This keeps Agile teams focused on
delivering value to the customer and enables them to change course early if new or altered
requirements are uncovered (Goodman, 2018).
In addition to gaining customer feedback at the end of each iteration, effective Agile teams
look to shorten the feedback loop even more. They are seeking out opportunities to actively
involve the customer throughout the development phases as well. They recognise the risks of
not enough customer involvement. These include:
• End products and outcomes that don’t provide value to the customer
• Missed opportunities to maximise the amount of value provided to the customer
• Time lost as project iterations are spent reworking previous deliverables because
customer input wasn’t available.
The Agile principle “Business people and developers must work together daily throughout the
project” stresses the importance of constant collaboration with customers (with ‘business
people’ being the customer). Strategies to facilitate this include:
• Include the relevant Product Owner and/or end user in project meetings (including
planning and daily stand ups).
• If you have a Product Owner, have them sit with the project team for the duration of
the project if the team are co-located.
• If you have access to the end user invite them to work with the project team
throughout the iteration and include them in problem solving and decision making.
• Require the project team to regularly explain their activities to the customer and ‘ask
does this work?’
• Provide access to prototypes and examples throughout the iteration and provide easy
feedback mechanisms.

21
 Agile Fundamentals: Workbook

Activity: Who are your customers?

Working in your project team, identify your customers and end users for the annual team
conference. For each customer and user identify their needs for the conference and the value
they can gain from it.

Plan how you will create short feedback loops throughout the project, including during the
iterations, to ensure you are maximising value to your customers and users.

22
Agile Fundamentals: Workbook

Learn and Adapt

The only thing you can be certain about in the workplace and when working on projects is
that there is going to be a level of uncertainty in regards to what you are delivering and that
things are going to change as you go.
This is where the true value of Agile is for project teams and organisations. Agile provides a
flexible framework that keeps teams focused on customer outcomes and yet enables the
team to use the most effective ways of working to achieve them. Even if it means adapting
ways of working throughout the project.
It is to be expected that as team members work together on a project that they will develop
new knowledge and new skills that could benefit the end design. It is to be expected that as
customers start to see their initial list of requirements be built out, that they will identify new
requirements or tweaks. For projects that span over a certain period of time, you can almost
guarantee that someone, somewhere, will develop new technology or make a new discovery
that will have an impact on your intended outcomes or how you achieve them.
In linear project management approaches, customer feedback typically happens towards the
end of the project. This makes it challenging (and potentially expensive) to implement the
feedback received. When this happens there is often push-back from the team, who have
worked so hard following the initial scope of the project. They’ve delivered what was
requested, why should they have to do more work because someone’s changed their mind?
The Agile approach recognises that customers quite often don’t know what they don’t know.
A customer may think they know what they want and then when they see a prototype, they
realise it doesn’t quite hit the mark. By releasing iterations of a product early, whether it be a
mock up, a prototype or rough and ready draft, you are helping the customer define their
needs. And then you can adapt your approach accordingly.
Just as important as regularly reviewing and confirming customer needs, is reviewing how
the team is working as well. In the linear project management approaches the team doesn’t
review their own ways of working until the end of the project – this is the lessons learned
review. Which means any potential improvements can’t benefit the current project, only
future projects—if they are shared and remembered that is.
In Agile projects, teams typically conduct a review at the end of each iteration; this is often
known as retrospective. In this session team members discuss:
• How well they worked together as a team.
• Did they achieve the intended outcomes for the iteration, if not why not?
• What worked well.
• What they can do differently in the next iteration.
This is an important determining factor in truly Agile teams. Whilst they might start with an
Agile framework or process like SCRUM, Kanban or SAFe, they will over time adapt the
framework to work for them. They will in fact, create their own Agile methodology and that
methodology will continue to evolve to suit their needs.

23
 Agile Fundamentals: Workbook

Plus/Delta
Plus/Delta is a simple technique that can be used to run retrospectives at the end of each
iteration. Plus is used to indicate all of the things that worked well during the iteration and
delta signifies things the team can change.
To conduct a Plus/Delta, draw two columns and label one ‘Plus’ and the other ‘Delta’. Ask
team members to share their pluses and deltas in an action phrase format that are specific.
So instead of the delta “the stand up meetings took too long” use “limit stand up meetings to
15 minutes.” Once all of the pluses and deltas have been named assign an owner
accountability for each action and ask for their commitment to managing it in the next
iteration.

Activity: Learning as a team

In your project team reflect on how well you are collaborating this far into the project. What
can you do as a team to optimise your performance for the remainder of the project?
Conduct a Plus/Delta with your team.

Plus Delta

24
Agile Fundamentals: Workbook

Agile Planning

In Agile the act of planning is more important than the plan itself. Planning is a continuous
activity throughout the project rather than a phase at the beginning. The plans developed will
start out deliberately vague and as the project unfolds, they become more precise the closer
the project is to completion.
Agile planning is designed with future changes in mind. It is to be expected that as a project
progresses teams will gain new knowledge that could benefit the end design. It is to be
expected that the customer, as they see the end outcome come to life, will have changes to
be made. As such as these events occur the plan is adapted, whilst always keeping customer
value in mind.

Value Based Delivery

Before delving into the activities that make up Agile planning it’s important to first
understand what it is you are planning. In traditional project management, planning focuses
on breaking down work into functional tasks to be completed. For example, if you are part of
a project team that is working on the redesign of the customer waiting room, you would
potentially break the project into tasks such as design the room layout, source and furnish
the room, implement customer wait time tracking etc. With Agile you plan customer features,
that is, something of value to the customer. So, in the waiting room example you would break
the project into features that represent value to the customer. For example, a comfortable
seat to sit in whilst waiting.
In Agile these features are often usually stories. They are written in a way that is easily
understood by both the customer and technical specialists. Importantly each feature needs
to deliver something of use and value to the customer. Agile planning in a nutshell, focuses
on prioritising and scheduling the delivery of these features.

25
 Agile Fundamentals: Workbook

Activity: Feature breakdown

Work with your project team to break the staff conference down into value-based customer
features that you can base your planning around.

26
Agile Fundamentals: Workbook

Prioritisation
Given the opportunity, customers and Product Owners will produce a list of required features
a mile-long and then deem them all important. However, project teams only have a finite
amount of time and resources to dedicate to the project, so the ability to prioritise features is
critical. Prioritisation happens at all levels of planning. Features need to be prioritised for
release, features need to be prioritised for each iteration and tasks need to be prioritised on a
daily basis. Prioritisation for release planning and iteration planning is led by the Product
Owner however it needs to include the whole project team.
There are a number of factors that influence how features are prioritised and the weight
attributed to each factor will depend on the organisation. One organisation may choose to
prioritise all of the low risk items for delivery, whilst another will prioritise those items that
present the biggest opportunities for learning that can inform future development. Factors
considered include:
• How much value a customer gains from the feature
• How much value (make money/save money) the business gains from the feature
• How much risk is removed by delivering those features
• What dependencies there are between features
• What features represent opportunities for learning that can inform future
development
• How easy the features are to implement (Cohn, 2007).

MoSCoW Technique
There are a number of techniques that teams can use to prioritise features and stories. A
simple, yet effective technique is MoSCoW. MoSCoW requires the Product Owner and project
team to assign each feature to one of four categories.
1. Must have
• These are the features and requirements a product needs in order to be worth
releasing. The Agile Business Consortium (2019) defines these as meeting one of the
following:
- No point in delivering on target date without this
- Not legal or safe without it
- Can’t deliver a viable solution without it.
2. Should have
• These are the features that are important but the product can function without them.
Usually these are the features that a workaround (no matter how manual) exists for.
3. Could have
• These are the bells and whistles of the product. If these are left out there is less
impact in comparison to if you left out a ‘Should have’.

27
 Agile Fundamentals: Workbook

4. Won’t have this time

• These are the features that the team agree won’t be released this
release/iteration/project.

Activity: Prioritising the conference features

In your project team, work through the features you identified previously and prioritise them
using the MoSCoW technique.

Must have Should have

Could have Won’t have this time

28
Agile Fundamentals: Workbook

Estimation
When it comes to planning releases and iterations it’s helpful to know how long a particular
feature or story will take to complete. This is where estimation comes in to Agile. Estimation
is the process the team uses to figure out the effort required to complete a piece of work.
This enables teams to plan the amount of work that is to be completed in an iteration or
release, appropriately.
Using the term ‘estimation’ for this stage of planning is acknowledging that when calculating
duration for the completion of work it is just an approximate number. It recognises that the
actual duration may change based on any number of factors.
In an Agile team estimates are created by the team rather than a specific individual. This is
because at this stage teams are not certain who will do the work for each feature, so the
estimate needs to allow for this. Creating estimates collaboratively also allows the team to
challenge each other on their estimates, as a result requiring individuals to clarify and justify
their estimate or to change it.

Estimation techniques
When estimating how long it will take to deliver a feature or story, most people will instantly
jump to calculating hours and days. However, this can be fraught with danger. When the
Product Owner asks how long you will take to deliver a feature and you respond ‘three days’,
you typically mean three days of uninterrupted work. Yet in most workplaces you will have
other tasks vying for your attention. There are emails to be read, meetings to attend,
customer enquiries to respond to. Your three days soon extends to five days. So, even if you
spent the equivalent of three days work time on the task, in the view of the project schedule
you are now two days behind.
An alternative to estimating duration in days is to estimate effort in points and do so on a
relative scale. For example, you may know that one task will take twice as much effort as
another task so you would attribute it twice as many points. This method was developed by
Mike Cohn and is known as story points.
To use story points the team agrees on a scale, such as the Fibonacci scale and based on the
effort required for each user story (requirement) assigns points. So, using Fibonacci scale of
1, 2, 3, 5, 8 the stories requiring the smallest amount of effort are assigned a 1. The stories
that require the most effort are assigned an 8. Stories are all ranked relative to each other on
the scale based on the effort required.
A popular collaborative method for determining story points is Planning Poker. In Planning
Poker each team member is given a deck of cards with the numbers from the scale. The team
will then take a story from the pile and read it out to the group. Team members have an
opportunity to ask questions about the story and clarify the requirements. Once questions
have been answered each team member will calculate an estimate individually before
everyone holds up a card that reflects their estimate. If all team members select the same
card then that becomes the estimate. If there are differences of opinion a brief discussion will
occur to help the team reach consensus.

29
 Agile Fundamentals: Workbook

Once each story has points assigned the team can schedule based on their past performance.
So, if in previous iterations they were able to complete 15 story points, for the next iteration
user stories that total 15 points will be scheduled. This is known as velocity.

Activity: Planning Poker

Your facilitator will give you each a deck of cards with the available points. As a team conduct
a game of planning poker to estimate the effort required for each of your stories.

30
Agile Fundamentals: Workbook

Planning and Scheduling

There are multiple levels of planning in an agile project. Agile teams typically focus on three
planning levels (Cohn, 2007):
• Release planning
- A release is a group of relatable features that can be deployed and used by the
customer. A release plan determines what features or user stories will be
developed or built within each release. Release planning happens at the start of
the project after the Product Owner has gathered the user requirements and
business priorities. Like all Agile planning it is expected that the release plan will
be adapted as the project progresses.
• Iteration planning
- Iteration planning occurs at the start of each iteration and involves the whole
project team. This planning results in a more-detailed plan that breaks the user-
stories into tasks and estimates how long each task will take to complete.
• Daily planning
- Daily planning consists of daily stand up meetings where the day’s activities are
planned. In the meetings teams will discuss the tasks they are working on that
day, what they have finished and any assistance they need to complete their
tasks.
To plan your releases and iterations you start with the product vision and business outcomes
that were agreed in the vision planning session. These are guidelines that all decisions need
to be made against. Ask the question; ‘If we do this, will it move us closer to achieving the
product vision?’
If it hasn’t already been selected, the team should agree the length of each iteration (ideally
between one to four weeks). With the iteration length selected you can determine the team’s
velocity, that is, how many story points it can complete within the iteration.
As projects typically have more features than time to deliver them in, you need to use your
estimates and story prioritisation to determine what will be included in each iteration within
the release.
At this stage you will have a release plan that can be used to guide the team’s activities. In
keeping with the Agile value of ‘Responding to change over following a plan’, it is important
that the plan is revisited regularly and updated as required.

31
 Agile Fundamentals: Workbook

Activity: Prepare the conference plan

Your project team has been advised that it has three weeks to pull together the conference. Those three weeks consist of three iterations
each a week long. Previous projects of a similar scale have had a team velocity of 20 points. Work together to schedule your delivery of
features.

Iteration One Iteration Two Iteration Three

32
 Agile Fundamentals: Workbook

Ensuring Quality
In Agile projects quality is defined from two aspects, extrinsic quality and intrinsic quality
(Highsmith, 2009). Both need to exist for the product to be considered of quality.
Extrinsic quality is the customers’ perception of quality. Does the customer gain value in the
immediate term? This after all is the entire concept behind Agile, every requirement and
feature that the project team delivers are linked to the product vision and the customer value
proposition. Therefore, even if a delivered product is correct functioning and free from
defects, if it doesn’t provide the customer with value, it won’t be a quality product in the
customers’ eyes. They won’t be willing to pay for it.
Intrinsic quality relates to the technical quality of the product, which is where people’s minds
instantly go to when talking about quality. Does the product function reliably, is it free from
defects? For Agile products, intrinsic quality is about enabling the continuous delivery of
value over time. That is, is the product adaptable and responsive to being built on so that it
can meet future needs?
Intrinsic quality and the adaptability of the product being built is especially important in the
context of incremental development. If a project team takes short cuts in one iteration of the
project and delivers a product that cannot be easily adapted or that contains faults, it creates
a technical debt. The team will then need to address this debt down the track, creating delays
and rework.
With such an emphasis on quality, it comes as no surprise that in Agile teams’ quality is the
responsibility of all team members. Even if there are team members with a quality assurance
or testing background, each team member has accountability for delivering and reviewing
products for both extrinsic and intrinsic quality.

Activity: Delivering a quality conference

Work with your project team to identify both intrinsic and extrinsic quality indicators for the
conference.

Intrinsic Extrinsic

33
Agile Fundamentals: Workbook

Agile Delivery

Once an iteration has commenced teams now need to engage in daily planning activities.
Daily planning typically consists of a stand up meeting for the project team. The meeting is
capped at 15 minutes and team members remain standing for the duration to keep it short.
These meetings typically follow a variant of the following three question format for each team
member:
• What have you completed since the last meeting?
• What do you plan to complete by the next meeting?
• What is getting in your way? (Agile Alliance, 2019)
The intent of these questions is to focus on what has been completed and plan for the day’s
activities. It is important that these meetings don’t become a series of status updates from
the team. Rather each team member is to briefly talk through their planned activities for the
day so that other team members can use the information in planning their day. If a
collaboration opportunity arises team members should mention it in the meeting and agree
to a conversation afterwards. Similarly if a team member asks for help with something, the
team will quickly decide who can help and the issue is addressed after the meeting wraps up
(Gilhooly, 2019).
Daily planning activities like stand up team meetings help by:
• Letting team members know what each person is working on to prevent duplication of
effort and/or working on conflicting activities
• Highlighting opportunities for collaboration
• Creating a forum to ask for assistance for the team
• Forcing team members to think ahead and plan their day.
Another major benefit of daily stand up meetings, is that in stating what work they will
complete today, each team member is making a commitment to the team. They know that
they will have to face them again tomorrow and let them know whether or not they met that
commitment.

34
 Agile Fundamentals: Workbook

Work in Progress
In many workplaces today, it’s quite common to see teams (and individuals) that claim to be
very busy, yet don’t seem to actually produce a lot of finished results. The cause of this
phenomenon is often having excessive amounts of work that has been started and not yet
finished, known as work in progress in Agile terms. For example a Learning and Development
team has drafted a privacy training program, it’s now waiting for a final review by the
Compliance Manager. Whilst waiting they’ve started developing a customer service program
for frontline team members. The team has also just completed a training needs analysis for
leadership training so they are thinking about that in the background too. Finally, in between
tasks when they have a moment, they are updating the induction program for new
employees.
Whilst working like this may seem efficient—there is a task that can fill every spare minute—
it’s actually incredibly inefficient. When you get stuck on a particular task rather than
doubling down on the effort to get it finished, you can put it aside ‘until you are ready’ and
pick up another task. Every time you switch tasks you are also switching your focus and
concentration and this switching comes at psychological cost. Each time you switch between
tasks you lose time as your mind needs to stop and refocus. You need to review what you
were up to; you need to get your train of thought back on track.

Video: The Challenges of Multitasking

This is a light-hearted view about the difficulty of multitasking. Note any points that resonate
with you.

https://www.youtube.com/watch?v=Q45cUHfvMZU
Agile approaches recognise the impact of teams taking on too much work at once and
actively seeks to limit the amount of work in progress. The benefits of this are:
• Collaboration within the team is increased as the team works together to complete
stories so they can move on.
• The high priority stories are usually completed earlier in the iteration as the team
works together to deliver the most value.
• The team moves through the work quicker, boosting morale as more work is done
(Donaldson, 2018).

35
Agile Fundamentals: Workbook

Managing Work in Progress

In Agile projects and/or work environments, work is not assigned to individuals in advance.
Rather team members “sign up” for requirements that need to be completed. This requires
team members to self-manage their own workload and hold each other to account in regards
to the current amount of work in progress.
Teams can also use a number of other strategies to limit the amount of work in progress.
Use visual task management tools such as work in progress boards so that everyone can see
what work is in progress and what has been completed.
• As a team agree on the definition of ‘done’. For a lot of project teams there are items
that are ‘technically done’ but are just waiting on testing, or a final review or feedback.
This is where Agile teams come unstuck. Done needs to mean done, no more work,
no feedback, doesn’t need to be touched by the team in this iteration again.
• Use shorter iterations to focus effort on a smaller number of stories and user
requirements.
• Set work in progress limits. That is, how many stories the team can be working on at
any one time. For example, an Agile team agrees that there can only be three stories
in progress at any one time. If the team finds itself with three stories in progress and
they want to start another one, they must first completely finish one that is in
progress.

Activity: Managing work-in-progress

You are coming to the end of the second iteration and you are spotting a theme. One of the
project team members, Juan is very keen to make a good impression on the project sponsor
(and CEO) Leslie. So, he keeps taking on additional tasks for the project even though he
hasn’t completed his existing tasks. Each stand up meeting when asked about the
outstanding tasks he says “it’s almost finished” or “I just need to put the final touches on it”
or “I’m just waiting on them to get back to me”. You also notice that he is working longer
hours than the rest of the team and when you mention it to him, he admits that he has also
been doing work for his normal role as well.
As a team what steps can you take to assist Juan and also manage the amount of work in
progress?

36
 Agile Fundamentals: Workbook

Status Reporting
Status reporting helps the team and the project sponsors know how work is progressing.
There are a number of tools that Agile teams use to track project status; two of the most
common are tasks boards and burndown charts.

Tasks boards
Tasks boards are a visual depiction of the work that that needs to be completed for an
iteration. Tasks boards (also known as Kanban) enable team members to see at a glance
what work is yet to be started, what is in progress and what is finished.
The actual format of the task board can vary based on the type of project or work being
completed. This is significant as the task board is a tool that helps enable teams to self-
organise, so it is up to the team to create a board layout that works for them. It is important
though, to keep the layout relatively simple so that it actually gets used by the team. A simple
task board format is three columns titled To Do, In Progress, Done.

Task boards need to be highly visible and easily accessed by team members. Team
members, not a team manager are responsible for updating the board. As team members
sign up for a task, they move the relevant task into the In Progress column and once
completed the task is moved to Done. This is all done as the day progresses, there is no need
to wait for the daily stand up meeting; rather the task board is an accurate snapshot in time of
the project’s status.
For co-located teams the task board is often a large whiteboard or corkboard in the team’s
workspace. The tasks (or stories) that were written on cards during the iteration planning are
attached to the board in the relevant column. For teams that are distributed across various
locations there is task board software that can be used by the team to maintain the project
status.

37
Agile Fundamentals: Workbook

Burndown chart
A burndown chart is a visual representation of
progress against time – it shows how quickly the
team is burning through tasks (or stories) and when
the project is likely to be finished. The burndown
chart can be created for iterations (although
normally if the iteration is only one week it isn’t
necessary) or releases.

Activity: Status update required pronto!

As a team discuss and decide what options will be most suitable for you to track the progress
of the project.

Leslie (Project Sponsor and CEO) has asked for regular status updates on the project.
However, given the schedule of a CEO it’s hard to book face-to-face time in on a regular
basis. What options do you have for updating Leslie on the status of the project?

38
 Agile Fundamentals: Workbook

Dealing with Changes

Responding to change over following a plan
Agile Manifesto – Values
Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage.
Agile Manifesto – Principles
Expecting change and the ability to easily respond to change is one of a number of factors
that sets Agile apart from other approaches. The ability to respond to change creates a
competitive advantage for the Agile organisation. However Agile teams and projects,
especially when working in an iterative fashion need to manage how they respond to change.
An Agile project could easily become never-ending if the team constantly adapts and
responds to changing customer requirements. Constant changes throughout the project can
also steer it off-course away from the original product vision.
When responding to changing requirements, it’s important to remember that not all changes
are created equal, not all changes are necessarily going to add value and not all changes are
worth the cost. Each requirement or request needs to be evaluated in line with the product
vision and on the premise of “will this requirement generate more value to the customer?”
To enable the concentration of effort towards achieving value for the customer at the end of
each iteration, the addition of new stories, swapping of stories and other changes to
requirements have to be minimised during each iteration. Instead all change requests are
best funnelled through the Product Owner who will evaluate and prioritise them for delivery.
The Product Owner is the only role that has the authority to prioritise new requirements over
existing ones whilst minimising disruption to the team. More often than not, Product Owners
can just reprioritise requirements for future iterations. Every now and then the changes
required may have such an impact that the Product Owner will cancel the current iteration.
The Product Owner and the team will then need to evaluate the work completed so far and
reprioritise for future iterations.
One of the benefits of using incremental development and iterations is that the Product
Owner and the team does not need to wait too long before they can incorporate the change
into their plans. When the project team is deciding on the length of iterations (i.e. one week to
four weeks) it is important to look at the pace of change the organisation is working with. If
change is a constant factor, then the team needs to look to shorter iterations with less stories
in each. If the organisation and the customer’s environment is fairly stable, then a longer
iteration length can be selected.

39
Agile Fundamentals: Workbook

Activity: Looking good so we want more

The initial feedback on the conference is looking great. In fact, the Board are so excited by it
at the end of the second last planned iteration that they decide they want to add to it. They’d
like to extend the day to include an optional all-employees cocktail reception at the end of
the day for 90 minutes. It will be a chance for Board members to casually network with
employees.
Your team has been so creative in designing the conference that they want you to organise it
as part of the project. Oh, and can you make sure that there is some kind of entertainment as
well – one of the directors thinks it would great fun to have a roving mime (they’ve seen it at
another event). And don’t forget music, definitely need music.
Your team’s secondment from their other roles ends in a week’s time and you already have
the work for that week planned out. How do you handle this?

Activity: Social media crisis

One of your high-profile speakers who is confirmed to speak at the staff conference has
become embroiled in a social media scandal. They’ve been caught on film in an intimate
situation with someone who is not their partner and it’s been shared all over social media. To
make it worse there appears to be illegal drugs visible in the background.
The conference agenda has already been shared throughout the organisation. What do you
do?

40
 Agile Fundamentals: Workbook

Agile – Always Learning

Agile is a process of constant learning and adaption. As features of a product are released,
you gain customer feedback and learn how you can improve the product for the next
iteration. As an Agile team you review how you worked together at the end of each iteration
and learn how you can improve for the next iteration. At the completion of an Agile project,
Agile teams conduct a retrospective for inter-team learning, so that the team can pass on to
others what worked and what didn’t (Highsmith, 2009).

End of Project Retrospectives

An end of project retrospective is time set aside for the team and their stakeholders to review
the effectiveness of the project. Retrospectives can be incredibly valuable if done well. They
also have the potential to degenerate into blaming and buck-passing sessions. The most
value can be gained from a project retrospective when it is kept action focused and the
outcomes are shared between project teams. Those organisations that see the value in
project retrospectives will often bring in a facilitator external to the project (and sometimes
organisation) to run the session and keep it action-focused.
There are countless different formats and models that can be used to structure a project
retrospective. However, one of the simplest models revolves around answering three
questions:
• What worked well?
• What didn’t work well?
• What are we going to try to do differently?

Activity: Conduct a retrospective

Congratulations! The Annual Staff Conference was a great success. Feedback from the
employees is that it was the best team conference ever. They are actually excited for next
years. In the three weeks since the conference there has been an unmistakeable buzz around
the workplace. Not only that but absenteeism has been down for the past three weeks and
feedback from customers on service levels has gone up.
Of course, not everything was smooth sailing on the day. No-gluten free cakes being ordered
for morning tea prompted a last-minute dash to the grocery store, one of your breakout
session speakers was sick, another got held up on public transport so they missed their
session. There was also the small issue of one of the booths collapsing under the weight of
the cooking equipment they were using for a demonstration. And you don’t even want to
think about the three Senior Managers who got a little too excited by the free drinks at the
cocktail reception and thought it was a great idea to initiate a drinking game in front of the
Board.
All-in-all you are pretty happy with the end result as a team. Now it’s time to conduct a
retrospective.

41
Agile Fundamentals: Workbook

As a team how can you record the lessons you’ve learned in the retrospective?

What steps can you take to share these learnings with future project teams?

42
 Agile Fundamentals: Workbook

Learning Journal

Take this opportunity to reflect on what you have learned in this workshop and consider the
changes you can make to ensure that you apply the knowledge and skills you have gained.

What do you want to:

Start Stop

Change Continue

43
Agile Fundamentals: Workbook

Glossary

Extreme Programming (XP) – an agile software development framework that aims to produce
higher quality software, and higher quality of life for the development team. XP is the most
specific of the agile frameworks regarding appropriate engineering practices for software
development.
Incremental development – each successive version of a product is usable, and each builds
upon the previous version by adding user-visible functionality.
Iterations – a fixed period of time during which project work takes place. These periods are
short—between one to four weeks—and sequenced consecutively.
Iterative development – intentionally allowing for “repeating” development activities, and for
potentially “revisiting” the same work products to add value.
Kanban – a visual method for controlling work in progress.
Large Scale Scrum (LeSS) – an agile framework for scaling Scrum to more than one team.
Product Owner – a role created by the Scrum Framework responsible for making sure the
team delivers the desired outcome
Release – a group of relatable features that can be deployed and used by the customer.
Retrospectives - a meeting that's held at the end of an iteration where the team reflects on
what happened in the iteration and identifies actions for improvement going forward.
Scaled Agile Framework (SAFe) – a set of organisation and workflow patterns intended to
guide enterprises in scaling lean and agile practices.
Scrum – a set of practices used in agile project management that emphasize daily
communication and the flexible reassessment of plans that are carried out in short, iterative
phases of work.
Self-organising teams - a self-organising team is one that does not depend on or wait for a
manager to assign work. Instead, these teams find their own work and manage the
associated responsibilities and timelines.
Sprints – a short, time-boxed period when a scrum team works to complete a set amount of
work.
Timebox – an agreed period of time during which a person or a team works steadily towards
completion of some goal.
User story – functional increments of work that have been described by the customer or
Product Owner.
Work in progress – tasks that have been started and not yet finished.

44
 Agile Fundamentals: Workbook

Add your own:

45
Agile Fundamentals: Workbook

References

Agile Alliance, 2019, Three Questions, agilealliance.org, Tennessee, accessed 28 June 2019
<https://www.agilealliance.org/glossary/three-qs>
Agile Alliance, 2019, Incremental Development, agilealliance.org, Tennessee, accessed 03
June 2019 <https://www.agilealliance.org/glossary/incremental-development/>
Agile Alliance, 2019, Iteration, agilealliance.org, Tennessee, accessed 03 June 2019
<https://www.agilealliance.org/glossary/iteration/>
Calabrese, J. 2018, Agile Leadership Myth #2: Self-Organizing Teams Don’t Need Any Help,
Agile for All, accessed 13 June 2019 <https://agileforall.com/agile-leadership-myth-2-self-
organizing-teams-dont-need-any-help/>
Cockburn, A. 2006, Agile Software Development: The Cooperative Game, Second Edition,
Addison-Wesley Professional, United States
Cohn, M. 2007, Agile Estimating and Planning, Prentice Hall, United States
Donaldson, N. 2018, Manage project risk by limiting work in progress, Boost, accessed 28
June 2019 < https://www.boost.co.nz/blog/2018/11/manage-project-risk-limiting-work-
progress>
Gilhooley, K. 2019, 6 basic things you shouldn't be doing during daily stand-up, TechBeacon,
accessed 29 June 2019 < https://techbeacon.com/app-dev-testing/6-basic-things-you-
shouldnt-be-doing-during-daily-stand>
Goodman, D. 2018, Agile Process: Why You Need Feedback Loops Both During and After
Sprints, Mendix, accessed 27 June 2019 <https://www.mendix.com/blog/agile-process-why-
you-need-feedback-loops-both-during-and-after-sprints/>
Highsmith, J. 2009, Agile Project Management: Creating Innovative Products, Second Edition,
Addison-Wesley Professional, United States
LeMay, M. 2018, Agile for Everybody, O’Reilly Media, United States
Measey P. 2015, Agile Foundations – Principles, practices and frameworks, BCS Learning &
Development Limited, United Kingdom
Moore, G. 1991, Crossing the Chasm: Marketing and Selling High-Tech Products to
Mainstream Customers, HarperBusiness, New York
Radigan, D. 2019, The secrets behind story points and agile estimation, Atlassian Agile Coach,
accessed 27 June 2019 < https://www.atlassian.com/agile/project-
management/estimation>
Rasmusson, J. 2010, The Agile Samurai, Pragmatic Bookshelf, United States

46
Agile Fundamentals: Workbook

47
Agile Fundamentals: Workbook

COMMONWEALTH OF AUSTRALIA
Copyright Regulations 1969

WARNING
This material has been reproduced and communicated to you by or on behalf of Australian
Institute of Management Education and Training pursuant to Part VB of the Copyright Act
1968 (the Act), under licence from Copyright Agency Limited.
The material in this communication may be subject to copyright under the Act. Any further
reproduction or communication of this material by you may be the subject of copyright
protection under the Act.

Do not remove this notice.

48