by John Turner
Posted on February 02, 2011
Mike Cohn is a well respected author, trainer and coach. I follow his blog at Mountain Goat Software avidly and am hoping to attend his Certified Scrum Master training in the near future. In the interim, I obtained a copy of the three books he has published and I will be working my way through them as time permits.
I am not new to Agile or Scrum (but of course always learning), but more recently I have been tasked with building a Scrum team, delivering working software, and looking to further spread Scrum. Succeeding with Agile describes how to introduce and spread Scrum within an organisation, and the challengesrewards of such an endeavour. I was looking forward to seeing how my experiences would compare to the experiences relayed by Mike.
Part 1 - Getting Started
As an opinion leader championing the transition to Agile, you will find yourself extolling the benefits of Agile methodologies frequently, perhaps even before having a full appreciation of the challenges ahead. Mike provides a concise summary of the challenges you will face in adopting Agile, and the reasons why overcoming these challenges are worthwhile. What I like about this, is that Mike presents cold, hard facts backing up the opinion.
Mike goes on to introduce the ADAPT acronym that represents the common activities necessary for a successful Scrum adoption. These being Awareness (that the current process is not delivering), Desire *(to adopt Scrum as a way to address current problems), *Ability (to succeed with Scrum), Promotion (of Scrum) and Transfer (of the implications of using Scrum throughout the company). There are also a number of interesting quotations from people who have succeeded and failed with agile adoption. I found the insights into organisational change were particularly interesting.
Prior to the adoption process, a few decisions are required to best position the organisation for a successful adoption of Agile. Like Agile itself, the adoption process can be delivered using several different practices or patterns (or indeed any subset of same). Typically ‘Starting Small’ is applied through a pilot project and team (or teams depending on the scale of your organisation). A very useful comparison is provided between the ‘Starting Small’ approach and the ‘All In’ or ‘Big Bang’ approach. I thought the discussion on spreading Agile was interesting and described the pro’s and con’s of different approaches to spreading Agile subsequent to ‘Starting Small’.
Agile processes themselves can be used to spread Agile within the organisation. Mike discusses this along with the development of improvement communities. Improvement communities are focused on improving how an organisation performs specific tasks or operations. One such improvement community might be focused on Agile itself, another automated testing and another continuous integration. There are a broad range of practices associated with Agile and for most projects, adopting them incrementally is the only viable option.
Selecting a pilot project (and indeed identifying the goals of the pilot project) can be quite a difficult process and Mike discusses desirable characteristics of pilot projects. Typically these characteristics focus on project duration, size, importance and business sponsor engagement. Mike suggests that goal of a pilot project is not to prove the Agile methodology, but that a pilot project should be considered a success if “…the teams involved in the pilot learn about what is likely to work or not work, which aspects of Scrum will be be easily brought into the organisation, the types and sources of organisation-specific resistance, or any other similar information…”.
Part 2 - Individuals
We have all experienced resistance to change (and perhaps resisted change) and overcoming this resistance starts by understanding why it exists. Mike looks at resistance to the introduction of Agile, how to anticipate it and how to best manage resistance so that it does not have a detrimental effect on the transition. Must be the frustrated philosopher in me but I really enjoyed the social analysis.
The role’s of the Scrum Master and Product Owner are described along with the desirable attributes of the people who fulfil these roles. An interesting comparison was made of the technical team lead and project manager roles and why a default decision should not be made to map individuals from these role’s to Scrum team roles without accessing the suitability of candidates individually.
When introducing Agile methods, the first question most people will ask is “How will my role change?”. The effect of introducing Agile is described for the roles of analysts, project managers, functional managers, programmers, database administrators, testers and user experience designers. I found some of the comments on architects very striking. For example, Scott Amber called non-coding architects “Ivory tower architects” and most any company I have worked for have a liberal sprinkling of these! Further, the numerous unnecessary meetings these architects prefer were justified because “..in an unnecessary meeting, all attendees are equally productive and valuable.”. I personally find recurring meetings, meetings without agenda, meetings with unnecessary attendees and meetings without purpose intolerable.
The daily stand-up, retrospectives, planning poker and other Agile practices are only half the battle. The technical practices that have become synonymous with Agile complete the picture. The most important of these are Test Driven Development, Refactoring, Collective Ownership, Pair Programming and Emergent Design. These are described briefly along with useful advice on how to introduce these practices to the team. As with Agile itself, the best way is iteratively with an emphasis on continued improvement. (This was one of the two chapters that I specifically asked my team to read.)
Part 3 - Teams
Team structure is an important factor in the productivity of a team. Mike’s thoughts on team structure reflect my own. Primarily these are that teams should be small, members should be dedicated (not on multiple projects) and teams should be standing teams (not disbanded at the end of projects). The discussion on multi-tasking resonates particularly strongly as I observe within my own team the difference in overall productivity between those 100% allocated to the project and those who multi-task! It’s not a reflection on the individual, but on the lack of appreciation of how disruptive context switching can be.
Creating a team does not necessarily result in effective teamwork. The Agile Manifesto includes the statement “individuals and interactions over process and tools” and it is those individuals and interactions that create (or not) effective teamwork. Team dynamic is immensely important to the productivity of the team, which is one of the reasons I much prefer standing teams or teams with minimal churn. Mike makes some useful sporting analogies to emphasis this point.
Managing a team that is self-organising would appear to be a contradiction but Mike explains how one can manage a self-organising team by changing the factors that have an effect on the team’s decisions. One example was based on how an organisation defines performance and it states that “An organisation that favours long-term success will be more likely to invest in training, support working at a sustainable pace, be willing to allow employees time to explore novel ideas, and will not exchange meeting a near-term deadline for unmaintainable code.”. It’s quite obvious how this would effect decisions made by self organising teams.
The product backlog is one of the major artefacts of Scrum and it is one around which the teams activities focus. Using the product backlog to manage requirements and workload is paramount to the success of Scrum and this is discussed at length with ample examples to support the recommendations.
The Sprint is probably Scrums most recognised practice but there is significant variance in how different teams run their Sprint. Advice is provided on the length of a Sprint, best day to start a Sprint and how to incorporate specialities into a time-boxed Sprint. This was a great section with very relevant advice through which Mike’s experience really shone through.
The chapter on planning is interesting. I particularly liked the differentiation between an estimate and a commitment. Alas, I could imagine this being seen as playing with words. It’s a good start to Agile planning and I will soon be reading more on the subject as I have a copy of Mike’s ‘Agile Estimating and Planning’ book that I have yet to read.
There are very few organisations that would openly say that they do not have a focus on quality, but the mechanisms they employ to ensure quality vary widely. The Agile approach to maintaining quality is one centred on team quality focus and appropriate test automation. This is described so well that I asked my team to read this chapter of the book (those safari IT subscriptions prove useful again).
Part 4 - The Organisation
One of the things that can be hard to grasp without direct experience, is how Scrum will scale to larger projects. Some of the practices that can support scaling Scrum are described and expanded upon using the example of a productivity suite (similar to Office, Google Apps etc. ). These are some of the things that are difficult to just read about and only real experience will give you the feel of what works better in certain scenarios. But the material presented is certainly a good start.
Distributed teams will always throw up unique challenges and some of these are described along with techniques that can be used to meet these challenges.
Interaction with sequential approaches can be difficult to get right, but is often necessary during a migration to Scrum. Some of these pain points and suggestions on how to address them are covered. In particular, some of the insight into interactions with governance and compliance are very informative.
No man is an island, and the same can be said for a Scrum migration. Any migration also has to consider its effect on things like Human Resources, Facilities and the PMO.
Part 5 - Next Steps
Depending on how Scrum adoptions are approached, an early consideration may (or may not) be to try to quantify the effect of the Scrum adoption against certain objectives. I must say, this is not something I have considered but I certainly see the benefit of such metrics. To echo Mike’s view, these metrics can be a very useful tool to focus on what Agile is delivering and why the pain is worthwhile (especially when an Agile adoption is stalling or going backward - “organisational gravity”). Of course, “Lies, damn lies, and statistics” can be used against an Agile adoption effort and caution should be used so metrics are viewed in context.
There is something very compelling about Agile and so reading well authored books on the subject (of which this is definitely one) is effortless.
This book delivers a thorough introduction to Agile, the key principles and practices, and how they might fit in different organisations. It also makes valuable suggestions as to how Agile might be introduced into an organisation, how it might grow and what it might deliver.
I enjoyed the liberal use of anecdotes to convey key points and concepts. These relay evidence of Agile working and delivering for organisations, rather than grand theories and assumptions.
I would highly recommend this book for anyone involved in pioneering Agile in an organisation, as well as those who have a growing interest in the subject.