An Agile Glass of Water – A Simple Introduction to Agile

We recently had a team day at the lovely Chalk Lane Hotel in Epsom at which I’d promised the team I’d deliver an introduction to Agile and Scrum.

Manifesto is an Agile agency but given how quickly the team has grown over the last year people have different backgrounds and understandings of what both Agile and Scrum are and how to use them.

It’s important for us as a team to have a collective understanding of the things we do and a shared vocabulary. It makes it easier for the team to slot into new projects, with a sense of orientation that let’s us get on with what we’re delivering.

I wanted to give the team a project to work through using Agile – one that they could complete in under an hour and that didn’t exclude the non-technical members.

And so was born the Agile Glass of Water.

But before I get ahead of myself, let’s go back to basics…

What is Agile?

Agile is the name given to of a bunch of software development methods that take an iterative approach to managing work using teams that are self-organising and collaborative.

What does that actually mean in practice? Very little, since Agile isn’t a prescribed way of doing things – rather a set of guiding principles which can be distilled into the following four principles known as the Agile Manifesto:

Agile favours… individuals and interactions over processes and tools

customer collaboration over contract negotiation

responding to change over following a plan

and working software over comprehensive documentation.

There are several different methodologies for applying these principles – Kanban, XP, DSDM and Scrum are four of them.

Scrum is the one we use most frequently, both within Manifesto and with our clients, so that’s the one I wanted to concentrate on. How does it work? Allow the team to demonstrate through their glass of water challenge…

The Challenge

The team of 8 – Curtis, Simon, Anna, David, Rabbia, Louise, Simon and Jamie – had to make a glass of water like this one in 40 minutes.

The Product Owner and the Scrum Master

The Scrum method requires two people to perform very important roles.

The Product Owner, as the name implies, is the person to whom the product will be delivered. They make the final calls on what the product needs to be, what it needs to do etc. In real life they might be the a customer of an agency or, within an organisation, a manager or director from outside of the development team.

David was nominated for and accepted the Product Owner role.

The ScrumMaster is a team member who, rather than managing the team, facilitates team decision making processes and moderates the Scrum meetings (more about those shortly).

Louise took on the role of Scrum Master.

The Vision Statement

Now the team needed a vision for the product. We borrowed Roman Pilcher’s vision board technique for this – to set down who the audience was for the product, what needs it would address, what features it would have and what value it would offer.

This information then generates a vision statement – a concise sentence that sums it all up and guides the development process.

A short collaborative session produced something that looked like this (it was actually on a flip chart but I forgot to take pictures):

It was David, the product owner, who had final say on what ended up on this board. Louise facilitated the process, making sure that enough ideas were generated in the time provided and calling on David to resolve any uncertainties.

The Scrum Planning Meeting

The next stage was to turn the vision into user stories. A user story is a statement which expresses a desire for a particular feature and why that feature will benefit them.

Previous experience of making glasses of water told me that there were 5 essential user stories for this product so, to keep things moving along, I told the team to come up with what they thought those 5 stories were.

Here’s what the team produced (again, apologies for the lack of photographic documentation but I’m writing this post less than 24 hours later so I’m pretty sure these are accurate):

Planning Poker

Now that the team had their 5 user stories it was time to assign story points to each.

Story points are a relative measure of how much size/complexity each user story contains. In a planning poker meeting the values are derived collaboratively – only when a consensus is reached does the point allocation become valid.

In Scrum, the system for reaching consensus goes like this: taking each story in turn, the team votes on how many story points they think it requires. Voting is done simultaneously so that no one can influence anyone else’s vote – numbered cards are shown at the same time.

When you first story point a new set of user stories you might find a smallish task and assign it the value of 2. The other stories are then scored relative to this one.

The numbering system for these cards is Fibonacci-like. In other words the gap between numbers gets bigger as the numbers get bigger. This reflects that the higher the estimate, the less accurate it’s likely to be. It also helps with consensus reaching, creating fewer points around which consensus can coalesce. The numbers on the cards run like this:

0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 and ∞ (infinity)

