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!).
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:
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?”
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.
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”→
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.
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.
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.