Lately I've been shifting focus back and forth between development and project management. 2 years ago I took the initiative to start Scrum where I work, and this has turned out to be such an interesting and demanding process that I'm having problems letting go (not that there is any reason to). During this process I've been reading a lot of books about Scrum, Agile, XP, planning, estimating and so on. All the books I've read has been very theoretical. Most of them were based on experience by very experienced practitioners, but still they tend to be very general in their advice and cautious of telling you how to do things.

Today I was looking at some Scrum resources over at ScrumAlliance and found a presentation by Henrik Kniberg called "The Manager's Role in Scrum" (access requires membership). In his presentation I saw a book he had written (Scrum and XP from the Trenches) and found it freely available at InfoQ. The interesting thing about this book (which I by the way have not read but just skimmed through) is that it focusing on "this is how we did it" on a very detailed level. The nice thing about these kinds of books (or even presentations) is that you might not agree with everything that they've done, but it gives you input like: "we've tried this and it worked!" or "we tried that, but it failed miserably!". And if you're lucky you also get "we think this worked for us because..." or "it did not work very well because..." and so on. You also often discover things that you haven't thought about before. "Ahhh... that's right, why haven't I thought of that?".

I've seen the same things at NNUG where we typically have two types of presentations; new technology, or someone's experience within a certain topic. New technology talks are very interesting and motivating, but often lack experience. Experience based talks are popular because everyone knows the value behind time spent and experience gained, and that this information is given to you for free, helping you do avoid common mistakes.

Hopefully I will get time to read Henriks book soon and maybe I'll post a short review as well.

I’ve blogged a bit about planning poker lately (Planning Poker and Planning Poker – Why does it work?). This time it’s the anchoring effect. You might have heard about the anchoring effect before and you can read more about it at Wikipedia, but here is an example of why anchoring in planning poker is not wanted:

David is Product Manager. Jonny is team lead. He’s been in this company since the startup 5 years ago. David, Jonny and the rest of the team sit down for a round of planning poker. Before they vote, David reads the user story to be estimated and asks if there are any questions. Some questions come up and get quickly answered by David and Jonny. Before they start to vote, Jonny says:

    “This should be very simple, shouldn’t take us more than a couple of days”.

Jonny has now put out the anchor. When all votes are in, not surprisingly they’re all unanimous on 2 days. Jonny could have left out his guess on 2 days, and there would still be an anchoring effect. This is because he states “this should be very simple”.

When playing planning poker you should try to talk about the story without mentioning anything about your impression of the complexity or timeframe of the story. This will allow your team to estimate more honestly. If Jonny didn’t say what he said in my previous example, someone might have voted much higher and forced a discussion that would have highlighted something previously unknown to the story. As soon as the anchor is out there, this seldom happens.

First I need to start off by saying that my experience is related to combining planning poker with agile development. For me this is Scrum. For planning poker to work I believe you need to use commitment driven planning as part of your sprint or iteration planning. I think that without this, planning poker will not be equally efficient.  One of the tools a team has in agile development is velocity, so let me first explain velocity.

Velocity is the average amount of story points your team successfully has committed to over one or more sprints. A team’s velocity will evolve over time, and be more and more accurate if you can:

1. Keep the number of members in your team stable
2. Have the same length on all sprints
3. Keep doing the same estimating mistakes
   

If you change either one of these, you will weaken your velocity. Here are some examples of the above:

1. By removing a member from your team, you will not be able to do as much work as before, resulting in a sprint with fewer story points than in previous sprints.
   
   
2. If you have a shorter sprint than your normal sprint length, you will be able to commit to less story points which gives a wrong outcome for your velocity.
   
   
3. If there is a sudden increase/decrease in the amount of story points estimated for a user story compared to a previously similar user story, the velocity will be less accurate.
   

One important thing about velocity is that it’s not necessarily this number you should use when your team is committing to user stories for a sprint. The velocity main purpose is to plan ahead for more than a sprint, e.g. for release planning. Typically the product owner uses the team’s velocity to calculate how much work can be fitted into one release.

When you sit down for a game of planning poker you focus on estimating user stories. Before you start a sprint the team goes through the estimated user stories and commits to do a certain number of these in the sprint. The first time they will probably miss by committing to too much. The second time they will do better and so on. Eventually the team will get a feeling of how much they can commit to. Remember what I said earlier, the team should not USE the velocity to commit, but rather use it as a warning sign. E.g. if the team commits to much more than the current velocity, you might want to check your commitment again.

