Agile
LESSON
LESSON SCRIPT
@Circus_St | [Link] 3
AGILE LESSON SCRIPT
LESSON 3
Chapter 1: Introduction
Hello, and welcome to our final lesson on Agile. Now we’ve covered the
fundamentals of Agile and how an entire business can go about adopting this way
of working, it’s time to explore some practical ways you can start using agile.
The concepts of agile working are prescriptive on paper, and, while the rules and
principles are meant to guide the people using them towards improving their
product delivery, many organisations have found that it’s sometimes not practical to
expect a team to be able to adopt every rule around agile working. In some cases,
businesses will find that an agile principle just doesn’t work for them.
Agile is about learning and uncovering new things all the time, trying and failing fast.
After exploring these concepts over the first two lessons, here we’ll cover how you
can identify and trial different aspects of agile and Lean to suit your team or
company.
© Circus Street Ltd. 2
AGILE LESSON SCRIPT
LESSON 3
Chapter 2: Getting Started
With so many guiding principles, it can be difficult to know where to start. The most
effective step towards an agile transition is to deliver working products frequently to
customers. While this can be a radical change for corporations who deal with upfront
planning and scoping, the change itself can be approached incrementally.
So, why not try approaching your next piece of work or project in a more iterative
manner? There are small and manageable changes that can contribute to trialling
this. For example, a project can be planned differently to include fortnightly demos
with the customer, which encourages the team to ensure the work done so far is
functional. It also invites early feedback, which could be discussed and expectations
managed accordingly.
You could also use “alpha” and “beta” deliveries, to represent that your delivery is
not quite built to its full scope yet, but still gets it into the hands of users. By keeping
deliveries small and regular, it reduces their complexity and risk, but does require a
shift in thinking to ensure that the product is functionally ready for each demo.
Bit by bit, you could develop the concept even further, by switching your planning to
be more regular. This means that the feedback from those customer demos can be
written up and incorporated into the next planning session, which is the first step
towards implementing Scrum.
The journey to agile working is most effective with the right advice and coaching to
guide businesses and teams through the change. Some companies choose to
employ an agile coach or consultant to advise on the theories and help teams
implement them. However, as we’ve explored, it’s important for all levels of the
business to be on board with agile for it to work effectively.
Most agile teams have high-level roles, the most common of which will fall into the
categories of:
Team member - a “worker” on the team. This could be a variety of roles, but
ultimately should be someone that produces the end result. For example, on a
Marketing team, a team member might be a blog writer or an email marketer.
Team lead, coach or mentor - someone who can mentor the team to reach their full
potential, whether that be in agile practises or industry specialities. This role should
to be able to facilitate team discussions and remove blockers that might prevent the
team from progressing. If we think about the Marketing team again, this could be an
© Circus Street Ltd. 3
AGILE LESSON SCRIPT
LESSON 3
editor or a digital marketing specialist who can guide the team members to the right
answers - but it’s important to note that it’s not a managerial role.
A Product Owner or stakeholder - someone who is the voice of the customer within
the team. This role has the responsibility for prioritising the product backlog, and this
individual must have a strong vision for the product and be able to communicate it to
ensure business value is met. Perhaps the chief marketing officer might sit on a
Marketing team and take on this role, but, again, it’s not a managerial one.
We’ve covered off how traditional Waterfall methods with strict project plans have
downsides when it comes to delivery. But planning is still a useful exercise. However,
a balance between preparing requirements up front and anticipating them to change
is vital. An agile team should take a pragmatic approach and plan just enough up
front once they know enough about what’s coming.
Let’s create a product to explore how we could plan as an agile team.
Pet store “Supermar-cat” want a digital experience for its customers, and create an
agile team to build a website. The team is made up of developers and testers making
up the development team, a Scrum Master and a Product Owner. The team decide to
keep their iterations timeboxed to two weeks each because there are many
competitors in the pet store space and they want to ensure they’re always taking
advantage of anything that will give them a competitive edge. The team decide to
use Scrum as a delivery methodology.
The Supermar-cat team are starting from scratch with their product backlog, and so
they need to understand the requirements from customers. Remember, the backlog
is a prioritised list of features for the product. The PO invites the team along to some
workshops with some existing customers, and they collect these basic requirements:
• Customers want to see all products that are sold in Supermar-cat’s physical
stories.
• Customers want to know the price of each product.
• Customers wants to order the products by price.
• Customers want to have the option to only see products for their pet (so dog,
cat, bird, rabbit, and so on).
© Circus Street Ltd. 4
AGILE LESSON SCRIPT
LESSON 3
• Customers with more than one pet want to see products for more than one
type of pet.
• Customers want to buy the product online and have it delivered to their
address.
• And, customers want to have the option to pay by credit or debit card or store
voucher.
The PO immediately identifies that the first two requirements are the most important
to satisfy basic customer needs, and so these are put at the top of the backlog.
To see how this can work, why not try creating a product backlog for your team. As
it’s a list of prioritised requirements for your agile team to work through, it can be as
simple as writing down everything the team has planned for the next few days,
weeks or months. Try writing each item down on a separate card or piece of paper,
to make it easier to change the order of them. Items can range from being very well
understood, with specific detail, to very vague.
Then, when you have all your tasks on cards, you can put them into a single column
on a table or a wall and start moving the most important ones to the top, to indicate
that they’re the highest priority and should therefore be done next. You can
continually add items to your backlog and reprioritise them, but you should always
ensure the most important items are at the top so the team know what to do next.
So, what form do these requirements take on in the backlog? Many agile teams write
requirements with a user-centric method called ‘user stories’. A user story is
described from the perspective of the person who has a need for it.
In the Supermar-cat team’s backlog grooming session, the team take the time to
review the requirements. They identify four different high-level user needs: Product
listing, Product information, Filtering products and Buying products. These high-level
requirements become their ‘epics’.
To ensure that they’re focusing on the customer value for their users, the team write
the requirements as user stories so that they’re always reminded of what each
requirement offers the customer, before putting them into the epics.
The first user story is: Customers want to see all products that are sold in Supermar-
cat’s physical stores.
© Circus Street Ltd. 5
AGILE LESSON SCRIPT
LESSON 3
Following the standard convention, this user story is written from the point of view of
the customer:
“As a User, I want to see all products sold by Supermar-cat, so that I can decide what
product I want to buy.”
The team write seven user stories in total.
User story Epic
Customers want to see all products that are sold in
1 Supermar-cat’s physical stories.
Product listing
"As a User, I want to see all products sold by Supermar-cat,
so that I can decide what product I want to buy"
2 Customers want to know the price of each product.
"As a User, I want to know the price of each product, so that I
can decide if the price is reasonable to me"
Product information
3 Customers wants to order the products by price.
"As a User, I want to order products by cheapest to most
expensive, so that I can buy according to my budget"
Customers want to have the option to only see products for
4 their pet (i.e. dog, cat, bird, hamster, etc.).
"As a User, I want to only see products suitable for my pet,
so that I don’t have to trawl through items that are of no use
to me"
Filtering products
Customers with more than one pet want to see products for
5 more than one type of pet.
"As a User, I want to be able to see products suitable to
more than one type of pet, so that I can browse products for
all my pets at once"
Customers want to buy the product online and have it
6 delivered to their address.
"As a User, I want to buy products on the website and have
them delivered to my address, so that I don’t have to go out
to a Supermar-cat store"
Buying products
Customers want to have the option to pay by credit/debit
7 card or store voucher.
"As a User, I want to pay for my purchase by credit or debit
card, or store voucher, so that I can complete my transaction
all online"
© Circus Street Ltd. 6
AGILE LESSON SCRIPT
LESSON 3
Multiple epics might make up a theme, which is where an epic becomes too big to
be a large user story and instead is a collection of large user stories. There’s no rule
as to when a user story or an epic becomes too big, but some teams find it useful to
segregate requirements this way, and it can also be practical for product owners
when presenting a product roadmap.
Splitting requirements into their smallest and simplest form is an essential exercise
for an agile team, but a challenging one at first. We know that the main goal of an
agile team is to deliver working products that satisfy requirements to customers
frequently, but to do this, the team must plan what this looks like. Their user stories
must be small enough to deliver within an iteration, but still provide value to the
customer.
The Supermar-cat team do this by addressing each user story in turn to ensure that
they are as small as possible, while still delivering value, and identify the minimum
they can deliver to the customer. This will make up their minimum viable product (or
MVP). Although the customers at the workshop expressed many needs, the team
want to get a functional product that still satisfies their basic requirements into their
hands as soon as possible and start collecting feedback on it.
The team have agreed that the first two user stories are the most important and
commit to this as their first iteration to deliver to their customers. The other user
stories are then left on the product backlog to split up into smaller chunks and
address in future iterations.
You could try this exercise with your team to split up your work into iterations. When
faced with a task, consider all of its components or elements, and scrutinise their
importance and complexity.
As the Supermar-cat team works through multiple iterations, they begin to
understand how much work they are able to do for each one. They estimate each
manageable chunk of work by assessing the complexity and effort involved in the
task, and by comparing it to something similar they have worked on before. This is
called ‘comparative estimation’, and most agile teams use something abstract - such
as ‘t-shirt sizes’ - to estimate their work. Over time, the team will build up a velocity of
how much work they do per iteration.
Supermar-cat’s product team are a Scrum team, and they estimate their work in
‘storypoints’. Storypoints are an abstract unit of measurement for each piece of
work. On their own, they’re meaningless, and only mean something when they
© Circus Street Ltd. 7
AGILE LESSON SCRIPT
LESSON 3
become relative to other estimated pieces of work in the context of the product
backlog.
So, for example, if the team estimates a piece of work to be worth 1 storypoint, it
means it’s half as much as a task estimated as 2 storypoints. When estimating a
piece of work, the team considers the complexity of the task, the effort required, and
the risk involved, but not the amount of time it thinks it will take to do the task. An
agile team never estimates in time-based units for a number of reasons, one of
which is because different team members might take longer or shorter to complete a
task, and the team always works as a single entity.
The Supermar-cat team estimate their tasks for the first iteration as a total of 4
storypoints. As they complete those tasks in their first two-week sprint, their sprint
velocity is 4 storypoints. In their next two-week iteration, they feel comfortable
committing to completing another 4 storypoints.
© Circus Street Ltd. 8
AGILE LESSON SCRIPT
LESSON 3
Chapter 3: Working with Agile
We know that visualising work and the flow of work are important values in agile.
Agile teams visualise their tasks by writing them on cards, or “kanbans”, which we
know from discussing the Kanban methodology. Each card represents a manageable
chunk of work, on which the task’s description - or user story - is written, as well as
other useful information, such as dependencies, the estimate, or the associated epic.
The team then manage the tasks by moving them through the workflow represented
on a visual board. Some teams use physical cards and physical boards that are
visible to everyone in the office, others use online tools such as Trello or Jira as a
virtual board...
When a team commits to a piece of work, it gets put on their board. All agile teams
have boards, whether it’s a “sprint board” for a Scrum team, or a “Kanban board” for
a Kanban team. The board is arranged in columns, each of which represents a stage
in the workflow.
We know that all tasks go through a journey of To Do, Doing, and Done, and these
make up the three basic columns of an agile board. Some teams might split some of
the columns into multiple stages.
Work that hasn’t been started yet is “To Do”.
A task in the “Doing” column is actively in progress. However, for a large task there
may be multiple stages of ‘doing’ the task. For example, writing a blog post goes
through many stages before it’s finished, like research, writing, waiting for review,
and editing.
Different team members may take responsibility for different stages of “Doing” the
task, and some stages may need to be completed before another team member can
move theirs to the ‘doing’ column.
A task cannot be “Done” until it satisfies the requirements. Agile teams have an
agreed and documented Definition of Done, which is a checklist of everything that a
task must satisfy before it can be deemed “Done”. This might include rules like “sign
off from stakeholders” and “all tests passed”, but it differs from team to team.
Visualising work is an easy way to get started in agile, and you can try it too. Find a
spare wall in your office and draw columns to represent the team’s workflow -
remember to base the columns on “To Do, Doing, and Done”. Index cards or post-it
notes make great Kanbans to represent tasks. They can be stuck up on the wall and
© Circus Street Ltd. 9
AGILE LESSON SCRIPT
LESSON 3
moved across the columns so that all members of the team can see at a glance
what’s going on at any time. Encourage the team to remember to move their cards
when the status of the task has changed. Over time, the team can assess how to
improve the workflow and adapt the board as necessary.
In agile and Lean methodologies, meetings are generally kept to a minimum in an
effort to eliminate waste, but there are some meetings - or ‘ceremonies’ - that are
important for an agile team.
Ceremonies also differ according to the methodology the team adopts, for example,
sprint planning is used by a Scrum team to initiate their sprint, and they hold a sprint
demo at the end of a sprint to showcase their work to stakeholders.
Two of the most useful ceremonies for any agile team are the daily stand-up and the
retrospective.
An established agile team is self-organising, and the first step to making that happen
is ensuring that communication flows well between individuals. Implementing daily
stand ups is a formulaic way to gradually get people talking, and can be a great
introduction to agile working.
Why not try holding one with your team? Try getting your team together at the
beginning of every day - keep the time and place the same if possible, as
familiarisation and routine will help the session run smoothly.
Invite the team to stand in a circle next to your visual board, either on a wall if it’s a
physical board or on a monitor. Then, invite each person to say a sentence on what
they did yesterday, what they’re planning on doing today, and if they have any
blockers. You can encourage others to respond to their colleagues’ impediments as
part of this session with a simple “can anyone else help unblock this?” - this often
spurs additional conversation within the team, and, more often than not, eventually
out to the wider business.
But be mindful of not letting conversations get out of hand, and avoid anything
veering off track of the key questions.
A retrospective is a session where the team gets together and reflects on how it’s
doing, or, in the case of a Scrum team, how the last iteration went. These ceremonies
are often facilitated by the Scrum Master, who will stimulate discussion around three
areas.
© Circus Street Ltd. 10
AGILE LESSON SCRIPT
LESSON 3
A retrospective is a safe forum for vocalising emotions and team members are
encouraged to be as open and honest as possible with each other in order to make
things better.
You can easily hold a retrospective, using some post-it notes and a wall. Get
everyone in a room and encourage them to think about the past week or two weeks.
Allow participants a few minutes to write down their thoughts about “what we did
well” and “what we could be doing better” and invite them to stick them up on a wall
in two sections. Ask everyone to stand up and read the wall, or, you could read each
post-it out loud.
If the group is large, you may want to allow everyone to vote on which of the items
they feel are most important to discuss and gradually, actions should be generated
out of the discussion. If you find that actions don’t come naturally, try asking
something like “what can we do about that?” or “what can we do to avoid that next
time?” in response to particular items. The actions should be documented and the
team should recap on them before the session is over and agree to commit to
executing them.
New teams will often need guidance through this activity, especially in meeting the
commitments they identified, but giving them the forum to realise where
improvements can be made is the first step. After a while, the team can start
discussing more complex scenarios and concepts towards increased efficiency, and
commit to bolder solutions to solving problems.
© Circus Street Ltd. 11
AGILE LESSON SCRIPT
LESSON 3
Chapter 4: Summary
Applying agile principles doesn’t need to be complex. Teams and businesses should
use agile values where there is a need to, and where it offers value to them and their
customers. There’s little point in adopting agile practises just because someone has
written the guiding rules down in a book.
You’ve hopefully been inspired to start trialling some of the straightforward
applications of agile. It’s a good idea to try them out with your team and then bring in
other departments to participate. A weekly Scrum of Scrums session or even a
seating arrangement tweak could mean that communications run smoother between
teams, and learnings can be shared.
© Circus Street Ltd. 12