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.

At Contiki we started doing Scrum in November 2006 and I wanted to post an update on how we're doing, and at the same time look back and see what we have accomplished. Quite a few things have happened since I held my presentation about how Contiki is doing Scrum in February 07 at NNUG. After skimming through my emails from the last 2 years I was able to find an interesting progress on what and when we have introduced the different aspects of Scrum:

• Daily stand-ups/Daily Scrum (Oct 06)
• Daily Scrum in Campfire to improve communication with our offshore team (Nov 06)
• Started using ScrumWorks (basic) as our Scrum management tool (Dec 06)
• Started our first test sprint (Jan 07)
• Read Mike Cohn's book, Agile Estimating and Planning, which I've used as a guideline from that day (Jan 07)
• Started sprinting for real including all meetings (planning meeting, review meeting and retrospective meeting) (Feb 07)
• I got certified as Scrum Master (March 07)
• Started using Planning Poker and www.planningpoker.com (March 07)
• The word Scrum became a buzz word in our company (April 07)
• Our current dev team at the time got split into 3 Scrum teams because the team had grown to big (Nov 07)
• Started having fixed lengths on all sprints to get an accurate velocity (Nov 07)
• Started using release planning for long term planning (Nov 07)
• Started calculating cost based on number of sprints and team resources (Jan 08)
• Our Product Owner got certified (March 08)

It's taken time and we're still not quite there, but I feel we have achieved a lot. Not only that, I also think (and are quite confident) that we have improved our development process enormously.

If you look at the list above we can shorten it down to:

We started with Daily Scrum, continued with Sprints and "ended" with Release Planning.

For me this have been a very logical approach to introduce Scrum to our organization. The easy part was getting the development team to adapt Scrum. You might argue that we spent a long time doing so, but the process has evolved over time (for us that is) and we've adapted the different aspects of Scrum as we felt ready for it. It also has to do with the team getting more and more mature and gaining new knowledge about the process which increases the willingness to adapt new things. I also feel that we did right in not pushing everything at once. We could for instance have started with Release Planning earlier, but we had several good reasons for not doing this. It's also about letting the whole organization getting used to Scrum and it's way of doing things. Getting used to communicating with User Stories and Story Points instead of features, use cases, days, gant charts etc. The development team hasn't changed how they do Scrum for quite some time, but the rest of the organization has needed this time to adapt. The time spent also reflect our learning curve as we have moved forward. The most important thing of all is that the Scrum initiative came from the developers themselves, and not from management, and there was a mutual agreement for us to try this out.

In addition to focusing on the development process of Scrum, we have also adapted many things from XP. As you probably know Scrum does not say much about how a developer should adapt to the agile way of working. Scrum is a management process is my eyes. XP however are very practical and fits nicely with Scrum. You might ask why we decided to do Scrum and not XP? The answer is coincidence. At the time when we started looking at a new process, Scrum had a lot of attention and it was Scrum I started to read and learn about first. Later I found that XP is not as extreme as one might think.

The hard part for us (developers) has been to be effective with TDD or Unit Testing in general. Actually not only effective, but to get "acceptance" from all the developers to spend time on writing tests instead of being "effective" with coding. We have a lot of legacy code (as defined by Michael Feathers; legacy code is code without tests), and making major changes to our application for the sake of automated testing was just not an option. The cost would be to high and our ability to deliver new functionality would have decreased to much. Sometimes I really envy the consultants out there that get to work with new products more often than not. We are however aiming for improving our existing code with tests as we touch the code fixing bugs or creating new features, but this is a long running process.

In my previous post about Developer conference in Bergen I said some not so nice things about the .Net community in Bergen (also called criticism). After today's meeting I take it all back. Everybody that showed up today proved me wrong. On previous meetings we were satisfied if 20 people showed up. Actually 20 people is/was our goal for average attendance for 2008. So what happened today? 43 people showed up to see Erik Leivestad and Thomas Eyde talk about Agile Project Management and Test Driven Development! For a time there I was worried that we didn't have seats for everybody. I really hope that this is the new norm at NNUG Bergen and not just a onetime incident.

We also did a quick survey before we started the meeting. We asked how many project managers and how many developers was in the audience. To my surprise almost everybody was developers. I was thinking that because of the Agile PM talk we might have attracted a different type of crowd than we usually do, but that was not the case.

The second question was how many was here for the first time. About 50% of the crowd raised their hand. This was not a surprise for me since I checked the statistics the day before, but it's nice to get it confirmed :)

