Book Review – Succeeding with Agile: Software Development Using Scrum

I have been a fan of Mike Cohn and his latest book Succeeding with Agile: Software Development Using Scrum is another great book.  He blends a good mix of theoretical and practical techniques drawn from his past experiences.  This book doesn’t show you how the Scrum Framework works, but it is more of a cookbook of good practices and suggestions that you can help you succeed with Scrum.  So if you are new to Scrum or looking for an introduction to Scrum I suggest you read some other sources first such as the Scrum Guide (by Schwaber and Sutherland) or the Scrum Primer (by Deemer, Benefield, Larman and Vodde) and then coming back to this book for tips and advice as you implement Scrum.

I was able to relate to some of Mike’s observations with my own experience and found myself nodding my head in agreement to some of his sections on ‘objections’ and various stories throughout the book.  As a result, the book felt very personable as I felt like I have been there done that.  He does offer some practical advice when dealing with the various ‘objections’ that you may encounter along the way.    He also points out the challenges in adopting and transitioning to agile.  The following is an important quote from the book:

I’ve personally witnessed several failed agile adoptions that could have been prevented. The first was in a company that had spent more than a million dollars on its transition effort. Executives brought in outside trainers and coaches and hired five people into an “Agile Office” to which new Scrum teams could turn for advice. The company’s failure was the result of thinking that the implications of adopting Scrum would be restricted to only the development organization. The executives who initiated this transition thought that educating and supporting developers would be sufficient. They failed to consider how Scrum would touch the work of salespeople, the marketing group, and even the finance department. Without changes to these areas, organizational gravity pulled the company back where it had started.

A common theme throughout the book is that there is no ‘standard’ way of doing agile and that it must be adapted to the organizational context and project.  He devotes a whole chapter, ‘ADAPTing to Scrum’ [Chapter 2] to this topic.

Although it is mainly centered on Scrum, Mike describes various other techniques and methods to produce a handbook that is thorough and complete for any Agile practitioner.  Scattered throughout the book are real-world case studies drawn from the Mike’s experience helping many software organizations adopt Scrum, and ‘things to try now’ sections based on his advice offer practical, quick ways of coming up to speed fast.  I really liked the chapters on New Roles [Chapter 7] and Changed Roles [Chapter 8] where he describes the 3 key Scrum roles but also identifies how the traditional roles changes to fit into an agile development framework.

I highly recommend reading this book as part of your Agile training, whether you are implementing Scrum for the first time or an experienced practitioner.  It is an easy and good read.

Executive Support For Agile Adoption

One of the biggest failure to adopt Agile is not having the right mindshift change.  This mindshift change can be quite signficant for some.  Agile methodologies are a paradigm shift from tranditional “monumental” waterfall methodologies.

Managers and organisational leaders have a key role in helping adopting and transitioning to agile and this starts with the right mindshift change.  Esther Derby’s article, The Three Pillars of Executive Support for Agile Adoption outlines what is needed to succeed from managers.  What underpins the management support for agile adoption is managers having the right agile mindset.

It can be very difficult for managers to let go of Gantt charts, specific milestones and commitment dates they are accustomed to.  No matter that few projects actually meet those targets, managers fear how much worse it would be if the targets and schedule (no matter how unrealistic) did not exist at all.

Ultimately, it will take time to change the mindset and opinion of managers who have dug into their positions over years of working with projects that miss deadlines, deliver low quality, systems that don’t meet customer’s needs, and throw up change control walls.

The 3 points in Ester’s article are not that uncommon.

1. The Power of “No”

How many times do we hear “we have always done it this way”? Manager’s need to demonstrate, subscribe to and commit to the agile practices, values and pinciples and this means not allowing people to fall back into old habits.  This includes removing organisational impediments.

It’s predictable that when there’s a new method, process, or policy, people will request exceptions so they can continue to do things the old way.

There will be challenges in adopting any new methodology that you are not experienced with.  Adopting agile is no different and will take some time.  This is where an experienced agile coach may come in handy to guide the project along to successfully apply agile principles, values and practices.

2. Address Systemic Issues

Ester describes 3 systemic issues.

Three common patterns that I see driving exceptions are technical debt, overstuffing the pipe, and misaligned reward structures.
……
No methodology can fix these issues.  These are management problems, and it takes management to fix them.  Without management attention to systemic issues, you will achieve incremental improvements, at best.

Not fixing these systemic issues, Ester rightly points out that this “will sow cynicism in the organization”.

Consequently, agile will be seen as a failure when in fact the cause is nothing to do with the process or methodology used but the lack of management’s ability to address systemic issues.

3. The Ability to Hear Unwelcome News

In the agile community we believe in transparency and visibility.  Within HP (and EDS), there is training which educates us to operate ethically and with integrity.   To do this teams should be transparent with their management.  Likewise, management will need to be transparent with the customer.  And this helps build trust with the customer.

Status reports where it goes from green, green, green, green, and then suddenly red should not happen.  With focus on working software in small releases, agile methods provide transparency of progress.  However, managers will need to have “the ability to hear unwelcome news” should it occur and deal with this effectively.

The four value statments in the Agile Manifesto, shows perferences we should take.  Managers have a key role to play when it comes to “Customer collaboration over contract negotiation”.  Managers need to set realistic expecations with the customer.  Unrealistic expectations lead to shortcuts, continuous fire fighting, accumulation of technical debt, and ultimately delaying the project more.

Management often resort to adding more resources to an already late project thinking more people-power will solve the problem.  Ironically as Fred Brooke coined in the book The Mythical Man Month the term Brooke’s Law – “adding manpower to a late software project makes it later”.  Instead, Ester encourages managers to —

Take management action.  Have the difficult conversations and make the difficult choices to reduce scope or extend the date.

Agile methods don’t provide a silver bullet that guarantees success and requires a lot of management support.

Managment support for agile adoption is not just applying lip service and saying “we will adopt agile”, but demonstration of on-going support.  Skills are important, but having the right agile mindset is more important.

A lot of agile is common sense but without the right mindset adoption can be difficult and fraught with danger.