The Only Question To Answer At The Daily

How awesome is your Daily Scrum? Does it fall flat or does it launch the day, generating energy?

The Daily Scrum is to me the most important meeting of the day. The impact of this super short gathering is immense. How many times did we discover that we weren’t on the right path, that two people were actually working on the same task, that oh, yeah, it’s actually quite cool to talk to each other!

I could write pages and pages of key moments that happened during the “Daily” that saved us from actual (or future) difficult situations.

Continue reading about The Only Question To Answer At The Daily

Tags: , , , , , , , ,

A first try at LeSS (Large Scale Scrum)

Team Lego is one of the five teams currently working at Liip Zurich. All team members work together on one, long standing project. Over the last year the team has grown and changed. In the end, we were 10 people working together as one single Scrum team. It worked really well – until it didn’t.

Very slowly over time things stopped going as smoothly as they used to. The team couldn’t finish their sprints and the velocity was going down. The sentence most often heard at the Daily Scrum was: “I don’t know what’s up with this ticket, person X is working on it” – a sign of “Gärtlidenken” as it is called in Switzerland. Information wasn’t flowing as it should, even though we used the ‘Walk the Board’ approach to keep Daily Standup meetings short and focused. Other Scrum meetings were long and inefficient and any further growth of the team was entirely out of the question.

This interesting blog entry about the numbers behind Jeff Bezos’ two pizza rule for team sizes suggests that the problems the team were facing were possibly due to its size. Communication between all the people involved was complicated and it’s impossible to know what’s going on everywhere all the time. People focussing solely on the one task they picked is a logical move to push this problem out of sight. Yet, it is counterproductive for self-organising Scrum teams. It decomposes a team back to a group of people which happen to work next to each other on similar tasks rather than working together at achieving a shared goal.

Even though team Lego cannot be considered a very large team, problems were just around the corner. At 10 people, we were probably only beginning to see the problems that a larger team could bring. However, it’s always better to act before the horizon’s problems arrive at your door.

Continue reading about A first try at LeSS (Large Scale Scrum)

Tags: ,

Glad, Sad and…

Most Scrum Masters know the ‘Glad Sad Mad’ retrospective exercise. In the non native english speaking world, people trying out this exercise usually struggle to distinguish between ‘Sad’ and ‘Mad’. In every retrospective where we did this exercise I ended up with several stickies on the line between ‘Sad’ and ‘Mad’.
I tried to make it clearer by rephrasing the words to something more suitable that all of the team members would understand (like ‘I can’t take it anymore’ instead of Mad and ‘Get stuff off my chest’ for Sad for example, see this blog post by Mike Pearce). Although it helped, I still felt that the distinction was not 100% clear to everyone. Frankly, I got tired of having to explain it over and over again.

In a retrospective a few weeks ago when lots of those ‘in between’ stickies were placed on the wall we joked about making a new column for them. During that retrospective I noticed that a lot of the time my team was talking about things that came as a surprise to them that had an impact on the sprint or their feeling towards the project and things that they were scared of that could threaten the project or fears they had about the project’s current status. So I decided to add more columns reflecting that and came up with ‘Glad, Sad, Surprised, Scared’.

Retrospective vs. Futurespective

Adding a ‘Scared’ column opens up the possibility to also talk about fears for the future, which is usually not part of a retrospective but rather a futurespective. However, these fears typically uncover risks and uncertainties relevant to future planning. It also helps me as a Scrum Master to better understand the team’s feelings. Few people will talk about what actually scares them on their own. During the exercise I observed that once someone put a sticky in the ‘Scared’ column, others followed. Of course most of the stickies covered the same topic. But simply realising that they all share the same fear helped them to see that it’s not just their own private problem but that everyone feels that same way and that they actually needed to do something about it.

Surprise!

