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 , ,

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 , ,

SCRUM works better with the Symbian Foundation

July 6, 2009 2 Comments

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.

Read more of this post

Filed under Scrum Tagged with , , ,

In Denial? It is only human…

June 23, 2009 Leave a comment

Before I joined the Symbian Foundation, I was working on improvement programme for Nokia. During that time, I learned and observed the impact of change in people.

Theory says that a person normally goes through 4 stages/moods before it fully embraces the change. The first two stages consist of denial: either that the change exist all together or that, even when we accept its existence, it is going to impact us at all. This is also true of communities migrating from a close to an open source model.

While, technical changes are easier to accept, the hardest challange remains in encouraging ‘once upon a time’ customers to now be equally responsible for the development of the platform and reminding suppliers that are no longer bound by SLAs, only by common sense.

In a way, that is probably why open source projects with one major member contributor and many users, that limit their collaboration to minor updates, seem easier to accept (maybe because they feel more familiar). However, what are we really trying to achieve by going open source? Will this really unleash platform innovation?

The next stage to denial is exploration. When you start asking yourself what opportunities I can seize if I jump deep into this change. Is it possible that by investing some resources into improving the Symbian Platform I can open up larger opportunities for me and my company?

Start planning what contributions you need to make in order to enable your business model. You can not assume that someone else is going to do it for you, as everyone scratches their own “itch”. You can hope that you will find common ground with other contributors, allowing you to share the “scratching” cost. Recognising the advantage to the community of coordinating “scratching” efforts, the Symbian Foundation has set-up a centralise Release Management and Planning function. We are a growing team of 4, currently working towards building delivery plans for Symbian^2 and Symbian^3.

I guess the last stage is when the change feels so natural that you can not even imagine how you use to survive doing things the “old” way.

Filed under Scrum Tagged with , , , ,

Newer posts →

Follow

Get every new post delivered to your Inbox.