In his recent book, Agile Adoption Patterns: A Roadmap to Organizational Success, Amr Elssamadisy provides a framework for creating a context-specific agile adoption strategy. Rather than suggest the same set of practices for everyone, he helps you figure out which practices will be most effective at reaching your organization's specific goals. This practical approach will get you started on your agile path with a minimum of overhead and frustration.
Successfully adopting an agile approach to software development can have a huge impact on the the success of an organization. Agile approaches can allow more accurate assessment of project progress, enable finer control over software projects on an ongoing basis (ensuring that what gets delivered will be useful rather than just what the initial spec asked for), lead to higher-quality and more maintainable software deliverables, and can boost morale and build trust within the organization. Unfortunately, as many of us in the agile community have learned, making the shift from a traditional software development approach to an agile one is just plain hard. Figuring out which agile practices to adopt, and figuring out how to implement them in your organization's unique context is a daunting task. As a result, many organizations endure a lot of confusion and frustration while making the transition, and many abandon the effort before realizing all of the benefits a successful agile adoption can bring.
Elssamadisy provides a practical guide to help you avoid the most common pitfalls of agile adoption. For example, one of the most common pitfalls is attempting a "big bang" transition - he shows you how to build an incremental, iterative adoption plan instead. He encourages an agile approach to agile adoption: take small steps in (hopefully) the right direction, and use short feedback cycles to adjust your approach and determine what steps to take next. At the same time, he helps you get the most bang for your buck, providing techniques to assess which business values are most important to the organization, and showing how to select an initial set of practices to support those specific values.
The book is targeted towards readers who have a basic understanding of agile practices, and are interested in learning how to apply them effectively to real-world projects. This book belongs on the bookshelf on anyone who is interested in helping a traditional software organization make an effective transition to a more agile way of working.
Context-Driven Adoption
The first two sections of the book (Part I: Thoughts about Software Development, and Part II: Crafting an Agile Adoption Strategy) set the stage of the book.
Part I expresses two guiding principles for agile change agents:
- Learning is the Bottleneck.
When in doubt about how to proceed with any given process or task, find an option that speeds up learning. Elssamadisy advocates seeking out the type of feedback cycle common to many agile practices:
1) set a goal, 2) perform an action to achieve that goal, 3) compare the outcomes of the action and the original goal, 4) change the action accordingly and go back to (2).
Learning happens in step (3) and is applied in step (4).As well, Elssamadisy stresses the importance of communication in order to magnify learning, by spreading it quickly between the individuals involved in the software development effort.
- Personal Agility.
Elssamadisy borrows ideas from Chris Avery's "Responsibility Process Model" to help the reader stay in the productive frame of mind necessary for driving change in any organization. This section gives several suggestions of how to avoid the common pitfalls of blame, justification, self-pity and shame, and obligation (that is, feeling helpless instead of in control of your choices), in order to reach (and stay in) responsibility, "a state of mind where we take ownership for our situation. If things aren't as we prefer, we take action to change them. This state is the starting point for personal agility."
Part II is perhaps my favourite part of the book. It does something no other book about agile practices that I've seen does: it explicitly maps various "business values" (that is, goals such as "Reduce Time to Market" and "Increase Quality to Market") to the agile practices that help reach that goal and deliver that value. This provides a mechanism for basing your agile adoption strategy on your organization's context: first, identify which of the business values are most important in your organization, then from there identify the agile practices which enhance that business value.
Elssamadisy also maps common "smells" to the agile practices that will help you eliminate them. (Smells are generally easier to recognize than business values, so starting with the smells apparent in your organization is can be an easy way to decide which agile practices to adopt first.)
Furthermore, Elssamadisy explains how the various agile practices relate to each other. Many of the agile practices are very difficult to implement if certain other practices are not in place first. Elssamadisy suggests a rough ordering for the group of agile practices that address each business value and smell.
This context-driven approach to agile adoption is really something that has been missing in the agile literature, and I'm glad to see it take center stage in this book. Having been involved in several not-so-smooth agile adoption efforts, I can attest to the need to adopt agile practices in a context-sensitive, iterative manner - especially in large organizations.
The Patterns
The Patterns section contains patterns for all of the most common agile practices used in the field. They are broken into five groups:
- Goal and Cycle:
two basic patterns that form the component parts of many agile practices.
- Feedback Practices:
Iteration, Kickoff Meeting, Backlog, Planning Poker, Stand Up Meeting, Done State, Demo, Retrospective, Release Often, Co-located Team, Self-Organizing Team, Cross-Functional Team, Customer Part of Team, Evocative Document, User Story, Use Case, and Information Radiator.
- Technical Practices:
Automated Developer Tests, Test Last Development, Test First Development, Refactoring, Continuous Integration, Simple Design, Functional Tests, Collective Code Ownership, Pair Programming.
- Supporting Practices:
Coach, Engage the Community, Reading Circle, Workshop, Classroom Training.
- Pattern Clusters:
Iteration Cluster, Communication Cluster, Evolutionary Design, Test Driven Development, Test Driven Requirements.
In particular, it's good to see the supporting practices included. These are not agile practices per se; they are just practices that aid in the learning of any new body of knowledge. Neglecting these practices makes learning proceed more slowly and painfully than it needs to.
Each pattern includes useful tools to help you determine whether the given practice fits your agile adoption plan: an explanation of the business values this pattern addresses, a description of the context in which the pattern is often useful, and a more in-depth explanation of the forces at play which the pattern helps resolve. By reviewing these sections of a pattern, the reader can determine how much value the pattern may provide in his or her context.
For example, here are the sections from the "Demo" pattern that are helpful for determining a "fit" for your situation:
- Business Value:
- Putting requirements and design on paper is good, but not enough to gain confidence that an application meets the needs of the organization.
- Confidence is gained by visibility and regular, demonstrable progress.
- Working software gives stakeholders confidence that true progress is being made.
- Partial completion statistics - such as we are 30% done because the requirements and design are fully complete and reviewed - are faulty. Developers have a track record of being optimistic.
- The work done to get to working software involves removing many defects that only show up in the later stages of development.
- The earlier a defect is found, the cheaper it is to fix.
- Finding and fixing defects is a form of learning, and learning is the bottleneck of software development.
- An envisioned solution is not always as we hope. When the software is built and tested, it sometimes doesn't solve our problem even though it is exactly what we asked for.
Demos increase visibility to the stakeholders, increase product utility by giving the customer a concrete system to evaluate, and support iterations. This means it has a secondary effect on business values directly affected by iterations.
Context:
You are on a development team performing iterations and have stakeholders outside of the development team that are interested in the progress of the project.
Forces:
The patterns then presents sections to help you adopt the practice effectively and avoid the pitfalls many agile adopters fall into:
- Therefore:
The pattern description. The pattern resolves the forces within the stated context.
Adoption:
Steps, ordering, guides to adopting this pattern.
But:
Negative consequences that can occur from applying this pattern.
Variations:
Different ways this pattern has been implemented successfully other than that described in the Therefore section.
References:
Where to read more.
These sections distill a lot of the wisdom of the agile community in a way that is bite-sized and relevant to the task at hand. If you're adopting a practice and feel it's not providing value, these sections can help you decide what to adjust about your approach to get more value out of the practice.
I especially like the But section. It is sometimes frustratingly hard to find candid descriptions of the many ways some common agile practices can go wrong. The inclusion of this section helps newly-agile teams set realistic expectations (not everything will work out perfectly; there are a lot of ways to mis-apply agile practices), and gives them some red flags to look out for to keep them on track. Most of the time the But section also contains good advice about what to do if you have gone off track. Since all agile adoption efforts run into several of these common hiccups, it's good to see them addressed.
The Case Studies
The third section of the book contains two real-world case studies of agile adoption efforts. Agile literature often describes what a "fully agile" team looks like, which is quite different from a team slowly transitioning to agile. This can discourage agile advocates when they don't immediately attain results similar to those described. It's refreshing to read about real, warts-and-all, adoption efforts. The truth is that, especially in large organizations, changing personal and organizational habits is a long, difficult process. It won't go smoothly, but over time huge strides can be taken by determined individuals and teams. The two adoption efforts described clearly illustrate this reality. Sometimes in the long, hard slog of helping an organization move closer to agility, you just need to know that others have faced similar roadbumps , to overcome your doubts and realize you're making genuine progress.
Conclusion
This book isn't for everyone. I wouldn't recommend it to those completely new to agile concepts - Elssamadisy assumes the reader has at least a superficial knowledge of the most common agile practices and principles, so beginners may find that the book does not go into enough detail in some cases. I also wouldn't recommend it to experienced agile coaches; they probably intuitively understand most of what the book covers.
However, if you have read enough about agile software development to pique your curiosity, but don't know where to start, this book is for you. If you have a basic understanding of agile practices but don't feel confident enough to be the "agile expert" on your team, this book is for you. If you're working on an agile team and feel you're not getting as much benefit from the agile practices you're using as you would like, this book is for you.
Note: this book also available on Safari Books Online.
About the Author
Ryan Cooper is an agile developer and coach. He is the founder of Ryan Cooper Consulting, Inc, and the co-founder of the Agile User Group in his hometown of Halifax, Canada. He blogs at www.onagile.com.