Summary
My copy of The Art of Agile Development (AoAD) was the second edition, released in 2021. I never read the first edition from 2007. Still, I understand it was an early influential Agile book that treated the subject less dogmatically and in a less process-oriented way than Scrum literature, which has gained much attention in the past 15 years - both positively and negatively. The second edition is similar. It is a combination of a cookbook and a handbook, emphasizing the advantages of this approach to software development.
The book’s structure follows the Agile Fluency model developed by Shore and Larsen. It begins with a section on implementing Agile in organizations that lack the necessary buy-in and support. The Agile Fluency competencies are Focusing (producing value), Delivering (efficiently delivering value), and Optimizing (increasing business value). Each fluency section contains three to six chapters on related topics. These chapters are further divided into short subchapters dedicated to individual practices related to the topics. The practices are primarily, but not exclusively, based on XP ideas. The authors usually discuss the sources that influenced the practices described in the book.
The subchapters on practices follow a standardized structure and are very practical. The authors link individual practices to related ones in the “Ally” boxes, hint at the practice’s target audience, and provide FAQs, checklists, alternatives, and further reading. The book is presented as a collection of various ideas and techniques that can be followed, modified, or ignored but do not form a strongly defined, prescribed methodology. The authors stress that the practices are synergistic, though. They recommend following them entirely at first and only modify or discard after some time when the team is familiar with them, and any shortcomings can no longer be attributed to the chaos of learning new things.
Thoughts
Compared to books on Scrum or Kanban, AoAD does not present a specific method to be followed but rather a loose collection of practices that work together synergistically. I appreciate this approach because it is more flexible in real-world situations. I am convinced that rigorous methods followed to the letter work well only when fully embraced. Since that rarely happens, the result is often dysfunctional (time-wasting ceremonies, absent product owners, Kanban without limiting the work-in-progress, etc.). The practices in AoAD are very pragmatic, low-tech, and low-process, true to the Agile Manifesto.
I appreciate that the authors mostly avoid preaching the usual Agile clichés about magical, universal improvements that are supposed to happen after an Agile method is adopted. Quite the opposite; the authors warn that adoption takes time and effort, and for a short period, the actual performance will be lower. Only as the team learns the new skills does it perform better.
The book can be a helpful reference for various situations. Initially, I was uncertain about the Agile Fluency model, but after further consideration, I concluded it provides a valuable framework for the team’s major competencies. A team can begin by evaluating which competencies need improvement (most teams will likely want to enhance their Focusing or Delivering abilities), then choose a relevant topic and try the suggested practices. Alternatively, the book can be consulted when a team is facing an issue and unsure how to resolve it: find the topic closest to the problem and review its practices or follow the Ally links to related topics.
The limitation of AoAD is that it heavily focuses on co-located teams. Many practices are designed for a team working together in the same physical space, such as using index cards and post-its. The book acknowledges this and attempts to adapt the practices for online tools, but these sections are often vague and shallow. I don’t think it works; even when the book suggests that all team members should use a tablet to interact with an online board service, I can’t imagine this being effective. The book would have been better off if it had omitted these attempts entirely. Distributed teams should look for books that address their needs more precisely.
Lastly, I occasionally felt that the depth and detail of individual chapters were not balanced. Some topics are described in great detail and contain much helpful information. Others read like the authors needed some content to be filled into the common structure, so they wrote one or two paragraphs of generic, bland content. These parts sometimes even regress to fluffing the text with generic Agile preaching about happier teams, more business value, etc. In several (few) cases, the authors go into menial details of a particular practice, providing a step-by-step example of a process that is not that complicated to deserve such detailed treatment. A little more strict editing could have removed these low-value items, resulting in a shorter, more readable book.
Interesting Bits
This (highly subjective) section contains the bits that I found interesting, surprising, original, or significantly different from similar works.
I like the suggestion to start adopting methods in a rigid, by-the-book fashion. I agree with the reasoning that most Agile techniques are counterintuitive and synergistic. Discarding ideas before trying them or without long enough learning time is a waste of opportunity. I am convinced that many teams do this. This is very hard to do without a dedicated coach because the peer pressure of skeptics often leads to abandoning experiments too early.
I enjoyed the parts that dealt with investments into agility and change. I appreciate the admission that Agile transformation needs time and dedicated effort. I find the systematic writing on organizational pathologies and the methods to overcome them helpful - especially the parts that predict the common “setbacks” that, without proper handling, could lead to abandoning progress because the new methods “do not work.”
There is a high focus on low-tech, highly efficient, and collaborative techniques throughout the book: many use simple cards and post-its on a whiteboard. All participants interact with the board: rearranging, writing new cards and discarding them. I find these intriguing, especially in contrast to trying to do the same in a behemoth like Jira, usually through the hands of a facilitator that furiously types words on a shared screen while the participants awkwardly wait until all words are typed. I do not know how to achieve the efficiency of a single whiteboard in a remote setting.
I liked seeking consent instead of consensus: people can be in favor, against, or abstain. The team proceeds if at least someone is in favor and nobody is against it. People who are against it must explain why. If they are not convinced, the proposal is not adapted. This gives power to individuals to pick their battles.
I really liked the suggestion that “stories are reminders to have a conversation”. Again, this is a contrast against the hideous, detailed Jira cards, with sections and checklists and acceptance criteria. I like how this follows the “pure” Agile Manifesto ideas. Stories that need all this likely should be broken down.
I also really liked the system of techniques that work with sizing the stories “just right.” This eliminates a lot of process (Fibonacci scale planning pokers of the world) and plays really well with team capacity, evening out small deviations in estimation if the team behaves consistently. I appreciate that the authors stress that teams have limited agency in setting their capacity. In the long term, the team will learn and be able to do more, but any efforts to pressure the team into achieving more are doomed.
I really like the concept of “slack”: the built-in unstructured time in a team’s iteration. The slack is a time set aside to iron out wrinkles in an iteration and allows teams to deliver the planned work despite surprises and changes. Otherwise, the slack should be used to improve the ability to deliver: pay the technical debt, improve automation, learn new techniques, etc. I find the notion of a capacity buffer that should be invested in the team’s long-term productivity useful.
I liked guiding impediment removal by identifying whether the source of the impediment is in the team’s control, the team’s sphere of influence, or “Soup .”The “Soup” is everything outside the influence of the team. Impediments coming from the “Soup” need to be addressed by changing the team response.
I have never worked in a team that would practice the more extreme collaboration techniques like swarming on stories (the team breaks stories into tasks, then the whole team simultaneously works on them, instead of everybody working on a separate story) and pair or even mob programming. I want to try that someday. It is probably harder in distributed teams, especially ones spread across time zones.
Standup is not a status meeting; it is a coordination meeting. Continuous Integration is a practice, not a tool.
Top comments (0)