One can argue that stickies placed in a ‘Surprised’ column would also fit in the ‘Glad’ or ‘Sad’ columns and that’s true. And of course, stickies in that column cover a very broad spectrum of topics. But the value of this column is twofold.
Firstly, it helps to uncover things that arise unexpectedly – both in a positive and in a negative way. This way potential impediments can be spotted and dealt with or it can help to find out why a sprint failed (similar to the ‘Expected and Surprised’ retrospective).
Secondly, ‘I am surprised that…’ often uncovers a richer seam of information than simply ‘Glad’ or ‘Sad’. It allows discussion about why it was surprising and how the person feels about it. Software developers tend to primarily add stickies like ‘Sad about the slow server.’ or other very technical problems on the board. I felt that the ‘Surprised’ column opens up a way to illuminate the other, more personal side of problems which helps the team members to better understand each other and their connection as a team.

Try it out and tell me what you think!

Tags: , ,

Your Retrospective Sucks!

People fall asleep in retrospectives or have bad temper? They do not like to share their thoughts – if they have any?
Maybe you are trapped in repetitive rituals and would like to do something about it? Last Wednesday I had been attending the Agile Breakfast in Zurich
titled “Organizing Retrospectives Effectively” with fellow-Liiper Christoph Meier.
Marc Löffler was going to address how we can make our retrospectives
better.

The event was organized by the Expert Committee “Lean, Agile, Scrum” of SwissICT. Many thanks for educating us in such
a splendid way!

Marc started with a slide that said:

Your Retrospective Sucks!

I was suprised – and not quite sure how to deal with what I had
read. Then I had to laugh. It’s good not to lose one’s sense of humor.

The slide’s subtitle read: “…and what you can do about it”.

By the way, Marc’s slides are available on slideshare.net if you care
to have a look.

For this blog post I was looking for some images of meetings. I
stumbled on this one: “The Indians giving a talk to Colonel Bouquet”

img

Source: wikimedia.org

Doesn’t that meeting look interesting? Nobody is falling asleep.

Wouldn’t we want to have more retrospectives like that? I mean,
we’re not fighting wars like the proponents on the image did. But we’d
like to have purpose, and engagement, and …

What can we do?

Marc gave three reasons why retrospectives suck:

  • too much and unfocused talking
  • repetition
  • no effect

As time passes, retrospectives often get less interesting (Marc’s
slide):

Source: slideshare.net (slide by Marc Löffler)

We all like to pick the low hanging fruit first. Are we prepared for what comes after that?

img

Source: dilbert.com

The worst retrospectives are those that show no effect. Nobody looks
forward to such meetings.

Marc was going to cover three elements to address this:

  • Purpose (know)
  • More Fun (enjoy)
  • Systems Thinking (understand)

Purpose

To get the purpose back into the retrospective, Marc wants us to
experiment. Your first reaction to that might be like mine: “Yeah
sure, that’s going to ruin it totally. No structure ‘n all. Just
trying stuff!'”

But that wasn’t what Marc had in mind. He was talking about
old-fashioned experiments (you know, Newton or Tesla and those
guys…):

An experiment is an orderly procedure carried out with the goal of
verifying, refuting, or establishing the validity of a hypothesis.

So in the 1st retrospective we would start with a hypothesis, for
example:

If we go to work on-site with the client we can have a better common
understanding and therefore we will have less disagreements with the
client.

Time passes and we have the 2nd retrospective where we do a
reality-check: could we verify our hypothesis? Did things turn out
like we thought they would?

No, we had even more disagreements with the client!
What we assumed turned out to be completely wrong.

But that’s fine. That’s the agile way. We learn. Remember: “Inspect
and adapt”. We refuted the validity Hypothesis Nr. 1. We then form a
new hypothesis. We will verify that one in the 3rd retrospective.

So that’s Marc’s way to bring back the purpose: through experiments we
approach our issues with methodology and our retrospectives should
become more effective.

We shouldn’t be thinking in terms where we already expect the “solution” to work.

More Fun

Now we come to the More Fun element.

img

There are endless possibilities. Marc presented some pointers to get more fun into
retrospectives:

  • Retrospective Cookies

img

  • Change the Location

img

Source: wikimedia.org

and most importantly (in my opinion):

  • Metaphors

To do this we set the stage by choosing a metaphor we’d like to
use. When Marc asked us for ideas, Christoph Meier suggested
to make a Construction Site Retrospective.

When your metaphor-based retrospective starts, you collect terms that
belong to the metaphor. Everyone should try to stick to these terms
when talking events that took place.

