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.