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!

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.

Mylyn – Why it is worth upgrading to Tasktop

I have been using Mylyn now for a while and it has been great to help keeping on top of large amounts of bugzilla entries. I’ve used it to manage the integration plan for the Symbian platform, which describes the expected contributions into the platform.

One of the benefits that Mylyn offers developers is the reduction on Context Switching. Context switching is not only costly for software programs, but also for humans working on concurrent tasks. Mylyn provides a great integration with the IDE that allows developers using Eclipse to substantially reduce the wasted time on switching between application and work tasks.

However, I am not a developer… so Mylyn did not really provide me with any improvements in this area. Hence, I decided to download the Tasktop 30-day-trial standalone version and see if I could have get some time-saving by exploring the additional features for “Task Context”.  Here are the results:

The first obvious advantage is that it doesn’t really load all the rest of Eclipse/Carbide functionality that I don’t use and that eats a substantial amount of my manager’s-spec laptop memory. Hence, the first improvement is better working speed!


Read more of this post

Risk Analysis – Integration plan (part 2)

Every person has a different risk profile. This is the willingness of that person to take a chance to achieve a reward versus the probability of failure. The amount of risk we are willing to take seems to be correlated to the reward promised and the time frame associated to it (i.e. will I get teh reward tomorrow, in 2 or 10 years). Risk profiles of companies are somehow a weighted average of the risk profiles of their employees. Hence, different companies (even in the same market segment) have different risk profiles. Read more of this post

Integration Plan (part 1)

Recently I blogged about using Bugzilla to track features. I am happy to report that things are moving forward really well thanks to the community and Mylyn. We now have created the high-level delivery plan for Symbian^3 in Bugzilla, and completed the details for one of the key features: New Graphics Architecture (NGA – aka Screenplay).

intp3

As you can see from the picture, Mylyn makes it really simple for anyone to keep an eye on the plan.

BUG_ID 176 is the top level entry for NGA. In this post, I won’t go into the specific details of NGA, but explain the next step that we are taking in our planning: The Integration Plan.

Having all this data in Bugzilla allows us to build a good view of  the progress of a specific release. As we do not want to be monitoring every single submission, we have decided to follow the implementation of  “Key Features” (we are currently discussing the key features for Symbian^3)

The aim is to extract all the good information provided by the package owners and put into a format that facilitates the analysis of the health of the release. Taking a leaf from the Agile book, and introducing a 2-week regular heartbeat for our kits releases and tracking feature increments against it (for regular kit updates click here).

Also, any data beyond 6 months from “today” is displayed in quarters since we need to remain flexible and responsive to change (a “scaling agile” practice). Hence, it is understood that the detailed plan beyond 3 months will be fluid and beyond 6 months is only an indication of intent.

It is  probably worth noting at this point that the integration plan is based on voluntary contributions, and that we aim to increase the confidence in it by promoting frequent stage deliveries and asking the contributors to provide regular updates when changes occur.

intp1

The above table is a section of the full integration plan for Symbian^3

Read more of this post

Using Bugzilla to track features

One of the areas that we are currently working on is the use of Bugzilla to track and manage the integration of new features into Symbian Platform Releases. I have set-up a few examples of real features in Bugzilla for Symbian^3. Here is how we are proposing to use it:

mylyn

Read more of this post

Follow

Get every new post delivered to your Inbox.