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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Torbjørn commented on my previous post that:

“Nobody can be expert of everything”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

An office with a view...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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