Update: Part 2 is now available, covering Web Deploy (a.k.a. msdeploy)

Getting code deployed should be as easy as open up a web site (only taking slightly longer ). Devs or IT people should not spend manual labor (with the possibility of mishaps) on getting files from one place to another, making changes to IIS (or whatever you’re using), restarting servers, copy/changing web.config files etc. That’s the job for scripts and automation tools. Not to mention the cost savings of not needing IT people to do deployment. I bet you there’s no one manual step in the process of deployment that cannot be automated. Saying that, you have to consider how many times you deploy per day/week/month or year before going for full automation. However, if you’re serious about being Agile/Lean, you can’t do without a auto deployment scheme.

In the coming blog posts I’ll walk you through the steps I went through to automate our deployment, and hopefully you’ll find it interesting and even suggest improvements.

Overview
Below is an overview of the environments we’re deploying to:

One Load Balancer (LB) in each environment, two web servers in Dev and Test, and 3 in Prod. The actual numbers might or might not be true , but that doesn’t really matter. In addition there’s SQL Servers, but I will not cover that here.

Why have a LB in Dev? Reason number one is to catch any possible LB issues in Dev before going to Test and Prod, and have the exact same environment in Dev as in Prod. It’s also useful to try out new stuff, like having the LB do caching etc.

Deployment Frequency
For Dev we auto deploy every night (part of nightly build) and at will during day. For Test, 2-4 times per week and to Prod 1-2 times every 2nd week. That was yesterday! Today we can do it when the sun comes out of the clouds (not often in Bergen), every time I refill my coffee cup or whenever we feel like. The point being: we are no longer constrained by how often we can deploy.

Why All These Environments?
You can read about that here, but for us:

• Dev is where we try out things without physically hurting users, but still being in a real server environment avoiding the “works on my machine” issue.
• Test is as close to Prod as we can get (at external hosting provider, different network, firewalls etc) and where we make sure things run smoothly before going to Prod.
• Prod is Prod

Tech Details
Here’s the tech stuff we use which might be relevant:

• All servers are running Windows Server 2008 R2
• Web servers are running on IIS 7.5 (since we’re on R2)
• Application Request Routing in IIS is used as Load Balancer and runs on 2008 R2 Server Core (if you like, check out my previous post about setting up and configuring ARR)
• TFS 2010 for builds
• Team City for CI

Also note that we have access to the actual subnet where Test and Prod lives. This does however not mean we have access to all servers and features in all environments, it just means we can be given access to certain things not recommended through external firewalls, like PowerShell Remoting. This is where your environments might be different from ours.

Why Is Deployment Difficult?
First of all because every environment is different and there are no really good tools to automate the whole process. The challenge is to find the right tools to solve the problems your organization is facing, and have the tools work for you to get to the final goal.

What’s The Challenges?
For us it was about:

1. How can we safely move files from a build server to Dev, Test and Prod?
2. How can we automate the process of taking a node out of an LB cluster?
3. How can we safely execute an upgrade on a server in Dev, Test or Prod and get feedback of progress, errors, and abort and roll back on failure?
4. How can we remotely make changes to IIS?
5. How can we avoid all manual tasks? (like adding a virtual directory in IIS or copy a web.config file)

Safety and automation is two keywords that sticks out. Where safe means no-one else than the intended persons or services should be able to perform the specified tasks. Automation meaning no manual operations should ever be needed in either Dev, Test or Prod except from IT maintenance like hardware upgrades, windows update etc.

What tool options have we?

Copy files:

• Secure FTP in IIS 7 on a non public/available IP
• or PowerShell with BITS
• or WebDeploy

Taking LB nodes offline/online:

• Use PowerShell Remoting to execute PowerShell scripts on ARR server
• or the Web Farm Framework

Safely execute an upgrade:

• Use PowerShell Remoting to execute PowerShell scripts on web servers
• or WebDeploy

Avoid manual tasks:

• Script all tasks, so they can be repeated

The Build/Deploy Process     

