Agile software development with Scrum

Ken Schwaber, Mike Beedle 2001, 158 pages.

This was the first book written about Scrum. Ken Schwaber is the co-creator of Scrum together with Jeff Sutherland so he is clearly qualified to write about the topic. The book covers what is wrong with traditional techniques for managing software projects and teams. It also explains why Scrum provides a more functional working environment. Even though this is a short book already, the great news is that most of the beef is in the first part of the book. Thus, You only need to read half of it get a really good understanding of Scrum.

Agile Project Management with Scrum

Ken Schwaber 2004, 192 pages.

This is the sequel to Agile Software Development with Scrum. It contains a quick overview of Scrum basics, but except from that, it is collections of stories from real cases where Ken has coached companies, introducing Scrum. It is nicely organized with different chapters focusing of different aspects of Scrum. Real life stories like this is a great way to learn, and it also makes the book an easy and entertaining read. Another useful part of the book is the Appendix that lists the rules for the various meetings in Scrum.

Scrum and XP from the trenches

Henrik Kniberg, 2007, 140 pages.

This is Henrik Kniberg's description of how one Swedish company with about 40 developers is using Scrum after one year of experimenting with it. Lots of tips and down-to-earth details. If you like learning from examples, like most people, this is a really good introduction to Scrum. Even if you already know Scrum basic, you will probably be able to pick som new things up here. The book is also available as a free download from infoq.com.

Extreme Programming Explained: Embrace Change (2nd Edition)

Kent Beck, Cynthia Andres 2004, 224 pages.

The first edition of this book was written by Kent Beck in 2000. That was already an excellent book, perhaps the most important book on software development ever written. The second edition is a completely new book, rewritten to reflect five more years of experiences teaching and implementing XP. It does not describe a different method, it is just organised differently and presents the XP approach in a different way. The book covers problems with traditional type projects and how these are addressed by XP. This book should be mandatory reading for everyone involved with software development.

Agile estimating and planning

Mike Cohn 2004, 304 pages.

In this book Mike Cohn brings together most everything that the Agile community has learned in a decade about agile estimating and planning. This is the definite practical guide to the subject. The information in this book will be useful to CEOs, scrum masters, product owners, and team members. If you are working with planning or leading an agile project, you should get this book!

User Stories Applied: For Agile Software Development

Mike Cohn 2004, 304 pages.

In this book Mike Cohn makes his case that user stories is the best form of capturing and managing requirements for Agile projects. In doing so he compares this technique with others such as use cases and IEEE type requirements. He also shows how to work with users and user proxies to gather stories and how to go about to write good stories. Although user stories originally came from XP, they fit very well in, and are widely used with, other frameworks such as Scrum also. The beef in this book is about 140 pages. In those pages you have a complete guide if you decide to manage your agile requirements using user stories.

Part II of the book is called "Estimating and planning". We recommend that you skip this and refer to his other book, see above, dedicated to this subject instead.

At the end of the book he puts everything together is 40 pages long example of a team getting started using stories to create a new product.

There has been some critique about using stories for requirements. Alistair Cockburn claims that the fine granularity of stories makes the context of features unclear and that it confuses teams. He also claims that the granularity and lack of overview makes it easy to miss out on complete set of requirements. It seems like the techniques described in this book can be used, at least to some extent, to address these concerns.

Here is a presentation where Mike covers some of this material: Part1 and Part2

Writing Effective Use Cases

Alistair Cockburn 2000, 304 pages.

Alistair Cockburn is a veteran and a deep thinker in the Agile community. Most people doing agile development consider use cases as heavyweight and too much of an upfront planning approach (i.e. it causes wasted work due to putting effort in detailing requirements that will change over time and that may never be prioritised for implementation). Even so, Alistair's preferred style of managing agile requirements are through use cases. Although it causes extra work he claims it is possible to write agile use cases just in time and with different levels of granularity. If you prefer to work with requirements in this form, this is the definitive reference.

Agile Retrospectives: Making Good Teams Great

Esther Derby, Diana Larsen, 2006, 20 pages.

