Going Agile: Scrum or Kanban?

I have been using Scrum for a while. Back at my previous role, we tried using Scrum within the integration team that was creating the nightly builds and our bi-weekly releases. It brought good results, the team specially liked the visibility of the task board and the daily stand-ups.

We did found a bit artificial to have a cadence. We were suppose to put out a release every two weeks but we end up doing it as often as we could (or made sense), as we were not in control of when the new software was landing in our plate.

Since then, I’ve this nagging thought that Scrum might not be appropriated to service teams or teams with a large portion of maintenance/customer support work. I have found iterations shorter than 2 weeks, can be over burden by the demo, planning and sizing overheads. In the other hand, two weeks is too much time for teams with Service Level Agreements of days or hours. It also seems a bit cumbersome for short project (~1 month), were you end up with 2 or 1 iterations… What to do!?

In Canonical several teams have used Kanban in order to improve their development processes, so I started reading up on it when I stumbled on this excellent article on Kanban vs Scrum.

The author won me over straight away by not trying to decide which of the two practices is best but instead doing a great job at remaining impartial.

Looking back at the Symbian Foundation’s integration team it seems that Kanban would have been better suited. It retains the focus on making information visible while concentrating on reducing WIP. It seems better suited to a “specialist” team, where most members share the same skills and work on similar tasks. Scrum seems to work better for cross-discipline project teams.

Also, the emphasis on managing constant flow of work is one that resonates with teams that have a work “currency” measured in days of effort (bugs?) rather in large projects lasting months at the time.

While Scrum has been very successfully adopted by the Certification team at Canonical, My previous experience with the Integration team had stopped me from cheering on Scrum in teams that have a constant flow of work. Now, we are thinking on going Kanban! Don’t get me wrong, we are going to continue using Scrum. It is just a case of using the right tool for each job. I will keep you posted on how it goes.

If you have any advice, tips or gotchas that you could share with us, I would be most grateful if you could drop your comments here!

by the only anla — Time to try something new (by theonlyanla)

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.

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.

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.

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.

Continue reading “Agile – How and why does Scrum work?” →

SCRUM works better with the Symbian Foundation

Over the last few years, it has become more usual, and accepted as a good industry practice, the use of SCRUM as a team/project management methodology.

At the Symbian Foundation, we use SCRUM in our pdk build team. I have been recently pondering over what is the most efficient methodology for project management to use if you are building products out of Symbian Platforms.

Continue reading “SCRUM works better with the Symbian Foundation” →

SCRUM funciona mejor con la Fundación Symbian

Durante los últimos años es cada vez mas habitual ,y aceptado como buena practica, el uso de SCRUM como metodología de organización de equipos de desarrollo de software.

Nosotros, en la fundación Symbian, usamos SCRUM en el equipo que genera los “kits” de desarrollo como el pdk. Por esta razón, recientemente he estado reflexionando sobre cual es la mejor metodología de dirección de equipos y proyectos si estas trabajando con plataformas Symbian.

Continue reading “SCRUM funciona mejor con la Fundación Symbian” →