If you are considering moving to agile, read this book first. It will provide you with a well tested and reasoned approach which will minimize the risk and prepare you for the changes that are required. However, if you are already agile and looking for the technical details of how to implement TDD or other agile practices you will want to look elsewhere.
I read this book because I run a one man consultancy, where agility is a job requirement not an option. However, in the next 6-12 months I plan on hiring two additional staff members, including a developer. How do I maintain that agility as my team grows? Can we be agile if we don’t work in the same location, or even state? Will we need to adopt an entirely new process to become agile? What do I need to document, organize, or create to support a more formal agile process?
This book’s 23 chapters are grouped into 8 sections, each covering a different part of the agile process (from what agile is, to how to expand agile companywide). In addition to the theory and principals you would expect, each chapter also contains a case study (Acme Media). The case study demonstrates the challenges and solutions encountered when translating theory into practice.
Section I (chapters 1-2) explains what agile is, what it can do for you and your company, the principals underlying it, and introduces the reader to the Acme Media case study.
This section clearly sets the agenda for the rest of the book – this book covers the agile process and how to incorporate the agile principals into your work, but does not cover any specific tool or agile practice (e.g. user stories, test-driven development (TDD)) – in fact the authors state “it’s anti-agile to say that there is a defined set of practices and that no new practices can be created.” Therefore if you are looking for specifics on scrum or TDD you will either need an agile coach or a different book.
As a developer, I sometimes want to try a new technology or framework simply because it’s new. However, as a business owner, that isn’t necessarily the best idea. I was pleased to see that the authors made clear the bottom line business benefits of becoming agile, while also acknowledging the potential pitfalls (e.g. decreased performance in the short term).
Section II (chapters 3-9) covers how to decide if you are ready for agile, how to obtain executive support, how to assemble an agile team, what it takes to lead that team, adding agility to your current process, and picking your first agile project.
Despite currently being a one man show, I think I got more from this section than any other. I had never considered the question of whether I, or the company were ready for agile, either as a developer (team member) or business owner (team leader, and company executive). After all, as a one man team I must be – right?), but chapter three’s list of potential roadblocks to becoming agile (e.g. distributed teams, team with specialized skill set), resonated as both current and future pain points.
The agile-readiness assessment from chapter 4 will make some great interview questions when hiring a new developer later this year. As well as when working with third party developers (university IT staff, DBA’s and system administrators) who may not be familiar with agile development.
Many agile development books espouse a single group of practices that must be used together as a monolith to be considered agile. The authors in chapter 8 propose a different methodology, one based on using the agile tools and processes that fit you and your constraints, and add value. They argue that one size does not fit all, and that all teams should be agile in their own way. Their process began by analyzing current practices, keeping what worked and iteratively improving what didn’t. Therefore, as discussed in the case study you could use feature cards, without pair programming or TDD, and still improve agility.
Section III (chapters 10-11) covers project kickoff, picking a team to determine project feasibility? Determining and examining project requirements, making a go no go decision, and picking your development team.
The worksheets and checklists from chapter 10 (e.g. feasibility team checklist, feasibility discussion guide) were a big help in understanding that a more formal agile process didn’t require the production of volumes of documentation. That the process itself and its regulatory/compliance requirements could determine the amount of documentation and detail required.
I have already adopted the tradeoff matrix, and project worksheet from chapter 11 both for my internal projects, and with my clients It is a great way to help them prioritize their true needs, and bring new team members up to speed on a project. My one minor annoyance with the forms and screenshots reproduced throughout the book is that their small size makes them difficult to read.
Section IV (chapters 12-14) covers creating and generating a product backlog, using feature cards, how to group, sequence and prioritize a products features, estimating the work needed to complete a feature, and how to using story points to estimate the work needed to complete a feature.
Feature cards are another tool I have begun utilizing with my clients, because they are something that my clients do automatically. Almost every feature request starts with I once had a student where I needed to… It also lowers the barrier to entry (with non technical users and clients). It helps me build a rapport with them and demonstrate that I really do understand what they do. It gets me out from behind the computer interacting with them face to face.
I never really understood story points until reading this book. It seemed very arbitrary, and left me wondering if my 5 were the same as someone else’s. After reading chapter 14 I know it is arbitrary, but it is designed not as an absolute measure but a relative means of comparison (The authors use the metaphor of a car and impala is bigger than an escort and so should have more points), and that like anything else your estimates will improve with experience, time and completed iterations . Likewise, estimates should be done by the whole team. This idea has helped to align priorities and expectations between myself and my clients.
Section V (chapters 15-16) explains how to create a schedule, assigning features to iterations, defining done, modeling, developing tasks, capacity planning and displaying project status.
One of the questions I wanted to answer by reading this book was, how long should my iterations be, considering I travel an average of a week a month (doing sales and training), and that I will still be the lead developer and designer (how do I maximize both my time and that of the new developer). I think keeping iterations shorter (2 weeks) will allow me to make the best use of time (at least initially).
Displaying project status to others outside the company was not something I did very well, after reading the author’s suggestions I have implemented and electronic update system based on the project matrix (chapter 17) to keep everyone updated. Clients have said they really liked seeing this since it gave them a sense of “moving forward."
Section VI (chapters 17-19) covers building the project, iteration 0, modeling the architecture, gathering licenses, creating a testing plan, coding with agile principals and testing
I was pleasantly surprised to see the idea of cheating the timeline by using any free time in the setup phase (iteration 0) to get a head start on the task list, as this was something that had saved me on more than one occasion when the unexpected came up (including surgery). I also appreciated the idea of gathering/generating a sample data set to use during programming and testing in iteration 0 – before it is needed.
Chapter 18 emphasized that in an agile process the key metric is working code, not the number of lines or blocks or an estimate of how much is left. It also showed how agile principals can be used to improve the development cycle, client relationship, workflow and product.
Chapter 19 covered testing I especially appreciated that by using agile methods I could get my end users and testers reviewing code earlier. This has the dual benefits of creating ownership as they feel they have contributed to the end product, but also makes fixing the bug easier, since less time has passed since coding and identifying the bug.
Section VII covers adapting to changes, deployment, and the retrospective.
Chapter 20 demonstrated how to handle the inevitable changes that occur, both mid iteration and at the end of and iteration. In addition it explains how our first iteration is a source of data to help refine our estimates and plan our next iteration (e.g. story points completed).
Chapter 21 took us through the deployment process, from how to make the decision to deploy (waiting until bug free vs. as it is now – before the market window changes etc.). I especially liked the idea of everyone involved being in the same room. As someone who has had to communicate with people spread all over campus, or in another state or time zone this would go a long way to making deployments easier and less stressful. I have also learned the hard way the value of a both a good plan B and back out plan.
In chapter 22 the authors do a good job of how to plan and conduct a retrospective, then use this data to improve your agile processes and practices, and thereby keeping it from becoming nothing but a bitch session.
Section VIII (chapter 23) explains how to spread agile either throughout your company, or by incorporating more agile practices into your process.
I really liked the authors’ suggestion that as you become more comfortable with your new agile process you incorporate new agile practices, in an iterative approach to constant improvement, or as a former professor used to say if the shoe fits put it on.
In addition to the case study the authors have done a good job providing alternatives solutions especially where scale plays a role (e.g. small teams and companies usually operate with fewer levels of management than do big companies – and this can have a profound effect on what agile looks like in a small vs.large company). The forms, worksheets and spreadsheets were a big help both on a day to day basis and in the planning process.
Besides those mentioned above I did identify a few additional weaknesses. The case study did much to demonstrate what happens when theory becomes practice. However, I did find it lacking in follow up. Did Acme become a fully agile shop? What other practices had they adopted a year later and why? Did the business see the expected ROI? Besides the change in productivity what if any were the negative effects? How did they address the issues identified in the retrospective? How effective were these measures. This may be the natural result of the author working as agile coaches. They may simply not have access to this information. Likewise it is only natural for a coach or trainer to begin removing themselves somewhat from the process at this point.
I also would have liked to see an electronic download (word and excel) of all the worksheets and forms from the book.
This is not the kind of book you read in one sitting, rather to get the most from it you will need to assess you readiness, develop a plan, gather support and as the Nike commercial says “just do it.”
This book not only helped me answer the questions I started with, but forced me to ask and answer many more along the way. I now have a more agile practice and would highly recommend this book to anyone looking for the same.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)