What About MSI’s?
If you read my blog you know I’ve done quite a bit of MS Installer stuff and WiX in particular. MSI’s are perfect for deploying to multiple places where you have no control. The drawback is that most developers don’t know how to customize MSI’s and often end up with a versioning problem and leaving lots of old stuff behind on the server after upgrades. If you have people skilled in Windows Installer, please feel free to use MSI, but I personally find XCopy to be very easy and is what I recommend if you’re not an ISV. With MSI’s you still have to install them remotely, which could be done with WMI or PowerShell.

Notes on WebDeploy
I’m currently looking at using Web Deploy to simplify/reduce the amount of scripts needed. WebDeploy would replace the FTP and deploy steps, but first impression is that it’s too generic, making it really hard to do simple things without spending quite a bit of time learning the tool, it’s underlying package schema and IIS schemas. Hopefully one day Web Deploy will be the only tool I’ll need to execute the whole deployment process.

What’s Coming?
In future blog posts I’ll walk you through step-by-step how to accomplish the above solution. While I’m writing this I’m not 100% sure if it will be a solution using PowerShell (which I have in production) or a slightly modified version using Web Deploy. It all depends on which one is easiest and which has the potential of being maintained by other people than me in the long run.

Hopefully this will give you the input you need to fully automate your deployment process as well.

Going to QCon London? I am and a bunch of my friends are too! Just a heads up that the early bird is about to expire this Friday.

If you haven’t been to QCon before, I can really recommend it. What I find especially attractive by this conference is its various tracks that should satisfy the most demanding devs and architects, and of course not to mention the speaker list (which is still growing). Here’s a few selected speakers from my point of view:

• Dan North
• Floyd Marinescu
• Jim O. Coplien
• Joe Armstrong
• Jon Skeet
• Kevlin Henney
• Michael T. Nygard
• Ola Bini
• Ayende (Oren Eini)
• Rod Johnsen
• Ryan Slobojan
• Stefan Tilkov
• Steve Freeman
• Udi Dahan
• Ulf Wiger

And here’s the tracks:

• Architectures You've Always Wondered About
• Dev and Ops: A single team
• Functional programming
• Non-Relational DBs & Web Oriented Data
• Software Craftsmanship
• Solution Track: Wednesday
• 2015 Software Development
• Agile Evolution
• AlphaGeeks on .NET
• Cloud Solutions
• Irresponsible Architectures and Unusual Architects
• Solutions Track: Performance and ScalabilityBrowser as a Platform
• Cool Stuff with Java
• How do you test that?
• SOA 2010
• The Concurrency Challenge

Hope to see you in London March 10-12 (March 8-9 for tutorials).

A couple of days ago, my article about “The Current Direction Of Agile” was published on InfoQ. The article mainly represent my own learning curve within agile and lean inspired processes, hoping that my view would be interesting to others. I feel the recent Lean inspiration that agile has gotten the last couple of years, has pushed the agile community into a better place and been given tools to improve agile further.

Thanks to David J. Anderson and Arlo Belshee for reviewing the article, and not to forget Amr Elssamadisy @ InfoQ for pointing me in the right direction.

About a month ago I was contacted by Kjersti Sandberg at Programutvikling. She asked if I knew about any companies in Bergen that would be interested in having a full day seminar with Mary Poppendieck. I figured this was a great opportunity and contacted some of the companies I knew in Bergen. Webstep found this very interesting and invited customers and employees for a full day seminar with Mary.

At the same time I asked if she would be interested in doing a talk at NNUG, which she did! So, If you haven’t seen this already, the invite is out, so go sign up (for free!).

Mary is well known for her experience and knowledge within the Lean and Agile community:

Mary Poppendieck has been in the Information Technology industry for over thirty years. She has managed software development, supply chain management, manufacturing operations, and new product development. She spearheaded the implementation of a Just-in-Time system in a 3M video tape manufacturing plant and led new product development teams, commercializing products ranging from digital controllers to 3M Light Fiber^TM.

Mary is a popular writer and speaker, and coauthor of the book Lean Software Development, which was awarded the Software Development Productivity Award in 2004. A sequel, Implementing Lean Software Development, was published in 2006. A third book, Leading Lean Software Development, will be published in late 2009.