So for example, if the hosting provider for you new website was late
with giving you access you would say:

“We couldn’t get to the construction site for four days because it was
locked and the owner was on holidays. We are running late now. We
should have completed the basement last week.”

Or if the requirements for a feature were not clear enough:

“The architect said that the wall should be 10 feet and I made it
so. But now the whole building is too wide!”

The benefits of such metaphors are (quoting Marc):

  • Thinking outside the box
  • New, creative ideas
  • “Distance” to real events
  • Fun!

Systems Thinking

Last but not least: we should be trying to understand the system we
are dealing with. We need to know which buttons to push. We don’t want
to press the wrong buttons! Teams are not endpoints but nodes in a
system.

Assuming someone is sick, the doctor analyzes the given symptoms to
find the cause. If only the symptoms are treated, the patient cannot
get truly healthy. That’s why the doctor looks at the whole organism
so he is able to identify the root cause, which might not be directly
related to the observed symptoms.

In our environment, we want to know how the different factors (like
the client, the team’s morale, the budget etc.) influence each other.

If we forget to consider important factors, we can probably not solve
the issues at hand very well.

The approach suggested by Marc to understand the “system” is Systems
Thinking
.

An example to do this is by using a Causal Loop Diagram:

img

Source: isixsigma.com

In this case we can see how individual aspects influence other aspects
in a wanted or unwanted fashion by having an increasing or decreasing
effect.

I believe we often focus too much on short-term problems and lose the big picture.

Closing

It was inspiring for me to hear about these options. I would like to
add that Marc has written a book on the subject called
Retrospektiven in der Praxis: Veränderungsprozesse in IT-Unternehmen
effektiv begleiten (in German only). I will hopefully read it soon.

Please contact me or Christoph Meier if you would like to share your
experience, have questions or corrections to make.

On the 26th of June we will be celebrating the grand opening of our
new office in Zurich. There will be an agile session “Agile – to be,
or not to be” in the afternoon where you can even meet me in person.

See the announcement for further details (and to register for sessions).

So long, see you later!

… and thanks to Christoph for helping me with this text.

Tags: , , ,

How team Fri-Bar does Scrum at Liip – Part 2

This post forms the second part of a two part blog post about how team Fri-Bar does Scrum. For the first part, go here.

Artefacts

At this point I’m going to digress from explaining the Meetings (yes, there are more!) and talk instead about the Sprint itself.

The Scrum Boards

4857167851_a98195f15f 

The Scrum Boards are the most important artefact (in my opinion!) in Scrum.  We have a total of four boards in our team: two Sprint Boards, one board for Support Friday, and one information board.   I found myself standing in front of the Scrum boards in the mornings, which gives me a feeling for how we’re going, and for a long time I couldn’t figure out what it reminded me of, but eventually I realised it was the exact same way that the surgeons in Grey’s Anatomy stand in front of the surgery board (yes, I know I am admitting to having watched Grey’s Anatomy – no judging!)

Sprint Boards

The Sprint Boards are for tracking where we are with the User Stories in the current Sprint. They’re a portrait-style board (we use whiteboards), divided into three columns – backlog, in progress, and done.  After Sprint Planning II, I stick all the User Stories and their tasks (on Post-It Notes) into the backlog.  These are in descending order of priority.  We have two Sprint boards because with a big team and 2-week Sprints, one was not enough.

Support Board

The Support board is basically just a mini Sprint board, for all the tasks we have coming up, in priority order.  We only use this board on Fridays although I stick new tasks to it as they come in from our Support Team.

Info Board

The Info board is also important.  There are three main things on the Info board:

The Sprint Burndown Chart

At the beginning of the Sprint, we know we have some amount of Story Points to burn through to reach our goals (we don’t include nicetohaves here).  Say 50 points.  I make a little graph, with Story Points on the y axis, and days on the x axis.  Each day after the Daily Scrum Meeting (more on this in a little bit), I plot how many Story Points we’ve managed to finish.  I only track completed User Stories, for example if we have a 4-point story that is half done, I burn down 0 points for it, not 2.  The Burndown Chart is a great way for everyone to see how we’re progressing through the Sprint.

The Velocity Chart