As well as the numbered cards there are also cards that indicate that you’re unsure what to vote (?) and that you’d like to take a break (an image of a coffee cup).

When a round of voting on a user story produces no consensus the group discuss the story further, particularly the lowest and highest estimates, taking any further questions over what is/isn’t acceptable to the Product Owner. The team then votes again and so on until everyone is agreed and they can move on to the next story.

The team working on the glass of water assigned the following story points to their stories:

Umbrellas and straws had been provided in generous quantities so they were adjudged to be pretty low scorers.

After consulting the Product Owner it was discovered that the glass did not have to be designed and built from scratch, so some voters were talked down from their scores of infinity, but it it still had to be retrieved from another room, leading to the highest score of 8 story points.

This method – known as planning poker, or Scrum poker, is really effective for teasing out differences in understanding of what a story is about and over time can be used to forecast accurately how much of a product is likely to be created over a given period of time. It’s much better that just one or two people deciding unilaterally or, by exerting their personality over a group, silencing those with varying estimates.

Scrum Manifesto – an app we’ve developed for assisting Scrum planning poker and which does away with the need for cards is due for release soon.

Sprint Number 1

Now that the effort for each story had been estimated it was time to put them into the Sprint backlog. I told the team they were only allowed 1 minute sprints so not all of the stories would make it into the first one. To achieve the exercise in the overall timeframe some things have to be slightly more prescriptive than on a real Scrum project.

The Product Owner was consulted about which of the stories would provide the most value and the glass, water and lemon were decided for inclusion. Team members volunteered themselves for the available tasks and the clock was started.

A good start with both water and glass being retrieved quickly by Simon and Rabbia soon came unstuck as it became apparent that the lemon was too hard to cut- especially in the thin slices demanded by David – with the only available knife: a nice looking but ineffective bread knife.

The sprint ended with a glass filled with water but no lemon slice.

Time for a review: lemon cutter Louise was not confident that she could produce an acceptable lemon slice in the next sprint. Curtis volunteered himself as substitute. It was also suggested that the lemon be changed, giving the new cutter a better chance.

Sprint Number 2

Along with the lemon story the remaining two stories were added to the second sprint. Again, the team volunteered for tasks and the clock started.

Curtis had better luck with the lemon, producing a slice that satisfied the Product Owner’s rigorous specifications. The story points for the straw and umbrellas had been accurately estimated.

The second sprint ended with a finished glass of water suitable for even the trendiest Dalston dwelling thirsty hipsters:

Retrospective

Every Scrum sprint ends with a retrospective where team members point out areas for improvement that can be incorporated into the next sprint.

Due to the time and length of the sprints the first retrospective took the form of a short conversation about how the team could improve. The focus was on the troublesome Lemon.

We used an exercise called glad, sad, mad after sprint 2, but we included the ability to comment on both sprints as they were so close together. Each team member wrote what made them glad, sad or mad about the sprint on a colour coded post-it and stuck them on the wall.

Predictably the lemon incident had ruffled a few feathers but the team seemed upbeat about delivering a glass of water that met the Product Owner’s expectations.

Well done team! Take a well earned rest.

Agile Glass of Water Recipe

The Agile glass of water exercise aims to illustrate the Scrum roles, prioritisation, estimating, planning and in sprint activities in a way that’s easy to understand.

It’s deliberately designed to raise questions like ‘what’s more important – a lemon or a straw?’ Which is pretty much the same as ‘Shall we build login or a Twitter integration?’

It leans on Roman Pilcher’s great Product Vision Board to create focus for the team which is also a regular feature of the workshops we run with clients.

At Manifesto I use this after having run through all of the core Scrum principles as a way of reinforcing them practically. They’re part of our half-day introduction to Scrum workshop.

If you’d like to use this exercise you will need:

• A glass
• Some water
• A lemon
• A blunt knife
• Some straws
• Some cocktail umbrellas
• A Product Owner
• A ScrumMaster
• A team
• To drop a few hints to keep it on track

Let us know what you think – or if you use/adapt this exercise to teach people Scrum.

If you’d like to compare the agile approach to project management with the traditional waterfall method, check out this blog post.