Review: Implementing Lean Software Development


Implementing Lean Software Development, by Tom & Mary Poppendieck, is part of the Kent Beck Signature Series from Addison-Wesley.  All of the books I’d read in that series have been excellent, so it was no surprise that this book was also a great read.

As a newcomer to Lean principles, I was looking for something that would explain its essence, and how it can be applied to working environments, and I found Implementing Lean Software Development satisfied all those requirements.  I have a background in Scrum, and there were enough references to shared practices (respect for people, short iterations, defer responsibility) to make it pretty easy to draw parallels between the two approaches.

Implementing Lean Software Development is peppered with examples and real world application of Lean principles in software and non-software settings which makes the ideas behind the approach easy to digest and to apply to one’s own situation.  It’s obvious that a lot of care has gone into producing this book: there are very few wasted pages, which — considering the subject — shouldn’t be that surprising!

Many of the principles presented in the book are also principles shared by Scrum.  However, it’s easier for a Scrum adoption to fail in an organisation because the practices are often presented before the principles: many more people would be able to describe the ceremonies of Scrum, but none of the principles.  There is a much more obvious philosophy to Lean which makes me feel it would lead to fewer false starts for organisations attempting to transition to an Agile software development structure, but that is merely conjecture at this point!

Facilitation Kit

The following post lists the current contents of my facilitation kit.  The kit is not a static collection and I add to it quite frequently.  Most of the links on this page go to Ryman in the UK (so I can order repeat items), but most are international products.

Record Cards & Sticky Notes

Pens

For Hanging Things on Walls

Assorted Bits and Bobs

Question Poster for Daily Scrum

If your team have difficulty sticking to standard questions in the daily scrum, here’s a poster you can hang in your team room:

Daily Scrum Poster

The questions are adapted from the latest Scrum Guide, which focuses on teams and sprint goals instead of individuals and an abstract concept of “progress”.

Review: Drive by Dan Pink

Drive” by Dan Pink first came to my attention after it was cited in two of the keynote talks at the 2013 Scrum Global Gathering in Paris.

Drive focuses on the same material as covered by Dan Pink’s talk at TEDGlobal 2009 called, “The puzzle of motivation“, which has so far received almost 7 million views, putting it into the top ten most-viewed TED talks of all time.

The talk and the book describe what Pink calls intrinsic motivation.  Intrinsic motivation is presented as the antithesis of traditional carrot-and-stick motivation, which Pink labels “Motivation 2.0” (Motivation 1.0 is reserved for the need for human fundamentals such as food, clothing and shelter).

Instead of attempting to motivate employees for “positive” behaviour by offering more and more money, Pink argues that skilled people in creative roles (i.e. developers in a Scrum team) will be more motivated by the three factors of intrinsic motivation, that is:

  • Mastery
  • Autonomy
  • Purpose

So how does this apply to developers in an agile environment?

As long as developers perceive that they are paid as well as equally-skilled colleagues and workers in other companies in the same industry, the best way to motivate them will be to provide an environment where the above three factors are allowed to thrive.

Giving developers a stake in a product they are developing helps to cultivate a sense of purpose.  Involving developers in product workshops where they can engage with customers, and releasing software regularly allows developers to see their labours realised, and to understand that their efforts are appreciated.

Autonomy is one of the principles behind the Agile Manifesto:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Trust is the key to autonomy.  Organisations should make sure the right people are hired, then make sure they want for nothing when it comes to getting the job done.

Mastery can be encouraged by supporting whatever it is that developers need to get better at their job.  This includes using Scrum Masters to remove impediments to allow developers to access their ‘flow’ state; ensuring that being a good developer is a valid career goal in your organisation and not a step to something different, such as architecture or management; and encouraging a culture around development, such as communities of practice.

Drive is in some ways quite a radical book.  The ideas are very simple, and seem like they should be common sense, but the difference between the message it delivers, and the reality of most organisations makes the reader wonder why more organisations aren’t making the changes it recommends.

Review: Impact Mapping


Impact Mapping by Gojko Adzic is a great little book with a big message.  At only eighty-six pages, it can easily be read in one sitting, but it’s unlikely you’ll only read it once.

Impact Mapping is a technique that businesses can use to explore ways in which to meet their goals.  The book has a strong software development focus, but is clear in stating that software is not always the answer to achieving goals: pointing out that marketing and other business functions can often provide solutions.

I liked this book because it enforces honesty: the technique leaves no room for pet features or bias.  Software features must be traceable back to real business goals or they can be legitimately challenged.

Impact Mapping compliments user stories well: in addition to the usual pattern of “In order to [value], As a [user], I want [feature]”, we are now able to ask why we want to help that user achieve that value.  After all, I can write software to allow a user to search for a product in an online catalogue, but what does that do for me?  Will that increase my sales figures by more than if I spend the money I’d use to pay developers on my Google Analytics budget instead?

Impact Mapping puts business goals front and centre, and encourages businesses to evaluate all possible paths to attaining that goal, and challenges them to use metrics (e.g. increases in sales) to challenge their assumptions as often as possible.

In addition to the technique, the book also describes common pitfalls for businesses and facilitators, including how to deal with an existing product backlog.  As someone who has encountered their fair share of “questionable features”, I really hope Impact Mapping becomes a standard technique for generating software requirements.

The side-effect of using a technique which guarantees features of real business value is that it is so much more motivating as a software developer to work on bona fide features.  One of the worst part of being a software developer is developing features you know will never be used.

I’d recommend anyone interested in improving the commercial success of the software development projects to read Impact Mapping as soon as possible!

Review: Scrum Mastery

Scrum Mastery: From Good to Great Servant Leadership by Geoff Watts contains some excellent advice to new and experienced Scrum Masters alike.

The book is divided into nine characteristics of a great Scrum Master, identified by the mnemonic RETRAINED:

  • Resourceful
  • Enabling
  • Tactful
  • Respected
  • Alternative
  • Inspiring
  • Nurturing
  • Empathetic; and
  • Disruptive

Several example behaviours of each characteristic are described, with illustrations on the difference between the behaviour of a good Scrum Master in a given situation contrasted with the behaviour of a great Scrum Master.

The scenarios are engaging without being patronising, and the reader is left in no doubt that Watts knows the subject matter well.  I suspect this is a book that will gain popularity as a handbook for Scrum Masters, as it is quite easy to dip in and out of, and the characteristics are quite well defined.

This review is based on the Kindle edition of Scrum Mastery, and there were a number of disappointing aspects to that edition: for example, there are no hyperlinks for endnotes, and some of the punctuation was quite inconsistent.  This doesn’t subtract from the quality of the content, but it does occasionally distract.

All in all, Scrum Mastery was a rewarding read, and is highly recommended.

Review: Agile Software Development with Scrum

Agile Software Development with Scrum by Ken Schwaber and Mike Beedle provides a satisfying read for those with an interest in the origins and reasons behind Scrum.

Although quite a short book at 154 pages, it is not always an easy read, particularly when presenting Scrum from different views, such as risk management, new product development, and knowledge creation.  Many readers will probably enjoy a book with more practical tips, or a book with a slightly less academic tone.

Schwaber and Beedle make a good case for why traditional defined processes aren’t a good fit for software projects, and there’s a great metaphor comparing an autonomous Scrum team with a military unit, which is useful.

In summary, I wouldn’t recommend putting this book at the top of your reading list, but if you’re trying to fill out your knowledge of Scrum, you may find it worth a visit.