Please feel free to forward this to anyone within your company or to your friends, because this event has a much broader crowd than the usual NNUG crowd of developers and architects. At least your manager should have this in her/his inbox by Monday morning

Scrum has been very popular and still gains popularity around companies and individuals world wide. That’s good! Scrum keeps bringing Agile to the masses. What’s not good is teams doing Scrum only, not focusing on good development practices that XP are built around. In my talk I’ll be looking at some of the misconceptions around XP, how XP is compared to Scrum and why XP is superior to Scrum in many ways. Also why Scrum has become so popular the last few years and XP has not (in comparison).

This talk will be a introduction to XP, but it helps if you have experience with Agile in general and Scrum in particular.

My goal as of today is to bring XP to the masses! Sign up for the meeting at NNUG Bergen.

In the meantime you can order The Art of Agile Development, read my review of the book and have a look at eXtremeProgramming.org.

Before my talk John Arthur Berg from it’s learning will give us an introduction to Cloud Computing. Don’t miss out on this, cause it will be a good background to have when Christian Weyer will go into the details of Azure Services Platform in April.

See you all there.

I was asked to do a Scrum presentation for NNUG Haugesund and pulled out my old Scrum presentation, refined it quite a bit (strange how much you learn in a couple of years) and tried it on my collogues at Frende. Feedback was good :)

I’m a firm believer that doing Scrum alone is not enough. That’s why my second presentation will be about XP. XP in my eyes is a complete Agile process, while Scrum is a subset of XP. I’ll be talking about why this is and give you an introduction to the practices which I think any Agile team should adapt and XP specifically.

Hope to see you there.

My second news post is out on InfoQ. This time for the Agile track, talking about how to measure productivity in Agile teams and also how to monetize acceleration. You’ll find it here: http://www.infoq.com/news/2009/01/Measure-Agile-Productivity

A little self promotion Back in September last year, Einar Ingebrigtsen interviewed me about Agile, CI and other stuff I’ve been working on at Contiki. You can check out the podcast here: http://www.ingebrigtsen.info/post/2009/01/15/3cAgile-talk-with-Jon-Aril-Tc3b8rresdal-3e.aspx

Thanks Einar for doing this. Was very strange hearing myself talk. Don’t think I’ve done that since elementary school

It's great when we manage to get people like Dan North to NNUG. Many knew who he was from before and where excited to hear what he had to say, others didn't know so much about him but where excited by what the others told them. Dan talked about BDD and DDD, and how they are related. He said that without DDD, BDD would not have existed (hope I got that right). Which says a lot about BDD AND DDD!

One of the more funny things I remember from the event (which is not related to the topic itself) was the use of I in Interface in e.g. C#. So Dan said, why not use the I for something meaningful? Ask the interface the question: What do you do? And the interface says: ISendEmail or ISearchFiles or IPingComputers. This is a great way of giving interfaces roles. I just think this is brilliant!

My overall impression of the event was really good, but I would like to know what you think. Comment on this blog or drop me an email here. Actually since we had him over at Contiki as well, I'm a bit confused about what was said in his presentation and not Right now there is so much new and interesting knowledge trying to be consumed in my brain that I'm having problems concentrating  

I hope you liked the event and I also hope you would like us to continue getting people like Dan to Bergen.

After finishing the book "The Art of Agile Development" which I reviewed here, I was asking myself a few questions:

• Why are we doing Scrum?
• Why did we start out with Scrum on not XP?

I think the answer to these questions rely on many of the misconceptions around XP. If people really knew what XP was about and not that XP=pair programming and/or XP=no documentation or whatever first impression you get from XP, I think the adoption rate would have been higher. If that's true, what makes people adopt Scrum?

First of all Scrum got really hyped a few years back, many books were written and many adopted the process. They also introduced the certification program of ScrumMasters and Product Owners. If certification is good or bad is still being discussed in agile forums today, but one thing is clear; the certification programs gave Scrum much publicity and I will claim that it helped the adoption rate of Scrum. It also might have helped some companies to easier except the process as a "proper process".

