There is an “I” in team

Dennis Britton suggested Christopher M. Avery’s “Teamwork Is An Individual Skill” to me, and to show what great team member he is, loaned it to me while he was in the middle of it because he really wanted me to read it.

“Teamwork … ” is an amazing book, and is tied in my mind for the best book I have read this year with “The Goal”, though they are both very different books.  “Teamwork …” is about exactly what it sounds like, how excellent teams don’t form randomly but through active commitment of all individuals on the team.  When people say things like, “I just got on a bad team,” that statement is a reflection of speakers lack of understanding of how excellent teams work.

The book is chock full of gems – examples, exercises, explanations and practical applications of the theories expounded upon in the book.  I have to admit that one annoying thing about the book is Avery’s reference to his trademark “TeamWisdom”.  TeamWisdom is never fully defined in a single place but rather seems to  include whatever Avery deems as productive team behavior,  almost whimsically.

Oddly enough though, when I was reading this book, I was constantly reminded of the behavior of one of my colleagues, Mark Chang, who is a paragon of teamwork as an individual skill.  In particular, Avery talks about the importance of “calling it” – that being the act of informing a team member whenever they acting even in the slightest way outside of the team’s interest or goals.  Avery brings up this skill many times in many different ways.

Another example of these gems I speak of comes almost as throwaway near the end of the book. Avery instructs the readers to write down all their expectations about how people should behave in their presence, and then to prioritize those expectations.  Once done, the reader is encouraged to identify how and when to make commitments with team members in order to realize those expectations.

There are so many good examples and exercises  in this book that this blog entry would be too long to read if I put them all down. I’ll be returning this to Dennis on Thursday and buying my own copy today.

Agile Management For Software Engineering

After reading “The Goal,” I was thrilled to find that David J. Anderson had written a book discussing the application of TOC to Agile.  Actually, the book’s title is a misnomer since Anderson is less of an advocate of Agile than he is of XP and Feature Driven Development.

I have to admit that while I found Anderson’s presentation very dry, there is a wealth of valuable information packed into this volume.  Honestly, I skipped much of the latter third of this book as much of it compared the metrics of FDD to Scrum, RAD, and and other methods of running projects.  I think this information will be good for me to have, particularly when the day comes that I have time to help Tom turn the Excel spreadsheet about TOC that he presented at a Tacit Talk about 4 months ago into predictive tool.

Anderson’s discussion of development as a capacity constrained resource (CCR) is interesting.  Since delevopers cannot work 24 hours a day, the 8 hour work day is a constraint.  Anderson suggests that the best ways to protect and exploit this constraint are to give them

• A queue of work waiting
• A communication structure in which they have a minimum of lines of communication
• A quiet environment
• The best development tools available
• support staff to keep them from reporting status multiple times to multiple people
• Adequate training in the tools they are using
• a team of colleagues to help them resolve difficulties
• High-quality requirements.

I can’t agree more, particularly with the bit about requirements.

It was helpful to me to read Anderson’s work simply to know that there are other people out there who are thinking like me.  Furthermore, Anderson suggests something that I’ve been thinking, that any product that comes out of the system that doesn’t meet quality standards should not count as throughput.  In fact, since it probably causes more cycles to be spent now that it is in the hands of the customers, it negatively impacts throughput.

In chapter 31, entitled ‘Devil’s Advocacy’ Anderson takes on two ideas: 1) That generalists are desirable over specialists, and 2) that adding more people makes a project later.  In the process of making point 1, Anderson discusses the proposition of having business analysts writing acceptance tests.  What Anderson says is that in a well-controlled environment, specialists should outperform generalists.  Makes sense.  What Anderson seems to miss here though is that in a system of generalists, resources can be moved to address bottlenecks.  I think Anderson’s proposal assumes a system that has already been tweaked because someone has identified its bottlenecks and CCRs.  In making point 2, Anderson points to the J-Curve, which shows that new people introducted into a bottleck or CCR will at first decrease capacity of the resource but over time, that introduction will result in increased capacity.  His point, and I agree, is that it is not enough to simply add resources.  One must add resources in the right place, to the bottleneck or CCR.  In order to do that, one must, again, identify where those are.

Many of the people I’ve discussed Anderson with have something negative to say about him personally, though most of them don’t actually know him.  I have heard these complaints and agree that some of his actions sound like they are unproductive.  I’ve made comments about how unskillful behavior can negatively impact Throughput in my blog. I have to say however that there is never a good reason to throw the baby out with the bathwater.  Anderson is a brilliant thinker and this book is a valuable contribution to the Lean, TOC, Agile, XP, and FDD communities.