Agile Games

The way to a team’s heart is through the games it plays.

I had the pleasure of attending an Agile Edmonton meeting in September on ‘Agile Games’.  Mike McCullough ran the attendees through some exercises to demonstrate and teach agile principles.  We had a blast and enjoyed it immensely.

I took the liberty of presenting one of the exercises to my team.  It is called “What were they thinking?”  The game is designed to teach people that describing a product without an existing model is problematic.

I tweaked the game slightly by using a different picture for the second round.  I wanted to show the difficulties in describing an object which is similar yet different from the one used in the first round.

Give it a try with your team.  It is fun and demonstrates a very important lesson.

Here are the photos I used:

 

 

 

If you want to read about this and other agile games, head over to http://tastycupcakes.com.

Relatively Weighted

Why the Product Backlog is not prioritized by time

I gave a primer presentation to the team on how to plan in the SCRUM framework.  I covered SCRUM at a high level, occasionally drilling deeper in to best practices and smells.  Most of the presentation centred on preparing your Product Backlog & the Sprint Planning Meeting.

One of the attributes of the Product Backlog is that all items within it are ‘relatively weighted’.  While preparing my presentation I could not find an example that I felt satisfied why ‘relative weighting’ is a good idea.  Most of the examples I found were stories about the benefits realized, but not why the benefits manifested.  Traditionally our team focused on measuring tasks as units of time, so it was important I had an example that walked through the thought process towards ‘relative weighting’, rather than just stating the benefits.

Thus I created the following slides and walked the team through them.

Here is the scenario.  You just created a Product Backlog of 10 items, each weighted as ‘1’.  For your first sprint, your team has estimated that they can accomplish the top 5 items.

At the end of your sprint, you only managed to complete the top three items.  The first two took twice as long as expected.  This did not leave any time for the remaining two items.  You update your Product Backlog with the results.

 

Now your team begins planning for the next sprint.  So I posed this question to the attendees:

How much work can your team commit to accomplishing in the next sprint?

The answers were varied.  Some people said “five items”.  Others said ‘four’, or ‘three’.  There were many interpretations of the data.  This was the point of the exercise:

Using a value which varies over time, and cannot be reconciled between the Product and Sprint backlog, is problematic at best.

You’ll notice I did not say the weights were units of time, like “1 day” or “1 hour”.  They could have been ‘1 banana”.  The goal was to demonstrate the problem, not that you should not use time as a measurement.

Let’s try the exercise again but with one difference.  Each item in the Product Backlog is also weighted by risk & complexity.  Again there other ways to weigh your backlog, but I wanted to keep it simple for the demonstration.  We retain the estimation of effort as ‘1’ for each item in the Backlog.

We complete our sprint & find we are in the same scenario.  The first two items took twice as long, leaving no time for the last two.  We update the Product Backlog with our findings.

 

I then posed the same question to the attendees:

How much work can your team commit to accomplishing in the next sprint?

When I asked the question in the presentation, the answer came quickly: the team can commit to accomplishing the remaining tasks in the Product Backlog.

How you may ask?  We committed to 5 items in the first and only managed to finish 3 of them. Now suddenly we can commit to 7 items which is more than double what we previously accomplished.

As you may have guessed, our relative weighting has something to do with the answer.

Each item in the Product Backlog is weighted relatively.  Put it another way, each item is tagged with a value which ranks it higher or lower than other items in the Product Backlog.  Summing the values of the items we finished in the first sprint gives us 29 points.  This is our Sprint Velocity.  The sum of the remaining items is also 29.  Therefore we can commit to completing the remaining items in the Product Backlog.

 

The point is, your Sprint Velocity is a far better indicator of your productivity.

I want to be very clear.  I am not claiming that knowing your Sprint Velocity will solve all of your problems when estimating productivity, but it is a very good metric.  Remember that you can commit to as much work as you want, but at the end of the day, it is the work that is finished that counts.

The Sprint Velocity is a track record of how much you can finish, rather then how much time you can commit to your tasks.  To your customer, what you finish is what counts.

Virtually Standing Up

My teammates & I participate in SCRUM meetings. It is a daily routine that has proven useful and informative. One practice that we have adopted that I also find useful is the ‘virtual stand-up’. If someone cannot attend the meeting, then s/he sends the team an email that acts as a proxy for his or her standup. The content of the message is the same as what they would say during the meeting:

• What was accomplished
• What will I accomplish for the next meeting
• What is blocking me

The virtual standup keeps the team informed & I encourage other SCRUM teams to adopt the process if you have not already.

I Drank the Cool-Aid

It is official, I am a Certified SCRUM Master’. How did I achieve this prestigious title? The formula is simple. Years to hard studying while removing distractions like family, a personal life, & hygiene? Not! It was a laid-back two-day course. That has not to say SCRUM’s message wasn’t powerful nor enlightening.