The Velocity Chart is another interesting graph, but this one measures our progress over a longer period.  The velocity is how many Story Points we manage per sprint.  We don’t include any Story Points from any failed User Stories, but we do count nicetohaves.  I usually also plot a bit more information in different colours:

  • Committed-to Story Points (doesn’t include nicetohaves)
  • Achieved Story Points
  • Person days in the Sprint

It’s unfortunate that we have the last one – a Scrum team should really be consistent each Sprint, but since I’ve been Scrum Master over summer, we’ve had people on holiday, and this number has fluctuated quite a lot.

The Product Owners tend to carry in their head the ratio between time and story points (read: money) for budgeting reasons, but I force myself not to think about this.  I actually really like the abstraction of Story Points.  At any rate, this tells me how efficiently the team are working and whether we’re improving, and it helps us figure out how many Story Points to commit to in a Sprint, while at the same time helping the people who have to keep track of budget.

The Calendar

I’ve recently started drawing up a mini-visualisation of the days in the Sprint on the board (we tend to divide up boards using bright blue tape), and then everyone can stick Post-It Notes there for days they’ll be off or out or have something else to do.  In our next project we’ll have two team members coming from Zürich, so it will be a good way to get a quick overview of who is when, where.

Other Miscellaneous Information

We also track things on the Info board like the DDOD (Default Definition of Done) – that is, unless explicitly stated, what needs to happen for a User Story to be done.  This usually has at least:

  • Code committed to version control
  • Deployed to development servers
  • Documented

Our team has a 5 CHF penalty for being late to the Daily Scrum, so we also track debts on the Info Board.  We give our penalty money to http://www.kiva.org/

The Surrounding Walls

One of the projects we’ve worked on this year had a lot of printed material which we stuck to the walls.  This included flow charts and screen shots, and I found having these visually available through the whole project to be incredibly useful.

Meetings Part II.

Yes, back to the meetings

The Daily Scrum

The Daily Scrum is probably the most famous meeting, and in teams which are starting out doing Scrum, it’s usually the first one to be adopted. The Daily Scrum is a “stand up” meeting, to make people keep it short.  We have a talking “stick” which is actually a pony, which we pass around, while we talk about:

  • What we did yesterday
  • What we’re going to do today
  • Any problems we’re having

The Daily Scrum meeting is theoretically the only time that Post-It Notes get moved between backlog, in progress, and done.  I say theoretically, because it does happen that someone finishes their day’s work quickly and moves another task from the backlog into in progress, but the important point here, is that we don’t move tasks into Done without transparency to the rest of the team.  When a task moves from the backlog into in progress, the person taking it has to put his/her name on it.

As I said, one of the most important things about Scrum is self organisation.  This means that people need to work together to get a User Story done, and the Daily Scrum is the time to figure out the best combination of people to do this.

When we started, we were doing what I would later learn is called “Water Scrum”.  Water Scrum is when you have almost the entire Sprint in progress at the same time.  It is named after the Waterfall method, which Scrum is really supposed to be the antithesis of.   The problem of Water Scrum is also of course the same danger of Waterfall, which is that if you have everything in progress, but nothing complete, when time runs out, you fail everything, rather than just one or two features.  We aim as much as possible, to complete User Stories before starting the next ones.  This means if we run out of time in the Sprint, we will at least have some complete User Stories.  It’s very difficult to not do Water Scrum with a large team, because it’s really quite unfeasible for 9 people to work on a single User Story, but we do try and minimise it wherever we possibly can.

At the Daily Scrum, we also track the completeness of whole User Stories.  If all the tasks for a particular User Story are moved into done, that means the story is complete, which means that someone has to take responsibility for re-reading it, testing it in the environment that we’re targeting for demonstrations, and ultimately, demonstrating it to the Product Owners in the Sprint Review.  We mark tasks as complete with little green arrows that we stick on the User Stories, and at this point write the name of the person responsible on the arrow too.

Another thing that can happen in the Daily Scrum, is that we realise something is blocked.  This might be for technical reasons, like not having access to a server, or something else, like we need more information from the client.  To indicate this, we stick a little pink arrow (as close as you get to red in Post-It world) over the task (or User Story) to make this very obvious as well.

