Going Agile: Trying To Do Too Much

When you are managing a team that starts migrating towards Scrum, you will find yourself looking into things like velocity and burn down chart wondering if the team is committing to too much or not enough.  You will soon realise that if you allow your scrum master to do her job, the team’s velocity will quickly stabilise and become predictable on their delivery.

However, what I find often overlooked is the impact of the backlog management. In my experience, trying to do too much is not just about the team over committing on an iteration but also about the product owner providing a lack of focus for the release.

Let me give you an example. Within the Ubuntu Certification team, we run six monthly releases, this are then divided into two weeks iterations. On the last release, we scheduled 13 themes. A theme for us is a overarching issue or requirement to which then stories are link in the backlog. In other Scrum practices this are called Epics.

Out of this 10 themes, we estimated that we could deliver 75 stories.  The team is in average finishing 7 stories (depending on sizing) per iteration. The problem with this approach is not that the 75 stories we picked weren’t the right priorities but rather that:

  1. We went for breath rather than depth. We achieved some progress in each individual theme, but not in depth progress in any.
  2. The team constantly had to switch mental context between themes. Some times a month would pass between stories from the same theme. Although the stories are independent this did not build on the sense of achievement by team every time a story was complete.

What I have learned in this release is that context switch is not only a problem for multi-tasking coders but it is also a source of waste for scrum teams needing to frequently change backlog themes from iteration to iteration.

With hind sight, I would have rather schedule 5 themes. I think that the kick that the team gets from making substantial progress in a theme plus the reduce need for context switching would have actually increase the productivity of the team.

Our next release starts in November and I am going to make sure that this time we focus on depth!

Going Agile: Poker Planning In Action

The Certification team at Canonical has been Going Agile now for the last 9 months. Oneiric is the first release that we are running full Scrum practices. We are a bit unique as we are spread all over the world. We have 2 people in Montreal (Canada), 1 person in Boston (USA) , 1 person in Raleigh (USA), 3 scatter over the United Kingdom, our Scrum Master is in Germany, and our latest team member is in Taipei (Taiwan). Running Scrum in this type of  environment needs constant innovation. I am keeping track of our progress in my blog at victorpalau.net/tag/scrum/

Roughly every three months, we get together somewhere in the world. We just got back from the Ubuntu Rally in Dublin, where we decided to give our backlog some love!

We largely build our backlog at the Ubuntu Developer Summits and then we continue to add and remove items as we go.

Halfway through the project and with over 100 items to complete before the end of October, we needed to step back and make sure that we were working on the right priorities and that nothing had fallen trough the cracks. What better way to do this than a full poker planning session. Here is how it worked:

  • We use real cards that I brought over from home
  • We clear up a round table big enough to fit the whole team and we booked an hour and a half for the session.
  • We had a house dealer: I chair the session, I did not participate on the poker, my computer was the only one allowed at the table.
  • Using the list view in our google docs backlog, we reviewed a blueprint at the time
  • We spent less than 90 seconds per use case.
  • We use the following t-shirt sizes as measure of effort required to complete a use case: S,M,L & XL
  • Where there was substantial disagreement on size, we asked the highest and lowest  bid to briefly reason their decision. If needed, we did another sizing round after that.
We did came out of the session with a better sized backlog. The biggest benefit for me was that we merged, deleted and added new stories based on what we had learned over the last few months of implementation.
I also had to make some tough choices based on the new information and I decided to removes some blueprints from our Oneiric backlog scope.

Poker by Jonathan Rubio

Going Agile: Late Night Poker and Uncertainty

After the Ubuntu Summit in Budapest, We were faced with a lengthy backlog for the next 6 months. We made sure that we wouldn’t waste too much time on defining in great detail stories that would not be executed until 3 or 4 months from now. The result is that the next month worth of stories are smaller and more granular and large stories are found towards the bottom of the backlog. So far so good.

Like any successful team ;) we have more work that we wish we could do than we can actually fit over the next 6 months. To reduce scope, I needed to at least defined what is our estimated capacity for the 6 months and compare it with the current backlog.

