Email the Author

About the Book

Feedback from a reader: 

Thank you very much for the opportunity to read your book. You have no idea how much It made me feel better. I'm serious. I used to have a bad feeling of never getting those agile practices to work on my projects. Now I see I was doing it wrong. Those practices could never work for the projects I had been working on. They simply don't fit the context of my projects.

Indeed, before trying to make everything Agile, I had a good experience in a project. After reading your book, I realize that one of the factors that made that project a success was having a reasonable design phase in the beginning of each iteration. Another one was to have a good mix of personalities in the team. Another one was having a committed team -- this is hard to achieve in projects.

This book is a collection of observations over the past 10 years or so, looking at agility from the perspective of someone that doesn't depend on selling it to make a living.

There are plenty of models for software development out there, some may even be relevant to your culture, your product, and your industry space. It is highly unlikely that any of these will be a perfect fit right out of the box, and you should never let anyone tell you it is OK to turn off your brain. Learn about as many as possible, use the bits that work, and continuously reflect and improve upon the past.

There are many good things to come out of the agile movement. It's finally OK to talk about how we develop software, something that was taboo when 'process improvement' was a catch phrase. There are a number of good ideas that have been borrowed from other domains and applied to software development, and many good practices have been recast in terminology that makes it easier for technologists to buy into the ideas.

There are also some glaring challenges.

The blatant demonizing of pre-agile approaches would suggest that there were no successful software projects before the manifesto came out, whereas in my experience there hasn't been significant change in overall project outcomes (at least not nearly as significant as agile apologists would have you believe with their biased data).

There are things that remain unsaid and are taken for granted in many of the agile pitches that need to be explicitly stated, such as effective configuration management and mature team interaction. Without these, any practice is in danger of failing.

Many of the practices that are touted as new inventions are simply reincarnations of good things that people have done for decades (which doesn't fit well with that demonizing mentioned above).

On balance, though, if we think of agility as an adjective rather than a verb, we'll be better off.

This book talks about how to be agile, rather than how to do agile.

About the Author

Jim Brosseau

Jim Brosseau has been in the software industry since 1980, in a range of roles from tester and developer to manager and director. He has developed software and managed teams in embedded avionics, ATC systems, and commercial software packages.

A common thread through his experience has been a search for more effective collaboration across teams. Jim is principal of the Clarrus Consulting Group, and since 1998 he has consulted with organizations worldwide to improve their approaches for successfully delivering software. He has published numerous technical articles, and has presented at major conferences and local professional associations.

Much of his time these days is spent with teams outside the software industry, as he has found that at a certain level, projects are projects, and agility is important for all of them, in all disciplines, to varying degrees.

Jim lives with his wife and two children in Vancouver.