One thing to consider is that Scrum is a management process. It has no practical solutions of how to develop software, only how to manage and plan for successful software delivery. My impression is that after a while teams that started out with Scrum start to look for ways to improve their process and they often turn to the practices defined in XP (or adapted by XP). I think that every successful adoption of Scrum is also adapting one or more development practices like Continuous Integration, Test Driven Development, pair programming etc, and they might not even know that they're a core part of XP.

If you look at what XP says about the management part you see that it resembles Scrum in many ways, or was it the other way around? I would dear to say that the difference is so small that it doesn't really matter what you choose. However, Scrum cover less of the complete development process than XP does, so my preference at the moment is XP though we're still doing Scrum. In essence this only boils down to what you call your process and which community you want to belong to. So maybe I should just be satisfied by saying we're Agile

This makes me wonder what students learn about Scrum and XP today? If at all? The only process I learned at university was RUP. If they learn both Scrum and XP, which one would they choose? Any students/teachers/professors out there that would care to comment?

This also makes me wonder if a Scrum shop has more credibility towards customers than XP? If you where (or are) a boss of a company that were about to develop some software, would you choose an XP team or a Scrum team for the task? Would you care at all?

While I was on vacation in the southern part of Norway (Flekkefjord) I found a postcard with the "Viking Laws". Not sure of the authenticity of these laws, but I still found them quite interesting. Surprisingly I also found them quite agile and a set of good rules to follow for any development team!

Here's the laws and how I link them to software and agile thinking:

§1 Be Brave and Aggressive

• Be direct
  • Hmmm... I think I'll go for N/A for this one.
• Grab all opportunities
  • And another N/A...(?)
• Use varying methods of attack (attack is interpreted as testing) 
  • Test your code and functionality by doing TDD, BDD, Exploratory Testing and/or similar things
• Attack one target at a time
  • Don't do multitasking
  • Don't have single tests that cover multiple functional areas
• Don't plan everything in detail
  • Don't do a big plan up front (waterfall)
• Use top quality weapons
  • Use good software tools
  • Use simple planning tools like whiteboard, story cards etc.

§2 Be Prepared

• Keep weapons in good conditions
  • Keep plans up to date (e.g. sprint burndown, release burndown etc) 
  • If 3. party components are used, make sure you upgrade when new versions are available to avoid work to add up
• Keep in shape
  • To be fit will let you be more effective at work and also have a lot of energy left when you get home, which in turn hopefully means you're motivated and energized for work the day after
• Find good battle comrades
  • A great team of people will do great things
• Agree on important points
  • Common understanding/common code base
• Choose one chief
  • Hmmm... Who's the chief on an agile team? The team or the customer? I would go for the team together with the customer and not one single person.

§3 Be a Good Merchant

• Find out what the market needs
  • Develop the most important functionality first and prioritize accordingly 
• Don't promise what you can't keep
  • Tell the customer the truth and keep them updated on time schedules and in the loop by utilizing review meetings etc.
• Don't demand overpayment
  • I'll let the sales people cover this one  
• Arrange things so that you can return
  • Have your code and architecture so that you can "easily" change out existing parts of your system. Think separation of concerns, inversion of control and dependency injection.

§4 Keep the Camp in Order

• Keep things tidy and organized
  • Keep code and architecture clean and easy to read and understand
• Arrange enjoyable activities which strengthen the group
  • Have fun at work, use breaks for fun activities like fußball or other team games and have a beer on Friday night from time to time.
• Make sure everybody does useful work
  • Have everybody involved and work as a team
• Consult all members of the group for advice
  • Do agile modeling when you don't know exactly what to do or how to solve a problem
  • Involve the team and ask for advice whenever in doubt
  • Do pair programming

The title of this book could easily have been The Art of XP Development. My first impression of XP back in the days where two things; pair programming and no documentation. I guess some people still think that(?). Did they choose to use agile to not scare away the people with these type of misconceptions? James Shore (the author, together with co-author Shane Warden) says on his web site:

Our goal for this book was to provide a complete how-to guide and starter kit for beginning and intermediate agile practitioners. To keep the book concrete and practical, we focus on XP.

