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: Don’t Forget About The Future!

When working with Agile, make sure to define your long term strategy that gives direction to your product backlog.

The Ubuntu Certification programme follows the beat of the 6 monthly release cadence. In the certification team we run a two week iteration cadence.  It is a continuous delivery machine! The danger is for your ambitions to get stuck in the quick rhythm.

Regardless if I am working with a product or a service team, I found it important to set a clear vision to aim for. The constant cadence of Agile is normally riddle with changes in priorities. While this enables the team to remain flexible, I have found that can be confusing for the individual: “Tell me again why are we doing this?”

Having a clear vision or product road map doesn’t only benefit your team, but also your stakeholders. I often find that a lack of a shared vision creates a mistrust – “This iteration could be the last one. Quick, I better ask for everything I need at once! Everything is high priority!”, sounds familiar?

Sharing a common set of principles and aspiration to deliver great value is sometimes confused with the need to have a committed  two-year plan. To remain competitive, I rather stop second guessing the future and build working practices that allow for change and make people comfortable working with the unknown.

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

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

Why Is Change So Hard?

When a company is formed, individuals within must cooperate for it to succeed. As the company grows, the chances that not cooperating can be more rewarding for an employee are increased.

We are all too familiar with the examples of this behaviour: Developers short-cutting test efforts, delivery promises not kept at the last minute or the dreaded “office politics”.

If these situations can be described as iterative “prisoner’s dilemma” games between employees, then company cultures are established game strategies that provide the best outcome for the players. 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


Get every new post delivered to your Inbox.