Going Agile: The Ultimate Scrum Google Doc Template

February 23, 2011 5 Comments

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

Filed under Scrum, Tools Tagged with ,

Going Agile: A few iterations under the belt

January 7, 2011 Leave a comment

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

Filed under Change, Scrum Tagged with ,

SCRUM can help you running workshops

December 14, 2010 Leave a comment

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

Filed under Change, Scrum Tagged with

Going Agile: Planning for the Demo and Planning meetings

November 16, 2010 4 Comments

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

Filed under Scrum Tagged with ,

Going Agile: Scrum in a fully distributed team

November 11, 2010 4 Comments

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

Filed under Scrum, Tools Tagged with , ,

Mylyn – Why it is worth upgrading to Tasktop

December 9, 2009 1 Comment

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

Filed under Tools Tagged with , ,

Agile – How and why does Scrum work?

November 19, 2009 Leave a comment

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

Filed under Change, Scrum Tagged with , ,

← Older posts

Newer posts →

Follow

Get every new post delivered to your Inbox.