Thursday, July 7, 2011

Review: Individuals and Interactions an agile guide

In Individuals and Interactions an agile guide, Ken Howard and Barry Rogers give us a set of tools for managing individuals on agile projects. They acknowledge that "There have been countless books on the subject of human behavior and communication. Psychologists, sociologists, organizational behavior experts, and others have conducted studies, published journal articles, taught courses, and granted degrees in this subject area." Since the philosophical science has been covered in detail by many many others, this book focuses on specific tools you can use for individuals and interactions on agile software projects. It jumps right into actionable techniques without much exposition. It assumes you are fully in agreement with running projects utilizing agile project management practices. Fair warning: The book might feel quite one sided for some if you come from a heavy command and control background or don't agree with agile principals. You might get a bit frustrated.

In the first few pages the book discusses what a group of people behaving as a team looks like. How a "team" of individuals working alone isn't as good as a team working together.  How productivity increases once a team stops focusing on process, but on results. Next the book brings up the concept of the DISC behavior model. I really liked the quick explanation of DISC as "a behavioral fingerprint." For those unfamiliar with DISC it segments people into 4 categories: D—Dominator, I—Influencer, S—Supporter, and C—Critical Thinker. I generally hate to label people, but I find myself using DISC often when thinking about how to work with people professionally and personally. Its a useful tool.

After a detailed section on team dynamics the book moves to communication. Agile projects can succeed or fail based on the quality of communication of the team. I found a section about body language particularly interesting. Surprisingly, body language has never been included in any manager training I have been through. On Agile teams a project manager pays a lot of attention to the nuances of how people talk and work together. Body language tells a lot about the conversation. Its big tool to fail to have it in your tool box. I'm not a particularly empathetic person, but I notice a lot when it comes to my teams. The reason is that I read a book about body language when I first got in the workplace and feel that I have been at an advantage ever since. Finally, the book moves on to the highest form of speech: collaborative interaction. Its probably a blog post in itself so I suggest you learn more about it from reading the book.

Next in the book is a section about people's motivators. It goes into more detail than the simple adage: Some people follow a craft for the money, others make money to follow a craft. The book ends with a focus on people's strengths. My experience is that many people look to change and "improve" individuals vs directing them toward what they are good at and will enjoy.

The final part of the book is filled with a few workshops that are useful for those who want to facilitate a group into cohesion. I worry that they might be hard to get through in a very staunch environment. Of course, I haven't seen too many staunch organizations successfully do Agile anyway. Your milage my vary.

The final part of the book has a personal DISC test you can take. This is useful because, in my 5 minutes of research on Google, I couldn't find a free one on the web. Again your mileage my vary.

Overall I think this a great book for those who are doing agile, but only have a perfunctory understanding the mechanical processes. This book will round out your understanding and have to understand the why of it. If you have been successfully using agile principals and practices for a number of years, you are likely to find something useful in this book too.

Its short, pick it up. You won't be disappointed.


Tuesday, July 5, 2011

Review: Leading Lean Software Development


I am reviewing books I have read in the past for an upcoming coaching gig. I realized I hadn't posted this review on my blog yet! This is from over a year ago, but its still relevant as I work with more and more customers who are now becoming interested in Lean software development. This is still one of the better "agile" books I have read in the past couple of years. Here is my review:

In Leading Lean Software Development, Mary and Tom Poppendieck present a handbook for how to run a software development group, top to bottom. I intended for this to be a simple review of concepts known to me for years, but the book offered much more. The book’s jacket describes it better than I can: They “show software leaders and team members exactly how to drive high-value change throughout a software organization—and make it stick.”  If you are completely new to agile and lean you the book might move a little fast for you.  If this is the case, I suggest you spend some quick time getting agile and lean 101 elsewhere first.
If you walk away with one concept after reading this book it should be to believe that success comes from people. The best companies focus on developing problem solving skills and local decision making. These companies favor adaptability over efficiency.  These companies make money to survive rather than simply surviving to make money.
The book starts out by defining the concept of frames, “the unspoken mental constructs that shape our perspectives and control our behavior in ways we rarely notice.”  A useful way to look at software development. I was happy to see their description of Agile as evolutionary rather than revolutionary. This is why when you explain the set of Agile practices to those with extensive experience they usually nod their heads and say they are already doing them. I have been telling people that Agile is a collection of best practices that good software shops have been using for years. Now I have a reference to support this.
Software craftsmen should read chapter 2 about technical excellence. The chapter goes through each engineering practices, explains it such that a non-practitioner can understand and gives examples. After they are done they should make their manager’s read it, then their managers.
Conclusion
I wish this book had been written 5 years ago. It would have saved me considerable effort and time trying to define what a well run software organization looks like. Your mileage my vary, but I will say that I intend to keep this on my bookshelf right next to Managing The Professional Service Firm.