For those who do not know, SCRUM is a framework built on agile values. That is it. It is not a process or a methodology. It values communication over tools. In fact, the cornerstone of a SCRUM team is the ‘Task Board’, which is typically a grouping of sticky notes on a wall that people look at every day.

SCRUM starts with a Product Owner who creates a ‘Product Backlog’. The Product Backlog is a prioritized listing of all the work that the business would like the SCRUM team to implement. Next the SCRUM Master & SCRUM team perform a short launch (typically ~1 day) where the team reviews the top 20% of the Product Backlog to determine what they can accomplish in the next Sprint.

A Sprint is a fixed duration of time, typically 30 days (or 4 weeks). A Sprint can be longer or shorter. Longer is not recommended because that begins to violate agile principles on continuous feedback. Shorter (2 weeks) is generally a good idea for experienced or newbie SCRUM teams. Why? Experienced teams value the communication that SCRUM encourages, so shorter Sprints results in faster feedback of the success or failures of a Sprint. This allows the team to adjust for the next Sprint. If the Sprint was 4 weeks, that information may be delayed by an additional two weeks. The same goes for newbie teams. For intermediate teams, 2 to 4 weeks is normal.

Once the work has been decided, the team then breaks the work in to individual tasks. Each task is then estimated. Typically, this is all done on the Task Board with sticky notes.

Here is a simple example:

Work: Add Service X to product Y

Task 1: Draft engineering design
Task 2: Review engineering design
Task 3: Implement engineering design
Task 4: Test implementation

Every team member should take a single task & work on it. When the task is completed, they take another, and so on.

The SCRUM Master takes these tasks and creates what called a ‘Burn Down Graph’. The Burn Down Graph is a chart which tracks the completion rate of the team. For example, if there were 30 tasks for a 30-day Sprint, then the Burn Down Graph would estimate that 1 task per day would need to be completed to successfully end the Sprint. Completed tasks are tracked against the graph to determine if the team is tracking above or below the predicted rate. This way the team can track its progress and make adjustments as needed.

Each day the SCRUM Master facilitates a meeting called the ‘Daily SCRUM’. The daily SCRUM is a 15-minute (no more) team meeting where each member has the opportunity to answer the following questions:

1. What did I do since the last daily SCRUM?
2. What will I do for the next daily SCRUM?
3. What roadblocks am I experiencing?

No one else speaks, & when the last team member has spoken, the team disbands & gets back to work. The SCRUM Master then tries to remove the roadblocks outlined in the meeting.

Now it is important that you understand a key rule of the daily SCRUM. To understand that rule, here is a little story:

A chicken walks up to a pig and says "Hey pig, would you like to open a restaurant with me?". The pig responds "What’s the name?". The chicken says "Eggs & Ham". The pig responds "No thanks. I’d be committed while you’d only be involved".

In case you did not get the joke, the chicken would only need to provide eggs, but the pig would have to sacrifice himself.

Team members are pigs. They are committed to the project. Without them, the project does not exist. They are the ones who commit everything to the project. Everyone else is a chicken. They are those noisy entities that reside outside of the team. The reason I write ‘noise’ is that in traditional environments the noisiest entities are the ones that get resolved first, even though they may not be the right ones. For this reason, the chickens may attend a meeting, but they are not allowed to speak. Only team members are allowed to talk, & only on the three questions stated above. This is very difficult for both team members & non-team members because everyone likes to be involved.

After a Sprint, the team presents its potentially shippable product to the business during a ‘Sprint Review’. I will write it again: potentially shippable product. The object of the Sprint is to produce a product that, if management said to, you could ship. If the product is untested, undocumented, or incomplete in any way, then the team did not meet the goal of the Sprint. I must point out that you will not necessarily ship the product at the end of each Sprint (maybe for web development), but the product of a Sprint must be of high enough quality that you could ship if you had to. Hence potentially.

The last step is the ‘Sprint Retrospective’. To coin a more familiar term, it is the ‘post mortem’ of the Sprint, where the team discusses successes, failures, roadblocks, ideas, etc. The products of this meeting feed the next Sprint cycle. The next day the team begins a new Sprint with a new launch.

That is a brief overview of SCRUM. I did not mention many activities of the SCRUM Master specifically, but the role is critical to the success of the team. The SCRUM Master responsibilities include:

· Making SCRUM work in your environment

· Removing barriers between development & the customer

· Improving the lives of the SCRUM team by facilitating empowerment & creativity

· Improving the productivity of the SCRUM team

· Improving the engineering practices and tools

I enjoyed the course & recommend it to anyone interested in SCRUM or managing/leading agile projects.

I drank the cool-aid.