Agile is not about specific rules. It is about attitude – willingness to change, adapt, and continuously improve and expand. There is no clean-cut set of rules that make one an aglie developer- it is a craft and a way of thinking that must be practiced and honed. That is not to say there are not resources out there to put you on the right path- Headspring offers an agile boot camp that shows what steps you can take to put the agile attitude into practice. But there is no easy list of things that one can do to be an agile developer- and the push to find this list of things can create what some call “Agile Theater.” This is where teams use the “right” names for meetings, and call it agile development, but don’t really change their old ways of thinking. This can actually be quite detrimental to a software development team, as the added semantics of agile just add more work without actually changing the way things are done on a daily basis.

The name agile implies something other than just raw speed- the name also conjures up the idea of being able to adapt quickly to new situations. This is a very practical name- agile developers must be ready to develop quickly (the idea of releasing early and often is a core idea of agile), but they must also be ready to adapt to changes in customer needs and other factors- customer needs change on a constant basis, and at the end the needs and the product need to match up.

Just as the customer’s needs change constantly, so do an agile team’s needs- as people come and go onto a team, the skill set and standard work flow may change bit by bit. What works for one team at one time is never guaranteed to work for the same team at a different time, or a different team altogether. This is why agile development cannot be a list of rules- the way teams implement the core ideas of agile must fit the team itself as its needs change.

This may make agile development seem like a daunting task to implement, but it is a very valid investment towards zero-surprises development. Agile teams are responsive to client’s needs, and release working software early and improve on it often, which makes for much happier clients, and a project with little wasted effort, because the feedback loop is shorter.

Overall, agile is far from a list of rules that teams can follow to become agile developers. Rather, it is a list of ideas that developers should strive towards, using any tactics that they feel fits them best as a team. This makes agile teams responsive not only to their customer’s needs, but to their team’s needs as well, creating a stable environment for both customers and developers.

Want to learn more about agile? Headspring offers a fantastic Agile Boot Camp that you can attend to get you on the right path.

This book is thin, but a very dense read; it covers a true variety of subjects, many of which that are crucial for consultants – when and how to say no and yes professionally, test driven development, project management, teamwork, and estimation, to name several. But it is because of this wealth of topics that Martin is able to show readers that professionalism and the path to a long and respected career involves dedication, practice, and time.

This is a book I would recommend not only to new software professionals, but experienced ones as well- because Martin also delves into the more detailed issues of professionalism and career development, even established professionals might learn a thing or two. There is also a section on mentoring that should prove useful to current professionals- because sharing knowledge is just as, if not more, important than obtaining it.

Overall, this book provides a solid foundation for any new software development career by giving the reader contextual experience as well as well-thought-out, time-tested rules to govern the start of a new (or existing) career as a software developer. The Clean Coder pulls all of these important topics into a central text, lending a much-needed resource to the software development community.