The last question was how many will come to the next meeting, and that was depressing. The response was 3-4 hands at best. I guess you where thinking: "let’s have this meeting first and see how it goes" :)

A big thank you to everybody that showed up today and a special thanks to Erik and Thomas for spending their spare time to educate us about agile processes and tools. It's really awarding to see a big crowd showing up when you've spent a lot of time (without getting paid) getting speakers and subjects that you hope people will like and find interesting. Finally I hope to see you on our next meeting the 27th of February. Until then, happy coding!

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

At NNUG on Wednesday (28 of February) I will have a talk about CMA Contiki’s experience with Scrum after 2 months (3 sprints). Frank Botnevik from Amitec will start the show with a talk about SOA, WSCF and his experience around this. Go here to register for the meeting. Hope you find these topics interesting and hope I'll see you there.

I’ve just registered for a Certified ScrumMaster (CSM) course in Oslo. The course will be held from March 28-29. See here for details.

The course is held by Danube Technologies, the guys behind ScrumWorks. If you haven’t heard about this tool I absolutely recommend you check it out. I like the simplicity of the tool, the ease of use and it’s free. In short it has a backlog and a sprint. To move items to a sprint you just drag/drop from the backlog into the sprint, as simple as it gets. They recently came out with a Pro version of the tool that is not free, but I haven’t tried this yet.

My team has just finished our first iteration (Sprint in Scrum). One of the problems we encountered at the end was what to do when the tasks run out? Not that it’s a “real” problem, because there is always something to do (outside the Sprint), but it feels bad. Is there a recommended Agile approach? For us bugs was the solution, because somehow they’re always there. But when I say bugs I’m thinking of the kind of bugs we already know about before starting the sprint, not having high enough priority to be included.

My first thought was that the end of the Sprint would be a great opportunity to make sure that the implemented features was truly finished. Do an extra check and maybe some refactoring of the code. I was hoping that this “extra” time would make the quality of our product better and we would avoid the previous unavoidable: Rushing on to the next task without making sure that everything works and ending up fixing and finding all the bugs at the end, resulting in breaking the deadline because there are too many bugs.

One of the reasons for running in to this issue (running out of tasks) was a mistake about our testers. We didn’t include them on the first Sprint. Several reasons for that which I’m not going into now, but we soon found out it was a bad idea. Ideally the testers should have started testing functionality as soon as something was marked finished. This would have resulted in some new bugs, which would have kept the Team busy and made the features closer to the real completed state we were looking for.

So if any of my readers have anything to contribute with here, now’s the time. Would love hearing from you. I know some of you are so Agile that you probably don’t even read this bit because you’ve already started your comment…

An office with a view...

I have moved myself into an office, away from the development team! Me and the Team are not physically connected anymore. If they shout my name, I will not hear them… If I call for them, I’ll be met by a drumming nothing.

Here are some of the questions that went through my mind before I moved into my own office:

How will I know what’s going on with the Team? How will I get hold of the ideas and suggestions that spring to life from thin air while the Team’s working? How can I continue to work and still be influenced by the Team when I’m not there? Will I become more efficient working from an office? Will anybody come to visit? Will I now become that sad looking guy that people say “hi” to without ever getting an answer? Will I gradually lose my motivation, start making other plans and ending up as a consultant again? Will my company now raise my salary to the same level as the guy who previously had this office? And the most important question… Will the Team lose my respect now that I’ve decided to become one of “them” (the suits)?

As you can probably tell this was not an easy decision for me. I have done this in the name of science and with an open mind willing to be convinced of something I don’t believe in. This is an experiment and here is a glimpse of what I’ve experienced these last two weeks.

On my first day I wrote a note saying: “I’m so bored, I’m so f#¤&%g bored. No one to talk to, no one to bother… How am I going to work in these conditions?” And in huge letters at the bottom it said: “Be strong!” In the upper left corner there was a very personal note that I’m not going to tell you.

I used most of the day to get comfortable in my new surroundings. Since I’m an architect I can’t live without a whiteboard, so I found one and smashed it on the wall. I then removed some drawings left behind by the previous owner’s children (nice, but I’m not quite there yet). When I was about ready to start my day, it was over. I went home and complained to my girlfriend.