As you can see, we do Scrum in an extremely visual way.

Sprint Review

The purpose of the Sprint Review is to demonstrate, and ultimately get acceptance, of all the stories in the Sprint.  To set up for this, I pull down all the stories off the Sprint Boards and take them, with my laptop into a meeting room with a projector.

The Product Owners both attend the Sprint Review, and we go through each story and talk a bit about it and then demonstrate it for them to see.  The person who has been designated to be responsible for each User Story now demonstrates it to the Product Owners.  The Product Owner is usually given the printed User Story for reference during the demonstration, and then signals whether they accept it or not. I keep track of all this and then follow it through in JIRA by closing issues.  Failed issues usually go implicitly into the following Sprint, but they’re often completed in the same afternoon as the Sprint Review before the next Sprint even really starts properly.

Sprint Retrospective

The final meeting in the Sprint, and the one I personally think is the most interesting, is the retrospective.  This meeting is for the team (which includes the Product Owner Assistant, but not any representatives from the client) to discuss how they felt they worked during the last sprint and what they want to change or improve.  In the future we may try this with the customer Product Owner included as well for more transparency.

We do this by writing on green and pink Post-It Notes how we felt – green for things we were happy with, and pink for things we weren’t so happy with.  This is timeboxed to 2 minutes.  Then each person gets 2 minutes to go and put their Post-It Notes on a board and talk about what they wrote and explain anything unclear.  After that, I group together the pink Post-Its into themes – technical, organisational, communication, etc.  Depending on how many themes they are we allocate points to mark which we think are the most important.  For example, if there are 4 themes, we might say, each person has 2 points to distribute however they want, and everyone comes and makes marks on the whiteboard next to the themes they want to talk about (yes, you can put all your eggs in one basket).  We then pick the theme with the most points (or sometimes the top two), and spend another set of 2 minutes writing (green for constructive) suggestions on how we can improve, and then another 2 minutes for each person to talk about their suggestions.

The retrospectives are framed to be a safe place to honestly discuss how you feel that the team and the project are going.  My team is really good at both honestly discussing things we’re unhappy with, and finding constructive ways to try and change these things.  For example, all the different things we’ve tried to make the Estimation Meetings more efficient have come out of conversations during the Retrospective.  We’ve also changed times of meetings, workflow items to do with testing and quality, helped our Product Owners write better User Stories and in one case, agreed to “tell the Scrum Master to stfu when she needs to be told” :)

A final note on Meetings. We tend to have Monday as meeting day. This means that Monday morning is spent doing final testing of the User Stories you’re responsible for (remember the green arrows!), trying to finish any nicetohaves, and preparing for the Estimation Meeting by reading through the stories in advance.  Then after lunch, we have Sprint Review, then Estimation Meeting, Sprint Planning I and if we can, Sprint Planning II.  That’s usually 4 hours of meeting on Monday afternoon.  Tuesday morning we can do the Retrospective before starting work on the next Sprint, and it gives me time on Monday after all the meetings are done, to prepare the board.

The Awesome Things

From the client’s perspective, I think having a strict methodology that we adhere to impresses our clients, and because the requirements are described by them in “user terms”, they tend to get a system that works how they expect from the user’s perspective, rather than the developer’s perspective, which is certainly a typical problem we need to avoid in software development.

I suspect they think we spend too much time in meetings, but in reality they’re not paying for some Business Analyst to spend months writing a 400 page specification we can’t parse anyway, so this works out well.

Additionally, because we work in Sprints, we can react much faster to changing requirements.  In general writing a 400 page specification before a project starts is a procedure that lends itself to being completely unable to adapt quickly.  Describing things in User Stories is good, because we only plan the current Sprint out, and the Product Owners are free to change stories and priorities right up to the point where we have the Estimation Meeting and start planning the Sprint.

