Recommended to me by: Sam Livingston-Gray
I read this book in little bits over the winter. Since I’m now in two technical book groups for other books, I think it’s time to admit that I got as far as I’m going to get for now. It was surprisingly readable and relevant for a book on how to organize groups to write software.
I left my first full time software job after 5 years because I just couldn’t stomach the thought of another round of waterfall development: first requirements, then design specification, then functional specification, then code. With bonus Gantt charts. More recently, I’ve worked for three companies doing some version of Agile, and while none of them have strictly adhered to all the practices, they were all a big improvement over waterfall development.
In 2001, a group of experienced software developers got together and hammered out:
Manifesto for Agile Software Development
- Individuals and interactions over process and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The idea is to develop software in small bite-size changes so that it can adapt to continuously changing requirements, and to value teamwork among developers and with designers and customers rather than working in isolation. “People are the most important factor in software development success.” Agile includes automated tests written along with code, deploying software quickly, and working in pairs or larger groups.
The book includes how to start fresh with Agile when creating a new team, or adopting it in a possibly reluctant team or management. Management tends to resist the fluidity of agile teams because timelines and outcomes develop over time rather than being up front commitments (that are rarely met). At its heart Agile is about managing change, and the book includes thorough advice and analysis about the change to using Agile.
James Shore emphasizes having the whole team, which includes developers, designers, customer experts, and product managers, in the same room where they can easily ask each other questions and collaborate, as well as overhear details that might be relevant to what they’re working on. A remote team shares a Slack channel and uses video meetings to achieve some of the same benefits. “[Agile teams] are optimistic, enthusiastic, and genuinely enjoy working together. There’s a spirit of excellence, but it’s not overly serious.”
“Always ask, always help.” The team as a whole moves faster if everyone prioritizes helping each other get unstuck. It doesn’t help anyone for a developer to spend two days trying to figure out a problem that someone else could help solve in an hour of pairing on it together.
Psychological safety means team members are safe to disagree, safe to not know (yet), safe to ask for help. Enable all voices, be open about mistakes, be curious, learn how to give and receive feedback. Say “yes, and…” to people’s ideas.
There is a lot about estimates and breaking tasks into “right-size” pieces and the velocity of the team – how many stories get done in a given period. My current group chews through a lot of work in a two-week period, but we don’t estimate tasks ahead of time. Some tasks take an hour, and some take weeks because there are unexpected complications.
The book advocates for white boards and sticky notes, which don’t work as well in a remote team. Planning is done by moving sticky notes around.
This book is recommended for anyone writing software, whether their team is officially Agile or not. There are a lot of great practices, and it helps to know what some of the options are even if a team is only using some of them.
Leave a Reply