I used the next few days to send email to people letting them know I was sitting in this office. I hadn’t seen many people since I moved, so I though this email would help. It didn’t. I just had to admit to myself that I’ll be stuck here for myself for a while. I then started to look at the current and upcoming Sprints (ref. Scrum) and started to work. And the next thing I remember is that the lights went out. The time was 6.30 pm and I was the only guy left. Wow! Where did the time go? I went home.

By now I’ve started to notice that the days are getting shorter. I don’t know how it happened, but this office is in another time zone. I’m still looking for the knob on the wall to slow things down, but it’s not to be found. I’ve screamed out loud “Beam me up, Scotty” a couple of times, but nothing has happened so far. Even the hourly sessions of fussball has been reduced to once a day (at least I have one social activity). During a day I have more visits to the zone, than I usually have in a week. 

So am I saying that having your own office is nothing but good? Have I found Mecca? Have I just been playing around for the last 10 years? Yes, I have.  It’s been fun, but now it’s over. Time to grow up and become a responsible human being! Or is there something more to this?

I’m an extrovert person (according to this guy) and I like being around other people. If I’m alone for too long I get restless. This also means that I like talking to people, being part of and contribute to conversations. This makes a group of developers an ideal setting for me. So my problem is that I don’t WANT my own office, but I think I need one. Based on my experience described above I think you understand why.

What about the rest of the Team? Should they have their own offices to? First of all I think people who like being more by them self and are not as extrovert, have more to gain of being part of a team than I have. Why? I think they very often have better ability to concentrate on what they’re doing, getting into the zone and still be able to respond whenever their neighbor ask them questions or what not. And even more important, they are able to get back into the zone again very fast. So what do they gain from being part of the Team? One guy told me that sitting with the Team is just more fun! It’s motivating and you learn quite a bit just by being there. And if your team is doing Agile stuff, I think it’s mandatory in order to get the team spirit you need to be successful at Agile development.

One last thing about my role in the Team is that I’m not very often working on stuff that the Team is working on. I do a lot of research, specifications, talking to others about ideas and having my own whiteboard discussions. In fact when I think of it I might be a disturbing element for the Team, so they’re probably glad they finally got rid of me.

To conclude this rather long tale, I’m willing to change my mind and admit that for me having an office is a good thing. However, I still think that for a developing Team to have success they need to be grouped together. Not necessarily the whole Team, but at least in smaller groups.

Last year I was in Stavanger speaking for NNUG. After the meeting some of the guys went out to have a beer and invited me with them. While we were sitting there and talking about stuff we’re only aloud to in circumstances like these, joined by fellow .Net mates (as appose to when we’re out with <normal/> people), we came across the subject of Scrum. I mentioned we were going to adopt Scrum, and in next sentence started talking about how we had grouped our office landscape. Not using cubicles but having all tables in the centre of the room, all looking in. One of the guys interrupted me and said: “You’re not suggesting that Scrum has anything to do with how you organize your landscape do you?” I responded; “Of course not!” and continued.

In this room we are 12 developers sitting around this “table”. We love it! (Thanks Torbjørn for the picture)

After doing some more studying on Scrum and having practiced it for a few weeks, this somehow came back to me. If I had that same conversation today I would have answered; “I sure do. Don’t you?“

Scrum is all about Team communication. Letting a team being a team, performing as a team, talking as a team, making decisions as a team and so on. Very often Scrum starts out as a desperate solution for a team that keeps failing. They adopt Scrum and the team starts having success again, together, as a team. Why is that? I think it’s mainly because scrum (if properly adopted) focus on team communication. How do you communicate best with your team mate? If you turn your head and talk to him or if you have to climb over a wall (or maybe two, three…) to make contact?

This is a topic that has been widely discussed by many. I know one guy in particular who disagree with me on this; Joel Spolsky (Joel on Software). I must admit that he has done a great job getting me to doubt if we’re doing the “right” thing. Joel says that if you get interrupted in your work, you lose concentration and focus. It will then take you about 15 minutes before you’re back on track.

I think this has a lot to do with who you are as a person, if you’re working on the same functionality (same problem domain) or actually in which country you live. Some people communicate well, others don’t. Some like talking, some don’t. If you’re working on the same problem as the guy next to you I think that could be really beneficial. If you live in Norway (like I do) we usually don’t sit in cubicles. We usually sit in an open landscape communicating freely. It might be a European thing, I don’t know…

Anyway, I am a strong believer of Scrum and I think it’s easier to adopt if your team is sitting in a landscape. Do you?