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.

Ten Faces of Innovation

Author:

Tom Kelly

Premise:

This book discusses the importance of innovation and how it separates good organizations from excellent organizations. The Ten Faces of Innovations also details the different personas that can foster & create innovation within an organization.

Review details:

You can find the full review on my blog, Review of The Ten Faces of Innovation.

Made to Stick

This is a book definitely worth reading.  I maintain my own blog so as opposed to having duplicate content, I’m going to link over to that post.

Made to Stick Review.

Slide:ology – My Initial Review

In an earlier posting I included a link to an excellent presentation by Nancy Duarte, the author of Slide:ology. Since then her book has come out and I was able to get a copy just before I left for vacation so I thought I would take it with me.

So I started reading the book on the airplane to Kauai. From the very beginning of the book, and by the beginning I mean the acknowledgments, I found the content to be first class and enlightening. I was so intrigued by the book that I found myself compelled to continue flipping pages to see what was on the next page. I spent 2 hours on the plane just flipping through the book and reading the highlights.

This is a first class book in every regard. The content is deep, the examples are spot on and the author uses her own lessons of great presentations in putting together this compelling book. My only complaint is that the book should have come out in a hardcover. This is a book that is going to get a lot of use but is also such a beautiful book that I would be distressed if the pages and its cover get beat up.

Making Money

One of the main things attracting me to work for Tacit Knowledge was that Tom Looy is Managing Director.  I don’t say that to brown nose because, well, I don’t need to.  Tom knows how I feel about him. When I first learned about Tacit Knowledge, I started reading Tom’s blog “Conversations with Andrew” and knew that this was someone that I really wanted to work with.

Anyone who knows Tom knows that he loves to read business books.  I’m usually more attracted to self-help books.  However, since I’ve joined Tacit Knowledge, I have been reading more business oriented books, the evidence of which is the past three entries I’ve left on this blog.

One of the books Tom recommends to just about anyone who will listen is “The Goal” by Eli Goldratt.  Goldratt is know as the father of the “The Theory of Constraints” which says that your throughput can be no greater than the slowest producer in your production line.  I haven’t intentionally put off reading “The Goal” until now.  Honestly, I’ve just been busy with other books, mostly books that are very specific to quality assurance or testing, such as “Lessons Learned in Software Testing” which Matt Short so wisely recommended to me, the two Gerry Weinberg books mentioned below in a previous post and Gerard Meszaros’ “xUnit Testing Patterns” which I am, I confess, still struggling through.

Of course, one of the reasons I enjoyed “The Goal” so much is because of it’s relevance to testers and quality assurance.

“The Goal” is a business novel and its protagonist, a guy named Al Rogo, takes his son’s boy scout troupe on a hiking trip, during which he makes observations about how fast the troupe moves.

“Looking ahead, I can see that how much distance each of us has to make up tends to be a matter of where we are in the line.  Davey (the second kid in line) only has to make up for his own slower than average fluctuations relative to Ron — that twenty feet or so which is the gap in front of him.  But for Herbie (the slowest kid) to keep the length of the line from growing, he would have to make up for his own fluctuations plus those of all the kids in front of him.  And here I am at the end of the line.  To make the total length of the line contract, I have to move faster than average for a distance equal to all the excess space between all the boys.  I have to make up for the accumulation of all their slowness.”

Does that not describe the testing department in a nutshell?

The interesting thing about this book, written in 1984, is that it is suggesting the very thing that we are currently in the middle of implementing at Tacit Knowledge, that being the idea of putting quality in front of the bottlenecks

“Make sure the bottleneck works on good parts by weeding out the ones that are defective.”

Concretely, for the software world, Tacit Knowledge’s proposal for doing this is to create a role that is part quality assurance and part business analyst.  The intent is to reduce the number of defective and/or vague stories going through development.  Jonah, the wise sage in the story, says something really great that I have learned many times.  In reference to clients that would come to him to solve mathematic problems, Jonah said that they wanted him to check their numbers, which were almost always right. What he learned is that …”if I checked the assumptions, they were almost always wrong.”

Again, this statement very much represents what I have found in my career in quality assurance.  I find the most problems by checking assumptions, which is why I feel that the new role we’re creating is going to help the throughput of the team.

Next, I’m planning on reading either David Anderson’s book on Agile management or one of the two Poppendiecks’ books on the subject of TOC applied to software.  Does anyone have any recommendations?

I wish that I knew what I know now

“Getting to Yes” has been in my queue for over a year but I wish I had read it last week. I wish I had read it last year. I wish I had read it 2 years ago.

