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.