Holding retrospectives after each iteration where the team reflects and improves on their working methods is a vital part of agile development. After a while though, these meetings can get a bit mundane and loose some of their purpose. That's where this books comes in. It covers in detail how to design a useful retrospective meeting for your team, and it has so many ideas you will not get bored with your meetings for a long time.

Here is an one hour video where the authors present these same ideas.

The Enterprise and Scrum

Ken Schwaber 2007, 176 pages.

This is a thin book, 100 pages + a few appendices. It contains assorted tips from Ken on how to go about introducing Scrum across an entire Enterprice. It starts with a suggested approach and some information on about what to expect in terms of problems and gains. A big part of the value of this book is that it prepares you for the difficulty of the task. If all stakeholders are not prepared for what is about to come and properly motivated before the transition, the pain and the tension it brings will very likely cause the transition to fail.

If you have tried some Scrum/Agile projects and are happy with the results, this book will prepare you for the next step in the transition. Remember, all changes that are not allowed to spread up and across an organization will fade away with time as the organizational gravity pulls the changed parts back towards the previous ways of working. So, don't get discouraged by the amount of work lined up in here. Just dive right in...

Fearless Change: Patterns for Introducing New Ideas

Mary Lynn Manns, Linda Rising 2004, 273 pages.

Have you tried introducing new ideas and changes into your workplace? How did that work out? Maybe you learned just like us that change is surprisingly hard, and if it by any chance works at all, it takes time. This book teaches that each and every individual in a company has his own style for responding to change and every person needs a different a amount of time and different types of information to decide if they want to support a change or not. By using the patterns described in this book you can present your ideas in a way that makes change more possible to happen. The book also shows you that sometimes an organization may not be ready for a change, and then you may just save yourself the time and effort and stop trying pushing it through.

The Servant Leader: How to Build a Creative Team, Develop Great Morale, and Improve Bottom-Line Performance

James A. Autry 2004, 288 pages.

The Principles Behind the Agile Manifesto says: "The best architectures, requirements, and designs emerge from self-organizing teams". Thus, in many organizations, the role of management will change whan transitioning to agile work methods. Instead of using a command and control management style, managers now need to be practicing true leadership.
Servant Leadership is a concept that is well aligned with agile philosophy. In this book James Autry introduces the subject in a very readable and practical way.

Lean Software Development: An Agile Toolkit

Mary Poppendieck, Tom Poppendieck 2003, 240 pages.

The first book in this series. See below.

Implementing Lean Software Development: From Concept to Cash

Mary Poppendieck, Tom Poppendieck 2006, 304 pages.

The agile movement has some of the same roots as the lean movement, empowering people, eliminating waste etc. Most people have heard about the success of the Toyotas production system and of its product design methods. Toyota uses its philosophy in both areas to consistently stay four times more productive and have 12 times better quality than their competition.

The two books by the Poppendieck's is an attempt to translate the values behind this success to thinking that applies to software development. The books can be read as an explanation on why agile work methods work, motivated by lean principles. It can also be used by advanced agile practitioners to find ideas on how to optimize agile processes.

Although getting inspiration from production systems is what caused the software industry be in its current sad state from the beginning, these books contains some interesting ideas on contract management etc. The view is also more on company level, while most agile literature tends to focus on individual projects.

Fit for Developing Software: Framework for Integrated Tests

Ward Cunningham, Rick Mugridge 2005, 384 pages.

Many agile projects manage their requirements by using user stories. A story is a short description of something a user can do in a system. The story is not the complete requirement, more of a short reminder, a promise about a future conversation with the customer about this. I.e. the details are outlined with the customer just in time before implementation, thus increasing communication bandwidth and eliminating waste in the form of queued up obsolete requirements and lost information due to handovers.

When working like that the customer is supposed to specify detailed requirements, just in time, as executable acceptance tests. That way you get an always up to date, executable requirements specification that is run several times every day, ensuring that all requirements are still valid and still met. Compare this to the traditional approach with a 600 page requirement specification that is rarely read and quickly grows obsolete as a project gets going.