So, back to estimation. If a team consequently estimates to low on their user stories, this will be corrected by how much the team is actually willing to commit to in the sprint. This is also indicated by the velocity. It’s much easier to control and to see when the team misses a sprint, than to keep track of all estimates and figure out which were estimated too high or too low, and try to learn from that. This also means that you can’t try this couple of times, see that it didn’t work, and give it up. You need to give it time.

Are you an estimating guru? Have you never missed an estimate in your life? Can you even do estimates for others? Then this is not for you. However, if you don’t recognize yourself in the previous description this still might be something for you.
When I introduced Scrum to my organization, we quickly started to use planning poker. So what’s planning poker? Here’s what planningpoker.com says:

"Individual stories are presented for estimation. After a period of discussion, each participant chooses from his own deck the numbered card that represents his estimate of how much work is involved in the story under discussion. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed and discussion can begin again."

How we use planning poker in Contiki

At Contiki we use planning poker to estimate all our user stories, or features if you want. When the backlog starts filling up with un-estimated backlog items, we gather the team for a round of poker. We also have a team in Ukraine, so using planningpoker.com works great for us. Here’s what we do step by step:

1. The product owner reads the user story and adds any additional information he think is necessary. No comments or input is allowed from the others at this time (our experience is that starting the table discussion before the first estimate takes a lot longer and will not make the estimate any better).
2. Everyone vote for an estimate.
3. When all estimates are in, all estimates are revealed. When we see that the estimates vary (which usually is the case), we ask the person with the lowest and the person with the highest estimate to discuss why they differ. This usually results in highlighting the different perceptions of the user story and helps clarify other aspect previously unknown to the story. The person with the lowest estimate might know something that will make implementation easier or the person with the highest estimate might know some other implications that the other person didn't.
   
4. At this time other people might jump in to add extra knowledge to the story if they think this will help.
5. After a short discussion a new voting is started, if not the estimates are very close to each other that is.
6. If the estimates are still not the same, pick an average.
7. In rare cases we allow a third vote if the team agrees.
   

Using a team to do the estimates has several advantages:

• If one person is doing the estimate, it’s not definite that he’s the person to implementing the functionality, making his estimate less valid. I’ve never understood people doing estimate for others.
  
• If only one person does the estimate, he estimate is based on his background and his knowledge.
• Having several people with different experience, knowledge and perception to agree on an estimate, usually results in a better result. It will usually help people visualize aspects of a functionality that was previously unknown the one person.
• It’s more fun!
  

Later I'm thinking of talking about:

• The anchoring effect
• Story points vs. days
• Why does planning poker work?
  

I started to answer Torbjørn’s comment on my previous post about general specialist, but it turned out to be far too long for a comment, so I posted it hear instead.

I think I did a poor job defining the general specialist. Actually, after doing some more research I found that the guy I didn't remember the name of was Scott W. Ambler (which I’m a bit embarrassed of not remembering). Anyway, he actually doesn’t call it a general specialist but generalizing specialist (or craftsman), which is a better description. In my post I focused much on sharing knowledge. Sharing knowledge is important, but what I didn’t focus enough on is that generalizing specialists are also specialists in certain areas, but in addition to that also has quite a bit of knowledge in other areas. What Scott is stating is that you as an IT person should strive to become a generalizing specialist and not a pure specialist. His examples are focused on a much broader scale (like use case specialist, database specialist, C# specialist and so on). Torbjørn touched on this as well. What I'm saying is that by putting the same principals to a smaller scale, where you have developers specializing in certain areas of the application, you get the same effect.

So I think that developers should strive to teach themselves different part of the system, and not specialize in a few areas. One way of doing this is to motivate developers to share knowledge and allow them to work with parts of the system that someone else might do faster because he’s the specialist in that area.

Torbjørn commented on my previous post that:

“Nobody can be expert of everything”

And that’s not what I meant. What I meant was that people should be allowed to specialize in areas outside their specialty to become generalizing specialists. This will also let developers sharing greater knowledge within certain areas to be better suited to improve functionality within this area. Two people think better that one, right?

To hear more on this from Scott himself, check out this video. He covers a lot of topics in this talk, but if you forward to about 36 minutes, he’ll talk about generalizing specialists. Also check out his web site about generalizing specialist.

