Articles

Scrum in 5 minutes This is a good, short, management level introduction to Scrum. Also available in swedish

Scott Hanselman interviews Ken Schwaber on the definition of done. In this interview Schwaber explains the value of having a fixed definition of what it means that software is done at the end of the iteration. It turns out that introducing a definition of done will profoundly change the relationship between the product owner and the team! Schwaber also argues that introducing a definition of done is the only (!) way to putting real iterative development in place, delivering value step by step, iteration by iteration! You can also listen to this 30 minute interview here.

10 ways to screw up with Scrum and XP Some really nice looking slides by Henrik Kniberg about various things that can go wrong when you are trying to do Scrum. Focuses on visual clues so that you can see when mistakes are happening. Everyone involved with Scrum should know what is in here. Here is a video of Henrik presenting this material at a conference

The Scrum Papers A big collection of papers and case studies by the inventor of Scrum, Jeff Sutherland. Jeff Sutherlands goal with Scrum and his passion is general is to create hyper productive companies. I.e. companies performing 5-6 timer better than their competition. His company Patient Keeper may be one of the most advanced and productive software companies ever. In this compilation you will get lots of inspiration and ideas from the many real world success cases explained.

A proposal for a CM strategy that works well with agile projects by Henrik Kniberg.

The new product development game The article that was one of the inspirations for Scrum. You do not need to read this to be using Scrum, but it is of interest for those interested in the fundamentals and origins of Scrum.

Continous integration. XP pioneer Martin Fowler explains this agile practice.

Pair programming study
This is the classic reference study on pair programming by Alistair Cockburn and Laurie Williams. It enumerates observed effects such as finding defects early, fewer faults in the finished code, faster problem solving, more learning about the system and systems development, improved work morale and more fun at work! The conclusion is that there is a small increase of 15% in the hours spent solving a problem using pair programming, but that this small cost is paid back times 15-60 times (!) by the reduction costs for testing later and reduced support required. Show this to your boss if they think it is inefficient to have two people doing one persons job...

An Extereme Programming Episode This is an example where Robert C. Martin and Robert S. Koss develops a bowling scoring application using test driver development, TDD, and pair programming. A really nice introduction on the feel and flow of working with these XP practices. (The example is also available as chapter 6 in the book RCM's book "Agile Software Development")

Adventures in C#: The Bowling Game Ron Jefferies, TDD expert, shows a detailed example of test driven programming and what happens when you use TDD when some classes already in mind. In the sequel to this article he shows another, more open minded, pure TDD approach and how that creates a simpler solution. These examples are both worth checking out as an introduction on what TDD is.

User Stories - Card, Conversation, and Confirmation If you think that a User Story is something you write on a index card and pin to you Scrum board, take a look at this!

Responsibility redefined model
Christopher Avery is well known in the Agile community for his book on teamwork and he often speaks at Agile conferences. To have a successful team you need to have people that are acting responsible. But what does that actually mean? Christopher defines responsibility different than most. Did you even loose your keys and the first though that entered your head was "Who took my keys"? If you did actually do that, it seems that you are human...and that you are following the same thought process when being faced with problems as all other humans! It is also the case that you might do yourself a big favor by checking out Christopher's very simple, but potentially life changing work at this link.

Christoffer Avery's book "Teamwork as an individual skill" has been called the only book on the subject worth reading by Fortune Magazine In this media kit there are 11 articles summarizing some of the ideas from his book. He also has a small FAQ about team work and leadership.

David Astels argues that TDD should not be seen as testing, but as the focus should be on defining behavior. The behavior will be specified as executable tests. Astels thinks that calling the executable specifications "test" affects the thinking process negatively though. So, he does not want xUnit, since then you need to call each part that you write a "test". Instead he proposes completely new frameworks with new names that will make it easier to focus on behavior. This whole concept is called BDD, Behavioral driven development. BDD, by the way, would be the same as correctly performed TDD. Here is a video presentation of the material.

Heartbeat Retrospectives A nice and short description on how to run a standard type retrospective at the end of each iteration.


Back to top