“Getting to Yes” is a classic, best seller for a very good reason. So much of our lives are spent in negotiation and yet so few of us are skilled in it. We know how to become entrenched in our position, or to cave in to pressure but so few of us know how to try to negotiate in a way that both sides get what they want. This is the true skill and, what do you know, the book outlines some easy to understand, intuitive guidelines to help you engage in what the authors call principled negotiation.

As the authors say in the book, many of these principles are things you may already be doing. My guess though is that very few of us do all these things intuitively. I constantly find myself bringing up the past (that’s a big no-no) and not keeping in mind what my fellow negotiators best alternative to a negotiated agreement is.

I adore the idea of principled negotiation. Negotiation has made me uncomfortable in the past, mostly because I have this notion that I won’t get what I want unless I get entrenched, if I compromise in any way I’m a sucker, and if the other person is entrenched there will be no way to move them. This book has changed all that for me.

But don’t just take it from me. You can read an outline of the book on wikipedia.

Dysfunction

Upon the recommendation of an executive at the company where I’m consulting, I read “The Five Dysfunctions of a Team” by Patrick Lencioni over the weekend.  It is a novel that illustrates a methodology which identifies some reasons why teams are dysfunctional.

I don’t have much to say about this book other than I think everyone in my company should read it for the purpose of being able to recognize these patterns.  Programmers reading this review will understand it when I say this book identifies five anti-patterns of teamwork and helps you recognize when you’re committing them.  Although the characters in the book are executives, the anti-patterns are easily recognizable in any team situation.

This is a short book with small pages and big print.  It is probably the most accessible business book I have read, so for those of you who tend not to like books about soft stuff, this one may be for you.  I personally find anti-patterns just as helpful as patterns.  Being able to recognize what not to do doesn’t always lead you to what to do, but it can lead to lively, healthy conflict, which is something Lencioni encourages.

I’m curious if anyone else has can recommend any of Lencioni’s other books.

Quality Before Design

This year at (C)AST in Toronto, I had the unique opportunity to be one of 30 in room alone with Jerry Weinberg. Weinberg is a Quality guru and his approach extends far past testing. In his recent book “Perfect Software and Other Testing Illusions” he talks about his approach as “meta-quality assurance”. When he describes his ideal approach, it entails asking people tough questions and going to the root of the problem, which is usually poor communication. He even describes one of my favorites techniques; asking a bunch of people the same question and seeing how many answers you get because if it’s more than one, the requirements are vague and there are bound to be bugs.

Weinberg started thinking this way years ago as evidenced in the book I just read, “Exploring Requirements: Quality Before Design” by Weinberg and Donald Gause, written in 1989. Much of what he wrote 19 years ago is well known to us now, and some of the ideas presented here are more concisely represented in “Perfect Software”.

I enjoyed this book from the preface because they invoke the famous Dwight Eisenhower quote, “The plan is nothing; the planning is everything.” The authors go on to modify this statement with product/process, discovery/discovering and (yeah) document/documenting. This book contains great outlines in here to help people get down to the bottom of ambiguous requirements. Chapter 6 has a list of Context Free questions aimed at helping the group define the requirements more clearly. This is worth the price of book.

Chapter 1 has a provocative title: “Methodologies aren’t enough”. It is a fitting title for a chapter in a book that doesn’t ignore the communication aspect of building a product. I’ve often said that methodologies like XP, Lean, and Agile are great but that they don’t address some of the inevitable problems they bring to the surface — that being the problems people have communicating with each other. Weinberg and Gause don’t entirely address the interpersonal problems (though they do present some tools for running efficient, effective, and safe meetings). But they spend much of their time defining the various aspects of designing a product and detailing various ways that the communciation process can break down, resulting in bad requirements.

Chapter 17 is all about helping the client determine what is the difference between a preference and a constraint. Weinberg uses a marvelous metaphor here: the pinball tilt. In pinball, if you don’t tilt at all, you’re too timid. Tilt too much and you’re being to aggressive. The best pinball players tilt sometimes, but not too much to prevent them from scoring high. In order to be good at playing with what’s a preference and what’s a constraint, you’re going to tilt sometimes.

I think what I like about this book is that this is a rare, practical book about how to implement quality. There is only one chapter on testing, and that chapter is specifically about testing the requirements. I’d recommend this book for any Business Quality Analyst.

Does Organizational Transformation Work?

Apparently it does, but not in the way most of us think it does. The word is that top-down mandates are usually unsuccessful in provoking sustained organizational change. Why? Well, it might have something to do with brain chemistry.