To be accurate, we would need to estimate the size of every story in the backlog, in a more consistent manner than asking a team member for their gut-feeling (current process). We discussed having a Late Night Poker session at Budapest where we would size every single story, however this strike me as not agile at all.

Having discarded the massive Poker Planning session, I started looking with the Scrum Master at other options: Monthly Poker, Next Iteration Poker…and so on.

Eventually, I decided that I was looking in the wrong direction. We are going to continue doing planning poker for the Iteration that we are about to start and we will need to leave with the uncertainty of our backlog.

One thing was certain, that our backlog was too large and needed trimming down. Looking at our team’s velocity, I noticed that it was not only consistent on the story points but also fairly consistent on the number of stories completed per iteration. Saying this, I set out to cut down the backlog assuming that we completed 7 stories per iteration and that the last iteration should be empty. Clearly, this is not 100% accurate, maybe not even 80%, but it is a good starting point.

Agile is about managing change and living with uncertainty, and I’ve realised that I was trying to bend that in to good-old false security feeling of predictability.

Going Agile: The 6-Months Cadence

I have commented several times on the 2-weekly cadence that we follow at the certification team, but I haven’t gone into much detail on our 6 monthly cycle. We have just completed the Natty cycle (normally release date + 2/3 weeks) and we are about to start our Oneiric one.

6 monthly cycles help to plan achieving longer goals that drive the user stories implemented by the team in each iteration/sprint. During Natty, we had a loose coupling between these two.  I regularly (once a month) reviewed the progress of the Natty backlog and made sure that nothing was falling through the cracks. Despite the good completion rate in Natty, it was more of a case of the user stories forming the Blueprints (6 monthly requirements) than the other way around.

For Oneiric, the certification team went into UDS-O with much better defined blueprints. This has not only resulted in better sessions, but also on well defined backlog. Clearly, there is no much point trying to tight down what we will be doing in 4/5 months, so user stories towards the end of the cycle are vague and fairly large.  User stories for the next 2 months are better understood and described.

We have been collecting velocity data for the last few months, so by asking the team to roughly size new stories and review the sizes for the “next_iteration+1″, I hope to be able to build a burn up/down chart over the next few weeks! I will keep you posted.

Going Agile: The Ultimate Scrum Google Doc Template

While trying to work out the best way to adopt Scrum in the Ubuntu Certification team, I didn’t want to commit to an expensive process tool. So we have end up developing overtime the ultimate Google Document SCRUM tool.

I didn’t want to spent too much time reviewing tools and shopping for better prices rather than working on embedding the process correctly in the team. We might eventually move to a hosted “funky” web 2.0 solution, but in the meantime, Google Docs is doing the job just fine.

I thought that it will be great to share our backlog template with everyone, so I have created a public template with some fake stories. Here is the breakdown on how it works: Read more of this post

Going Agile: A few iterations under the belt

I wrote recently about the Ubuntu Hardware Certification team transition to Scrum.  We have since completed a few iterations, which means that the Planning and Demo sessions are in full swing. I am also happy to say that we now have a full-time Scrum Master in the team. One of the key advantages of this is that I get to sit in the demos and ask questions “from the outside” :)

Because of the global distribution of my team, we have end up with back-to-back Demo/Review and Planning meetings. This is how it goes:

3pm UTC – Demo meeting (30 minutes)

The Scrum Master runs (using Mumble) through all the user stories in the backlog.  Previous to the meeting, team members have posted links to their demos. We share the demos using a “virtual meeting” tool.  We end up settling for Spreed, as we already had some company accounts ( but I still secretly love yuuguu!).

At the end of each demo we [product owner, scrum master and me] give our opinion on whether the user story is completed or should be carried over to the next iteration (or later). Read more of this post

SCRUM can help you running workshops

The Sprint Taks Board

Last week I had the chance to run Rick Spencer’s Test Sprint. In Canonical-jargon a sprint is normally a 1-week workshop around a specific topic. In this case the topic was Automated Testing, hence my team was participating in the sprint.

