Agile Software Development: The Cooperative Game
Chris Guzikowski, Editor; Stephen Nakib, Marketing Manager
Should you read by Alistair Cockburn's Agile Software Development, Second Edition?
Absolutely. The first edition of Agile Software Development proved to be fundamental reading for anyone serious about understanding what agility is really all about. This clearly holds true for the second edition, which adds new insights from one of the top thought leaders in the agile community. The true message of the book is that software development is a "cooperative game," and if we're to succeed at software development, then we need to find ways to work together more effectively than we currently do. Cockburn shares his understanding of how people communicate and collaborate throughout the book, comparing and contrasting various strategies in such a way that you begin to reflect upon, and question, some of your underlying assumptions as to how software development really works.
The book brings together several critical streams of thought within the agile community. Discussions of how agile and lean fit together, how agile and self adaption works, how theory of constraints fit in, and how a few concepts from martial arts can help to bring everything together. The book also provides an update on Cockburn's work with the Crystal Methodology family, making it abundantly clear that one process size does not fit all.
Agile Software Development, Second Edition is a "must read" for anyone who is trying to understand the underlying philosophical underpinnings of agile software development, what works in a given situation, and more importantly, why it works. This book is a "you better read it" if you are new to agile ideas and want something with some depth. Finally, this book is a "probably bought it the first day it came out" for anyone who read the first edition-the second edition is that good.
E. M. Bennatan
If developers weren't optimists, we'd never write a line of code. "Can we build it?" "Yes we can!" When projects go astray, the tune hardly changes: "Can we fix it? Yes we can!" But, you know what? Sometimes, you can't.
Catastrophe Disentanglement, E. M. Bennatan, takes a hard look at a reality most of us have confronted: projects too dire to rescue by working harder, or working smarter, or thinking in new ways, or applying better tools, or any of the straws drowning developers grasp at. JUST STOP!
That's the first lesson of the book, and it's the hardest. When you find yourself at the bottom of a hole, STOP DIGGING! Catastrophe Disentanglement gives you objective criteria for recognizing when a project is standing in its own grave, and gives you a concrete checklist for analyzing what went wrong and determining how to either yank the project back on track, reinvent it so it's doable, or jettison it entirely. It's all backed up with a solid understanding of how people react when things are going wrong, and shows you how to move the discussion out of the realm of finger-pointing and guilt.
Just be prepared for some raised eyebrows when you leave it on your desk.
Practices of an Agile Developer
Venkat Subramaniam and Andy Hunt
Practices of an Agile Developer Venkat Subramaniam and Andy Hunt is a very, very, very special book. Why? It is one of those rare books that gives operationally useful success criteria for hitherto fuzzy coding goals. There are a great many books that are theoretically exciting, but darn few that give you a gut-level test for "how it feels" when the theory is working and still fewer that try to help you "keep your balance" when you become blindly optimistic because of the idea's success, or bottom of the barrel depressed when the idea bombs.
Each of the book's practices has such codicils. For example, take the universally known idea "Keep it Simple." Partially excerpting the book, it feels right "when there isn't a line you could remove and still deliver all features." A sample keep your balance guide: "Terse is not the same as simple; it's just uncommunicative." More than 40 such practices are examined in detail, including lively discussions on how they affect the team, customers, system design, coding, and debugging. The heck with Agility, these nonideological guides work in any development environment.
Keep your balance. Study this book.
Software Estimation: Demystifying the Black Art
Steve McConnell is no stranger to the Jolts, having won the Jolt award several years ago for Rapid Development: Taming Wild Software Schedules, and the productivity award for his post-dot com back-to-reality book, After the Gold Rush: Creating a True Profession of Software Engineering. Not one to shy away from the visceral issues challenging the leaders of software development, Software Estimation tackles this amorphous subject with an engineer's analysis and pulls the reader into a world of planning for the vagaries and uncertainties of more accurately modeling software development costs. The Jolt judges had quite a passionate discussion around this book because of the nerves that it struck with so many of us. Having been stung in the past by inaccurately estimating project duration and cost (I tend to be overly optimistic and sometimes fail to account for wetware constraints like sickness or sleep), I approached the book with skeptical enthusiasm. Although it failed to enrapture myself or fellow judges, it did spark lively conversations of our own estimation foibles and how the concepts in the book may deter future derailments.