Executable acceptance tests has been one of the least used agile practices so far. Probably due to difficulties for customers to write and read tests like these. Now it seems that Ward Cunningham has resolved this issue with his FIT framework. Using FIT, users can write acceptance tests as tables in word, excel, html or on a wiki. Most people is used to working with tables, and the language used in the tables are directly from the business domain. To get the tests executable a programmer creates a simple mapping for each type of table against the domain objects of the solution.

The book recommends that the tests are run against the service layer, bypassing any GUI. Partly since the GUI is the part that changes most often in a system. Partly since testing through the GUI slows down tests and discourages developers from running them as often as desired. By concentrating on business logic in the test table language that emerges, the structure of the system is also improved.

This book is split in two parts; the first half can be read by non-programmers and describes how to write tests. The second half is for programmers and describes the very simple development of "fixtures" that needs to be done to support tables. The book also has a long example showing a fictive company that recovers from some problems using FIT.

This is a very easy and interesting read. If you have access to testers/customers/product owners that can write tables this is a brilliant approach. If programmers are to write the tests, they could use other tools such as xUnit, but then the tests would not be readable to business people like with FIT tests.

FIT is available for Java, .NET, Python, Perl, Smalltalk, C++ and Ruby. The version using a wiki is called FITnesse. The examples from the book have been ported to C# , Visual Basic.NET and J# in .NET 1.1 and .NET 2.0 at this site.

---

---

Test Driven Development: By Example

Kent Beck 2002, 240 pages.

This may have been the first book with a detailed description of Test Driven Development. In test driven development, writing a unit test is not just a testing activity, but more of a design activity. The idea is that you first implement a small simple test that describes the problem that the code shall solve. After that you run the test and verifies that it fails. Next you go on to implement the actual solution, as simple as possible, making sure that you do not add anything that is not absolutely needed to get the current test case to run. When you have the test case passing you take a look at the code, rewrite it to make sure there are no duplication anywhere and that the code, while being as simple as possible, clearly describes the design and intention of the solution. Then you start over with another test. When doing pure TDD each test-implement-refactor cycle is less than 10 minutes. In that way the code and design will emerge incrementally. It will always be 100% covered by repeatable automated test. At all times it will also be as simple and clean as possible, not letting any technical debt accumulate in the system.

Although this book describes the philosophy of TDD, the examples are not that great, one of them develops a test framework for python in python, using the developed test framework to test itself as it emerges. That is really a completely unnecessary mess of an example...The book also contains some scattered material about refactoring and design patterns. All of that material is better described in other books and does not add to the value of this book.
A few of the examples are readable and useful, do browse through the first one if you get your hands on this book. In general there are much better books to start with than this now.

The Five Dysfunctions of a Team: A Leadership Fable

2002, Patrick M. Lencioni, 228 sidor.

A well functioning self-organizing team is the core of agile development. A team like this creates a whole that is bigger than its parts. So, to achieve hyper productivity like some Scrum teams have, it is likely that it is not enough to focus on technical practises. Probably there is some need to focus on the teamwork aspects also. In this management classic, Patric Lenconi describes his opinion on what a efficient well functioning team is. The book is written as a business novel and it is an easy, entertaining read. The main character is Kathryn. She takes over as CEO in a startup in Silicon Valley. She describes her theory on teamwork, the 5 dysfunctions, and coaches the management team through a series of exercises to get them into a productive state.

In the end there is a short section, 25 pages, that describes the theory along with some ideas on to improve oneself. This is good stuff to know if you are working in a team or leading a team.

If you think the approach suggested in this book is a bit touchy, feely...take a look at the next book on the list!

---

Working Effectively with Legacy Code

Michael Feathers 2004, 456 pages.

Most systems developed using pre-agile methods don't age gracefully. Instead they deteriorate over time making them more fragile and expensive to maintain. Usually it takes about 5 years for a system like this to get to a point where it is no longer profitable to maintain it. The choice is then to throw it away and start over from scratch or to try to get the old system back in shape. Rewriting from scratch is rarely the best solution, since it takes a long time for a new system to get to the point where it can replace the old one.

This is the classic text that tells you how to approach the task of cleaning up the mess and getting an old system back to a maintainable state.

---