Scrum says that once the Sprint has started, the Sprint Goals are fixed and can’t change.  In case of emergency, Scrum tells us that if the Sprint goals must change during the sprint, then we should throw the whole Sprint out and do the Planning again. In reality we had this happen once, but it was only affecting one or two User Stories, so we stopped people working on those until the issue was resolved, and they just worked on other stories in the meantime.  I do have to be quite careful about not letting things creep, or Product Owners putting new tasks in to the current Sprint, because that affects the commitment that the team makes during Sprint Planning I.  If it’s really critical we can usually make an agreement that they can add a new User Story if we remove one with the same number of Story Points, but we should re-get the commitment from the full team if this happens.

I have obviously “drunken the Kool-Aid” when it comes to Scrum.  I’m totally convinced that it’s awesome.  I love the visualisation of all the data, that is in traditional projects, just transparent to Project Management.  I think the importance that is placed on empowering the teams to be responsible for how they work and improve is fantastic.

The not-awesome things

There are none! Actually the only not-awesome thing is that I have become completely unable to do anything at all without Post-It Notes! ;) I carry them with me all the time in case I need to brainstorm something.

Tags:

How team Fri-Bar does Scrum at Liip – Part 1

I became Scrum Master in team BAR in Fribourg back at the start of June, and over the last 3 months I’ve learned a huge amount about Scrum and I’m really happy with the way my team are working.  Since I have contact with a wide number of people, both in the open source world, and people I’ve worked with in previous positions, who are interested in Scrum, I thought I’d write a blog post describing how we work, and what I like about it.

Roles

Scrum Master

The primary role of the Scrum Master is to make sure that the whole team adheres to the Scrum Methodology. They are also responsible for removing impediments that stop the team working.  In practice this means that I have to move the meetings along,  make sure that the Sprint goals stay consistent and help the team do whatever is necessary to achieve them.

The Scrum Master can be a programmer in the team, and I am, although depending on the size of the team and project, how much I can really do varies quite a lot.  During the last project, we had a big team of up to 9 people and I didn’t get much chance to do any programming, but instead was just doing code review and helping people solve problems.

We tend to have senior developers taking on the Scrum Master role, which means that often the Scrum Master tends to be a bit of a technical lead.  Many people think that isn’t ideal for a Scrum team, and for good reason.  Ultimately I think it’s ok, and has been working well in our team, as long as the Scrum Master doesn’t take on large tasks that would cause them to lose focus from their duty as Scrum Master, because that is of course their primary role.

Product Owner

The Product Owner role is actually split in two – the Product Owner, who is from the client, and an internal Liip “Product Owner Assistant”. My main Product Owner Assistant has been David Buchmann.  The role of the Product Owner Assistant is sort of the flip side to the Scrum Master.  While the Scrum Master takes care of the interests of the team, the Product Owner Assistant’s responsibility is the product, and the Product Owner at the client.

The Product Owners are responsible for creating the backlog of User Stories for the team.  This backlog must be prioritised and each User Story must be small, complete, understandable and non ambiguous. In other words, ready to start work on.  Basically, the Product Owners together are responsible for the functional description of the product the team is going to build.   These User Stories are typically something like: “As a <type of person>, I want to <describe functionality>, so that I can <purpose>”, with a further description of functionality and acceptance criteria.  It’s important that these are completely non-technical in nature.  The Product Owners have to take decisions about the right way for a particular feature to behave and must be available for the team if some ambiguity arises.

The relationship between the Product Owner Assistant and the Scrum Master is an interesting one, and I think one that David and I managed to figure out to a really good degree.  There must be a huge amount of trust and respect between these two people, the Product Owner Assistant must trust the Scrum Master to be able to make sure the team is working efficiently in a way that will result in high quality work, and the Sprint Goals being met.  The Scrum Master must trust the Product Owner Assistant to make sure all the requirements are expressed and the functional implications of everything has been thought through.  Of course this follows through in both directions to the Product Owner at the client as well.

Team

The last role is the most important one – the team.  The team are the people who build the product and are responsible for demonstrating the features they built to the Product Owner(s) at the end of each Sprint.  They should self organise and figure out the best way to allocate and take tasks on to reach the Sprint Goals.  When I first became Scrum Master, it was very difficult for me not to suggest what they should work on, and over time I tried to really force myself to not do this, but instead encourage them to self organise.  In that way the role of Scrum Master is really like a facilitator.

