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

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?

This weekend our company had a get together at a ski resort at Geilo, Norway. Here I had a talk about Scrum4Suits. My company is rapidly growing and we saw the need for some changes. One of these changes is Scrum. The problem with changes is that everyone outside of that department also needs to be in on it. The “suits” needs to change as well to make this work. So I decided to try to explain to our suits what Scrum is, why we have decided to adopt it and what they must do different to make this work. The feedback was great. They really understood the problems at hand and immediately understood why Scrum was the solution for us. Now we have to wait and see if they REALLY got it and if we can take advantage of Scrum the way we want.

At Wednesday 18th of October we will have a new meeting at NNUG in Bergen where Bård Strøm will talk about Agile development and I about Memory Leaks in .Net.

Agile development
In Norway agile development gain more and more popularity. Statistics show that 3 out of 10 software projects are delivered as ordered, but 7 out of 10 fail completely or partly. Based on techniques like extreme programming, agile development presents techniques to create products not only with higher quality but delivery on time, to the customer’s satisfaction.

Bård will talk more about this in his talk, so don’t miss out on this.

Memory Leaks in .Net
In a previous post in my blog I talked a bit about memory leaks and the importance of the dispose pattern. At my talk at NNUG I will go into the heart of the problem, show you the tools necessary to detect these leaks, demo common coding mistakes and show you some guidelines on how to avoid these errors in your software.

So if you live in Bergen, Norway don't miss this out. Go to http://www.nnug.no/Avdelinger/Bergen/Moter/Brukergruppemote-Oktober/ to register.