As this was my first sprint at Canonical, I got thinking: what would be the best way to ensure a tangible outcome after a week of locking up 10 engineers in the same room? It seemed a good idea to borrow some SCRUM practices to organise the sprint. Here is a summary of what we did:

Read more of this post

Going Agile: Planning for the Demo and Planning meetings

Now that we are scrumming daily and we have agreed a 2 weeks cadence, it is time to start planning for the next set of meetings: Planning, Demos (Reviews) and Retrospectives.

Scrum has four meetings or ceremonies that you must do within a iteration. Here is how they are described by the Scrum Alliance

  • Planning: the team meets with the product owner to choose a set of work to deliver during a sprint
  • Daily scrum: the team meets each day to share struggles and progress
  • Demo/Reviews: the team demonstrates to the product owner what it has completed during the sprint
  • Retrospectives: the team looks for ways to improve the product and the process.

Show me the money!

The value in Demo meetings is that you get to see what the team has done and how it brings value to your customers. However, it is not as simple as it sounds… there are two things that can make a Demo inefficient:

  • Lack of preparation – people scrambling for demos, you hear things such as “it used to work 2 hours ago, but it is broken now due to work for the next iteration”
  • Old habits (die hard) – the tendency is still to ask people “did you finish?”, and  then tick the box, rather than “show me what you did?”

This is pretty challenging to do remotely, hence I have enlisted the help of technology. Read more of this post

Going Agile: Scrum in a fully distributed team

Working with a fully distributed team has made me appreciate the beauty of having face time with your team!  Hence, I took the opportunity at UDS to get more acquainted with my colleagues.

Scrum by DarkMatter

As a first part to introducing Scrum to the team, we defined the high level goals (or Epics) for the 6 month release cycle. Part of what I have been trying to figure out is how to use the tools we have at-hand to get started. For the 6 months sprint backlog, we finally settle on launchpad blueprints. We are basically using a planning project within Launchpad, that will have a milestone per sprint/release. By prioritizing and assigning blueprints against the milestone, we get the backlog view.

Back at Symbian, we started by setting up daily scrums and weekly iteration backlogs. However, once the machine had started we struggled to define long term goals. It is hard to get out from the 2 week mindset.

Hence, with HW certification team at Canonical, I decided to prioritise the longer term goals. This was made very easy by the regular cadence of Ubuntu releases. The next step was introducing daily scrums and a 2 week iteration cadence within the 6 months sprints.

Are you standing up at the other end of the line?

With a fully distributed team, introducing regular formalised communication seems on paper an easy win. However, the trick is in the implementation. How do you do it? We decided not to have IRC meetings, based on previous experience. Eventually,  people did not read the comments from others and waited until their name pinged in the IRC channel to post a pre-baked update.  Another option was to Mumble our way through it! Read more of this post

Agile – How and why does Scrum work?

As an agile methodologies SCRUM is pretty simple to follow. There are basically 3 roles , 4 ceremonies and small bunch of practices. So why does it work? let me take a game theory perspective to the how, in order the explain the why.

from wikipedia

Sprints: Deliver often!

A sprint is a unit of  time (in our team is 2 weeks) in which the team plans and delivers an increment of the product that provides value to the customer. Once a sprint finishes a new one starts, the 4 SCRUM ceremonies are held within one sprint.

Classic waterfall projects tend towards a big bang approach to delivery. For the customer and the supplier, it leaves a door open to last minute surprises: “this is not what I ask for, it is going a bit late, I am not paying you, we had to cut that feature…”  This might be represented as deflections by both sides (or players in a prisoner’s dilemma).

Tricking the other side into doing their part without you doing yours, (e.g. increasing your margin by cutting test effort and delivering bug-ridden software) can be  more appealing if the players are not likely to meet again (or at least not in the near future).

However, if these interactions are more frequent and longer lasting, the benefits of ongoing collaboration become more attractive. This approach to fostering collaboration is well argued by Axelrod and it is implemented by scrum in the ‘sprint’ concept.

Read more of this post

Follow

Get every new post delivered to your Inbox.