14
May
2009

I have a confession to make. I don't know what "Agile Programming" is. At least, I didn't before reading "Becoming Agile ... in an imperfect world" by Greg Smith and Ahmed Sidky (In the interest of full disclosure, I was fortunate enough to receive an advance copy from the publisher).

I'd heard the term before, but I didn't really know what it meant to be an Agile programmer. What comprises Agile? Is it an abstract concept or are there explicit steps to take in order to "get there". How do you know when you're "there"? More importantly, is it worth investing the time to become Agile?

I got as far as page 4 before two of my questions were already addressed (What components comprise Agile development, and how do I know that I've achieved Agile development?). I took that to be a good sign. A sign that the authors know who their audience is, and will do their best to deliver the answers that their readers are looking for.

The book is also presented in a fair and balanced manner. The initial definition of Agile development is quickly followed up by a summary of what Agile development is not. This helped to clarify the initial definition, and helps to ensure that from the onset, the reader hasn't misunderstood or misinterpreted the ideas that the authors are trying to convey.

There is a set of 12 principles representing the foundations of Agile development (what is referred to as the "Agile Manifesto"). Some sound good in theory, and some sound far fetched. It is, as the authors state, a paradigm shift from a plan-driven mentality.

The authors engage the reader by asking questions such as, "Are you ready for Agile" (although they immediately answer their own question with a "Yes, you are ready"). As the book progresses, the original 12 principles are re-visited in greater detail. The pace at which new concepts are introduced is very comfortable. At no point did I feel as if I wasn't ready/prepared for the ideas being presented. At the same time, I didn't feel as if any concepts lingered too long or dragged on unnecessarily.

The book stays consistently objective. There are acknowledgements that there are risks behind adapting Agile. Not only in the development process itself, but also in the migration to Agile (e.g. buy-in from stakeholders and management). The book was not composed on a rose-colored word processor. If you choose to pursue an Agile methodology, you will be aware of the challenges that you'll face. But, you'll also be better prepared to face them.

This is much more than just a book about Agile. This is a roadmap. A very detailed roadmap that takes you from the initial "is Agile right for me?" stage through completion and delivery of your pilot project and beyond.

Did the book sell me on Agile? Not necessarily. I don't think it's a concept that can be sold without first putting it into practice. There are still some aspects of it that I'm not quite comfortable with (remember, paradigm shift), but my curiosity is definitely piqued. There's more about it that sounds appealing to me than dubious. I'm curious enough that I'd like to take Agile for a test drive and see how it handles. It may be unfamiliar territory, and I may not like the destination once I get there, but with a guide like "Becoming Agile ...", at least I know I won't get lost along the way.

Comments (1) | 1435 Views

Comments

Add Comment | Subscribe to Comments

  1. Jason Fisher's Gravatar

    # Posted Jason Fisher on 8/10/09 10:34 AM

    Charlie,

    About 12 months ago, I had the opportunity to take a 3-day Scrum course. Prior to that I had only a passing familiarity with what Agile was "supposed" to be, like one might get from reading a book. Not only was the instructor of this course solid, but we did a lot of group activities to work through *how* a team actually conducts an Agile project. At the end, we were all ScrumMaster certified, but more importantly, I went from being very skeptical to being convinced that the process is completely feasible and is superior to the plan-driven approaches I'd been using all these many years of software development. The single greatest challenge in bringing it into any organization, I think, is finding ways to actually carve out blocks of time for sprint teams to focus on the project. If you can't pull that off, the concepts are much harder to put into play.

    In short, when you say "I don't think it's a concept that can be sold without first putting it into practice.", I would say that you are entirely correct. The paradigm shift is just too great to guess at concepts and get it right, or at least that's my take on it.

Add Comment