In our main project over the last three months, we had two external developers from the client as part of our Scrum Team.  I was very impressed with how well these two were integrated – they were 100% part of the team, just as much as any of our internal developers.  I think Scrum is a huge part of why it worked out like that. They took part in all the meetings, paired up with internal developers to work out hard problems, and were just as responsible for the Sprint Goals as anyone else.

Meetings

The life of the project is divided up into Sprints.  We’ve done both one week, and two week sprints, and I personally think two weeks sprints are ideal.

In order to keep our team focused on the Sprint, all support tasks and maintenance issues for older projects get pushed to “Support Friday” (assuming they are non-critical, but we do have a support team to deal with critical stuff as well, and they only escalate issues that need developer help to us). This has been quite a revelation for me, as I was always one of those people who were working on, or responsible for, about 8 different things at once, and finding the time to really get a deep focus has been very difficult.  Of course in my role as Scrum Master, I don’t really get much opportunity to get this deep focus anyway, as I’m always running about helping people and removing impediments, but at least that way, the rest of the team is focused during the Sprint, except for Fridays, which are dedicated to multi-tasking and distractions anyway.

During the Sprint, there are a number of meetings.  To the uninitiated, it seems as though Scrum is very heavy on meetings, but in reality I think the cost is worth it because of the time savings of everyone knowing what we’re doing. And most of the up-front project planning is removed with Scrum, saving quite some time and costs.

Estimation Meeting

The Estimation Meeting is about going through the backlog of User Stories that the Product Owner or Product Owners prepared, and discussing them to a point that the whole team has understood them, and then estimating each story. The entire team, the Scrum Master, and both Product Owners attend this meeting.

The User Stories are estimated using some arbitrary scale called “Story Points”.  We’ve completely stopped doing time estimations in our team at all, which felt extremely weird to start off with, but is now fantastic.  A Story Point is some relative scale of “amount of effort”.  We used to rate them on “complexity”, but have since realised that some things are not complex at all, but still take a long time, so we stabilised on “effort”.  These must be relative to each other, and usually we achieve this by taking some reasonably small story and calling it a 3.  Then everything is estimated relative to this.

 

We do the actual estimations using a technique called Planning Poker.  Every team member (except for the Product Owner, and I usually stay out of it too unless I’m really working as a developer on the team), has a set of cards with a number on each one.  The numbers start off following the Fibonacci sequence until 13 at which point they deviate to 20,50,100. We also don’t have two cards with a 1, so it’s not true Fibonacci. Then we have a ? card and a K card, which mean “no idea” and “coffee break!” respectively.

We have the current User Story up on the wall somehow, either projected or a printed version, and we all read through it and discuss it until we’re ready to estimate.  Each person throws out a card when they’re ready (number face down) and then they all flip them over together.  This is to ensure that, for at least the first round, people are not influenced by the opinions of everyone else.  We then pick out the person with the lowest and highest estimates, and get them to justify their case.  This usually leads to a good discussion, and then either eventual consensus (with or without another round of throwing out cards), or if it seems like it’s going on too long, or is unlikely to reach consensus, I stop it and we take the highest estimate still on the table.

When we first started, Estimation Meetings were really taking a long time, and we have tried a number of approaches to make this more efficient.  I don’t think we’re there 100% yet, but we’ve certainly improved.  We usually have our estimation meetings in the afternoon, and have so far tried:

  • The whole team individually reading through the User Stories to be estimated in advance (the morning of the meeting) and asking clarifying questions to the Product Owner.
  • The team dividing into pairs and reading through a percentage of the User Stories in advance
  • The team dividing into pairs and reading through all the User Stories in advance

All of these have pros and cons, and we seem to have settled on the third, since it has the best way to promote discussion (pairs) but also still prepares everyone to be able to estimate all the User Stories.   However, this point really highlights the need to have very clear User Stories in the backlog. We have definitely learned that we need to work with the Product Owner a lot to help them write User Stories in a way that we can easily estimate without meetings that take forever.

This also means that the internal Product Owner must be able to push back against the Product Owner at the client, to force them to make decisions and have all the information we require ready before we start.

Sprint Planning I

