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.