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). Continue reading “Going Agile: A few iterations under the belt”

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:

Continue reading “SCRUM can help you running workshops”

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. Continue reading “Going Agile: Planning for the Demo and Planning meetings”

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! Continue reading “Going Agile: Scrum in a fully distributed team”

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.

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”