The next meeting is Sprint Planning I, which tends to go pretty fast.   This usually follows directly after the Estimation Meeting (with a quick coffee break in between to give everyone a rest). The purpose of Sprint Planning I is to define the goals for the forthcoming Sprint.  Since we’ve had the estimation meeting by this point, and usually know how many story points we can fit into a Sprint (more on this later), this is usually very simply done by just putting the next n highest priority stories into the upcoming sprint, to a point where the team can commit to the Sprint Goals without feeling overloaded.  There’s usually a bit of to-and-fro-ing at this point to decide exactly how much we think we can take on, but it’s quite straight forward.   We also put a couple of extra User Stories into the Sprint, but call them “nicetohaves”, which means they get planned out as well, but we only start them if everything else is done early, and we don’t fail our Sprint Goals if we don’t get to them, or don’t complete them.  The nicetohaves are usually the next highest priority stories that would go into the next Sprint.

Sprint Planning II

After Sprint Planning I, I usually rush off to my computer while everyone else gets coffee, and print out all the User Stories that have gone into the next Sprint.  We use JIRA for tracking all of this, although it’s usually not used by the team at all, just by David and I for tracking and reporting.  Pierre wrote me a Javascript “bookmarklet” for Firefox, which takes a JIRA page and formats the most important information in a nice printable way.

The team and I are now ready to go into the next round of Sprint Planning, which is technical, and therefore doesn’t involve the Product Owner, although they must be available to answer functional questions as well.  To do this, we go into a meeting room with the printed User Stories and a pack of Post-It Notes.  For each User Story, we try to list all out the technical tasks (one per Post-It Note) required to complete the User Story.   I usually write the JIRA issue number, which is on the printed User Story, on the top of each Post-It Note and then a summary of the task.  For some reason they really don’t stay attached to the whiteboard, and each morning I came in to have to put them back on the board.  We now actually use sellotape to attach each Post-It Note, which I find infuriating.

At the end of Sprint Planning II, we therefore have a number of Post-It Notes for each story, and I’m ready to prepare the board.

For more about the Scrum board, and the rest of the Scrum Artefacts and meetings, stay tuned for the second part of this blog post!

Tags:

Techday Slides: Management of medium and large size projects

Memi talked about the challenges in Management of medium and large size projects. It’s not all that obvious and some eye-opening stuff for the not so experienced in project management people was in there. Less techie than the other talks, but important for successfull technology projects even more so. Get his slides.

Tags: , ,

Growing Liip’s Knowledge

Being hopelessly transparent just is in our genes, so here’s another post on liipy internals – this time on our recent training spree.

→ Situation: As you might have guessed, we’re currently continuously growing in size and power. Well, size is one thing – power needs knowledge.
→ Approach: Workshops with entire project teams on a subject highly relevant to their work, with an expert able both to explain the theoretic foundations as well as to give clear and concrete advice on the code level.
→ Action: The following guys came by, helping us big time:

Luke Hubbard at Liip

Luke Hubbard (pictured above, from codegent, UK), in his role as a core developer of Red5, the Open Source Flash Server we use in our real-time multi-player gaming apps or for fancy stuff like multi-user video chat / streaming. Luke spent two full days with some of our Flash/Java folks, sharing a great deal of knowledge in the architecture and efficiency area.

Saban Ünlü (netTrek/Adobe, DE), one of Germany’s most prominent Flash/ActionScript gurus, also spent two days at Liip Fribourg, discussing best practices in advanced ActionScript development, specifically when it comes to games, and helped introduce an Eclipse/FDT-based Flash development process, which finally brought us a serious development environment for our Flashy endeavors.

Peter Stevens (namics/Angel Flight, CH), local Scrum master and experienced project manager brought us up to speed in introducing Scrum, an agile process we started to follow in all our major projects – which is working pretty well so far. Sure will share our experience gained from a couple more iterations.

→ Result: Lots of fun, lots of new ideas, a big gain in directly applicable know-how. We’ll try to distribute all of that to the rest of the company at the upcoming Liip TechDay.

Many many thanks to Luke, Saban and Peter!

And if any of you readers feel like there’s something we definitely must know and therefore should invite you over (or try to find a slot at Webtuesday Zürich): just drop us a line! :)

Tags: , ,