So that explains that, but I'm not going to review the title of the book am I?

Talking about the authors, James Shore is a well known name in the agile community. The Agile Alliance recognized James with their most significant award, the Gordon Pask Award for Contributions to Agile Practice. He is also an internationally recognized speaker and have done lots of consulting for agile teams. Shane Warden is the co-author and editor of this book. He promotes open source software for O'Reilly's Open Technology Exchange.

To cut strait to the point, this is probably the best book on XP I've ever read and one of the best agile books I've come across as well! Combine it with Mike Cohn's book; Agile estimating and planning, and maybe Agile Modeling by Scott W. Ambler, and you're well on your way to become agile.

My motivation for reading this book was based on my knowledge of Scrum and my willingness to adapt more of the XP practices. One of the questions I've been asking myself is how do "they" approach team management (our should I say self management...) compared to Scrum? That question and many others where answered in this book!

XP is of course a full fledged development process and (in my opinion) have been colored by its some "extreme" (at the time) practices and deserves more attention than it gets. So I would strongly recommend reading it, even if your focus is not XP.

As I've mentioned before, many books are very theoretical when it comes to software processes, but this book is very hands on and the authors clearly have a great extent of experience with the process. This gave me as a reader good value and motivated me to try out different aspects, as well as new things on areas that I thought we were doing ok already. I also rediscovered some things I just forgot about.

The key takeaways I got from the book was:

1. XP covers a lot more around the management part than I thought.
2. Scrum and XP is closer than I expected and XP cover more ground.
3. If I had known what I know about XP today, I might have introduced XP instead of Scrum to our teams.
4. I got many confirmations that what our teams are doing today is good, but also found aspects already known to us where I knew we could improve, and some aspects I hadn't thought of.
5. All the provided examples of what to try or do in specific cases allowed this book to be a how-to instead of a theoretical book about XP/Agile, which I valued very much.
6. The focus on technical debt gave me new insight.
7. The testing focus. Good article covering exploratory testing by Elisabeth Hendrickson.

The book is structured into three parts:

1. Getting Started
2. Practicing XP
3. Mastering Agility

For more details about the content of each part, have a look at Jame Shore's web site, where he lists the chapters. For me part two and three were most valuable. Part one give a good introduction to agile, XP the Manifesto and the values behind it all. You should defiantly read it if you are new to the process or feel that you could need an update, like I did. In part two every chapter starts with a mini-étude, and every topic within a chapter has an explanation followed by five paragraphs in the end; questions, results, contradictions, alternatives and further reading (if any). Here's what the authors say about the mini-études:

Have you ever heard a musician playing scales? That's an étude (if a boring one). An étude teaches mastery through precise and careful repetition...
...Beginning agile teams can use the études to refine their practice of agile development.

I think these are good, but I found myself skipping most of the mini-étude's and the five paragraphs in the end. In the beginning I read them all (maybe except from the études), but the further I progressed in the book the more I skipped. I did this because much of the material was known to me and I found the main part of each topic most interesting. If I felt something was unclear or had questions, I read the other parts as well. I'm not saying this is the way I recommend reading the book.

Part three of the book was very interesting to me. It covers the following topics:

• Improve the Process
• Rely on People
• Eliminate Waste
• Deliver Value
• Seek Technical Excellence

The interesting part is that they give you insight to how you can go about to improve the process when you've become comfortable with it. In essence; apply the process on the process itself.

So am I not going to criticize (on the negative side) anything in the book? Well, I could because there are some things I don't totally agree with, but all in all it deserves its good credit. However, I'm not going to pick on the few knitty details I personally don't like/agree with.

When I did some research about the authors I found an interview with James Shore over at InfoQ that you should check out: http://www.infoq.com/news/2008/05/Interview-James-Shore

As Brian Marick, I'm considering buying in several copies of this book to distribute among our agile teams. I really think that it could generate great value for anyone reading it, being any type of agile team member.

If everything goes as planned NNUG Bergen will in August have two great speakers. Dan North from ThoughtWorks and Christian Weyer from Thinktecture! Is that a great lineup or what?! And the best part... it's FREE!