A not so long time ago the company I work for initiated Management by Objectives (MBO). MBO is divided into 3 groups of objectives: company objectives, department objectives and individual objectives. MBO is also linked to a bonus. I’ll get a 100% bonus if the company reaches its goals, my team reaches their goals and I reach my goals. On each of these (company, department, individual) there is a weighting.

Let’s say I sit down with my boss in December to agree on my personal goals for Q1 (January-March). Before going into this meeting I’ve thought of some objectives. My boss also has some suggestions. Together we come up with 4 objectives, divided over the 3 months. One of the goals has to be achieved within 3 weeks from now, but the others are closer to the end of the quarter. As time passes I reach my first goal after 3 weeks, and I’m starting to focus on the other 3. But as it turns out, the objectives we clearly visualized one month ago are no longer valid, because of some unforeseen changes that have occurred. Since we’re doing agile development this change was handled nicely, but for the MBO’s this is not the case. So I now have two choices; do what I have to do to reach my objectives anyway or don’t do them and loose my bonus.

Let’s backtrack a bit. Why do companies use MBO? It’s to steer company objectives by motivation. In this case the primary motivation is money and maybe the satisfaction of reaching your objectives. So what happens when the objectives change? Well, it’s no longer in the company best interest for you to complete your objectives, so we need to change the MBO as well, right? But this sounds like a lot of MBO management, and we don’t want that.

For now I’ve mostly talked about individual objectives. Relating this to agile development you might want to ask another question: do we need individual objectives at all? What if we removed the individual objectives and only used the company and department objectives. This way we can work together to achieve the department objectives instead of focusing on your own objectives. This is also a much better philosophy related to agile development, where you always work as a team and not as an individual. But this will not solve all the problems. You’re still stuck with the same issues when things start to change. However, it’s easier to change the team objectives than change all individual objectives, so MBO management will be easier. I’m also much more fond of a team working together to achieve a common goal, than each individual working towards their own personal goals. It’s just better for the team.

A while back a saw a talk by someone with a name I can't remember talking about avoiding specialists. This got stuck in my mind and I have been trying to use this way of thinking in the team I work in. The idea is that having specialists is a risky business for the company. This is related to "the bus effect". What happens if the specialist (the guru) gets hit by the bus? All the places that I've worked we’ve always had them. Come to think of it, I've been one and so have probably you. This is also running in the vanes of developers. It’s much easier to do changes to your own code, that letting someone else do it.

So what can we do to address this problem? One suggestion is to have general specialists instead of pure specialists. So what does that mean? First an example of a specialist. A specialist is someone who is very good, or has a lot of knowledge within one specific area. For instance the guy that developed the framework that your application runs on. Every time there is a problem with that framework, he's the guy that has to fix it. You've tried several times to get access, but you're always told to hand it over to the specialist.

A general specialist however has divided and shared his knowledge over several areas. The most important thing here is the sharing of knowledge. It's now not only one guy that knows that specific thing within your app. I'm referring to larger bits of the app, and not small little bits, because you can't have everybody know every little thing in your system.

So how do you achieve this within your organization? To use our team as an example, we ran into a challenge when we were going to divide our Scrum team in two. We became too many in one team and were forced to split us up. In the app we're developing there was very clear layers of functionality, so the first thought was to divide the team by client and server. The advantage of doing this was that you would get extra focus on e.g. web services, business logic and database. You would also get another sense of ownership that might improve quality of the product. However, this also has a few negative effects. For instance, if you’re doing feature based development (like we do with Scrum) the client developer needs to hand over his work when he needs a new web service or some business logic. This will result in a dependency that is unwanted, and fits very poorly with Scrum.

So we decided that it's better to allow the developer to work on a single feature all the way through the layers. But will not this result in this person being the specialist on that feature. Yes, and that’s where sharing knowledge is important. Let’s say a bug is found on that feature. Who’s going to fix it? Maybe someone else than the guy who created it. Or if this feature is going to be improved, someone else might do that job. This also fit nicely with Scrum’s philosophy about choosing your own tasks and not being constrained by your knowhow within a specific area.

Trying to think of general specialist’s will help you share risk across your organization. On short term this will have an extra cost, but the company (and you) will see this investment worthwhile the next time someone quit their job or for some other reason leaves the company.