Currently the plan is to have Dan North on stage the 25th of August and Christian Weyer the 27th (Monday and Wednesday). Here's a bit about the two speakers and what they're going to talk about:

Dan is a principal consultant with ThoughtWorks, where he writes software and coaches teams in agile and lean methods. He believes in putting people first and writing simple, pragmatic software. He believes that most problems that teams face are about communication, and all the others are too. This is why he puts so much emphasis on "getting the words right", and why he is so passionate about behaviour-driven development, communication and how people learn. He has been working in the IT industry since he graduated in 1991, and he occasionally blogs at dannorth.net.

At NNUG Dan is going to talk about The relationship between Domain-Driven Design and Behaviour-Driven Development.

 

Christian is co-founder of ThinkTecture, a European software development support company. He has been modeling and implementing distributed applications with Java, COM, DCOM, COM+, Web Services and other technologies for many many years. Recently his focus has been on the ideas and concepts of service-orientation and their practical translation in customer projects with Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF) being the two main technologies applied. Especially the more than natural marriage of WF and WCF currently has gotten his attention.

Christian's talk will be about WCF, but other than that he's quite open to suggestions. I'm thinking it would be interesting to hear about why we should move from Asmx to WCF and the benefits (and any drawbacks) we get from that move. What do you want to know about WCF? Drop me a comment and we'll see what we can do... Be quick though, we need a decision soon.

On Friday we had some friends over and enjoyed the beautiful weather in Bergen. I and (let's call him Trond) were sitting outside talking a bit bout work, agile, .net and java. I fired up the grill to throw on some burgers and I went in and out quite a few times to get stuff I needed. First I went and got the meet I needed. At the same time I also got some lettuce, ketchup and mustard. I went out again and threw the burgers onto the grill, keeping the conversation going with Trond. Then I went back in, got some plates and some grill equipment I forgot last time. I went out again and starting flipping some of the burgers. I then realized we needed something to eat with, and went to get some knifes and forks, as well as a couple of beers. Back out again, I flipped the burgers, went in again and found something else I needed.

When I got out again Trond said: "I must say you really ARE agile! You even barbeque agile! Only getting what you need there and then and not planning too far ahead."

And he was right. This is how I am. Somebody might say chaotic, others agile Maybe that's why I was so easily convinced about the agile way of working.

But seriously, one of the most important aspects of agile development (from my perspective) is the idea of postponing all decisions to the last responsible moment (note: it's responsible not possible). This will let you be more adoptive to changes and force you to not implement things you don't need (e.g. it's very tempting to implement something that you think you will need in the future). On a traditional project where "everything" is planned up front (a waterfall like project), you often run into problems where you see that the way we thought about the solution back then is not the way it is today. This might effect the architecture in a big way. If you're being told to stick to the planned architecture, you find yourself creating workarounds to fit the architecture, which probably is not the best solution.

Lately I've been trying to focus on how to make testing work better at our company. We've fully integrated our testers into the Scrum teams, but there's still some things I feel is missing. Especially related to the tools/frameworks we use for testing. One of the things I'm looking into is Fit and FitNesse (Framework for Integrated Test) created by Ward Cunningham in 2002. The first time I got an introduction to Fit was in Nils Christian Haugen's presentation at JavaBin back in March. This got me very excited, but I've hadn't had time to look enough into it, but now I think I will.

In essence Fit is a framework that lets your user stories's story tests (or acceptance tests) to be automatically tested/verified. The way you do this is by using a table structure (as showed on the left) to give in values and expected outcome. This is a very nice way of working with tests from a customer perspective. Everyone can understand this by having a short introduction to how it works.

Much like you do with unit tests, this process is automated. The preferred way of authoring unit tests is by using Test Driven Development (TDD). Similarly, working with Fit you can use Story Test-Driven Development (STDD). I really find this way of working to be very interesting and I hope to try this out live soon. Hopefully I can post some more articles on this later when I have some actual experience with it

David Hussman does a great job describing Fit in his presentation.

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.