The Dynamics of Leadership-Team Behavior

Interesting article in BusinessWeek from Jim Collins on the Dynamics of Team-Leadership Behavior. It's actually an excerpt from his latest book "How the Mighty Fall: and Why Some Companies Never Give In."

Anyway ... the Dynamics of Team-Leadership Behavior is divided into leadership behaviors of teams on the way up vs. on the way down:

Teams on the Way Down	Teams on the Way Up
People shield those in power from unpleasant facts, fearful of penalties and criticism for shining light on the rough realities	People bring forth grim facts—"Come here and look, man, this is ugly"—to be discussed; leaders never criticize those who bring forth harsh realities
People assert strong opinions without providing data, evidence, or a solid argument	People bring data, evidence, logic, and solid arguments to the discussion
The team leader has a very low questions-to-statements ratio, avoiding critical input and/or allowing sloppy reasoning and unsupported opinions	The team leader employs a Socratic style, using a high questions-to-statements ratio, challenging people, and pushing for penetrating insights
Team members acquiesce to a decision but don't unify to make the decision successful—or worse, undermine it after the fact	Team members unify behind a decision once made, then work to make the decision succeed, even if they vigorously disagreed with it
Team members seek as much credit as possible for themselves, yet do not enjoy the confidence and admiration of their peers	Each team member credits other people for success, yet enjoys the confidence and admiration of his or her peers
Team members argue to look smart or to further their own interests rather than argue to find the best answers to support the overall cause	Team members argue and debate, not to improve their personal position but to find the best answers to support the overall cause
The team conducts "autopsies with blame," seeking culprits rather than wisdom	The team conducts "autopsies without blame," mining wisdom from painful experiences
Team members often fail to deliver exceptional results and blame other people or outside factors for setbacks, mistakes, and failures	Each team member delivers exceptional results, yet in the event of a setback each accepts full responsibility and learns from mistakes

HBR on Rebuilding Trust

Some of you may recall some earlier blog-entries of mine on the topic of trust:

• Trust: The social virtues and the creation of prosperity by Francis Fukuyama
• More Articles on Trust
• Building Trust: In Business, Poliotics, Relationship and Life by Solomon and Flores, and
• The Speed of Trust: The One Thing that Changes Everything by Stephen M.R. Covey

As it turns out, the current issue of Harvard Business Review is on the theme of Rebuilding Trust (follow the hyperlink for executive summaries). The article "Trust Revisited" has a roundup of the other articles in the issue that deal with trust:

The public’s trust in business leaders has never been weaker. According to the Edelman Trust Barometer, released in January, trust in U.S. business dropped from 58% to 38% in one year. European businesses are in nearly as much trouble with the public. Businesses in emerging markets are faring better—but not by a lot.

If companies can’t address this problem, an economic turnaround may be delayed indefinitely: Banks won’t lend money; innovation will slow to a crawl; trade across borders will fall even more rapidly; governments will overregulate the private sector; unemployment numbers will continue to rise; and consumers won’t open their wallets for anything they consider nonessential. A complex modern economy simply can’t function unless people believe that its institutions are fundamentally sound.

The articles' executive summaries are:

• Rod Kramer, in “Rethinking Trust,” argues that most of us trust others far too easily. While the pundits claim that businesses need to rebuild consumers’ trust as soon as possible, Kramer argues that we need to remain skeptical.


• Joel Podolny’s piece “The Buck Stops (and Starts) at Business School,” indicts the schools that train managers and executives and shares his thoughts about how to reinvent business education—and thereby regain people’s trust.


• James O’Toole and Warren Bennis argue passionately that senior managers must build a culture of transparency to repair that problem. “What’s Needed Next: A Culture of Candor” makes the case that trust within organizations is the bedrock for rebuilding it in business as a whole.


• In “How to Be a Good Boss in a Bad Economy” Bob Sutton and another Stanford professor take a different perspective on the destructive dynamic of senior management behavior during tough economic times — and describes a better one.

There is also an article from the previous month's issue about "When Contracts Destroy Trust."

Rewiring the Primal Management Talent Code

I came across an interesting book in Borders over the weekend, but didn't have the time to browse it more thoroughly. A few hours later, at home, I looked it up on Amazon.com. I found the description and review comments very interesting, and found myself following links to some related books and reading through those pages as well.

There were three books in particular that struck me as having conclusions that were different, but closely connected, and which combined together to yield something more powerful than any of them does alone. These three books are:

• Management Rewired: Why Feedback Doesn't Work and Other Surprising Lessons from the Latest Brain Science, by Charles S. Jacobs


• Primal Management: Unraveling the Secrets of Human Nature to Drive High Performance, by Paul Herr


• The Talent Code: Greatness Isn't Born. It's Grown. Here's How., by Daniel Coyle

What do you think? Can you see a connection from each of these to the other that suggests a "bigger picture" regarding agility, collaboration, leadership and excellence? How did you connect the dots from one to the other?

Dee Hock on Hiring & Leadership

I came across a great quote from Dee Hock in an article at Good2work.com:

“Hire and promote first on the basis of integrity; second, motivation; third, capacity; fourth, understanding; fifth, knowledge; and last and least, experience. Without integrity, motivation is dangerous; without motivation, capacity is impotent; without capacity, understanding is limited; without understanding, knowledge is meaningless; without knowledge, experience is blind. Experience is easy to provide and quickly put to good use by people with all the other qualities.”

A few other good quotes from Dee Hock ...

“If you don't understand that you work for your mislabeled 'subordinates,' then you know nothing of leadership. You know only tyranny.”

“If you look to lead, invest at least 40% of your time managing yourself - your ethics, character, principles, purpose, motivation, and conduct. Invest at least 30% managing those with authority over you, and 15% managing your peers.”

“If you're in such a position of power and your ego is such that this is not possible, then its essential to have a small cadre of very bright, committed people who are questioning, exploring and understanding these emerging concepts.”

“It is essential to employ, trust, and reward those whose perspective, ability, and judgment are radically different from yours. It is also rare, for it requires uncommon humility, tolerance, and wisdom.”

“Lead yourself, lead your superiors, lead your peers, and free your people to do the same. All else is trivia.”

“Make a careful list of all things done to you that you abhorred. Don't do them to others, ever. Make another list of things done for you that you loved. Do them for others, always.”

“Money motivates neither the best people, nor the best in people. It can move the body and influence the mind, but it cannot touch the heart or move the spirit; that is reserved for belief, principle, and morality.”

More Articles on Trust

Since I blogged about a couple books on this subject I wanted to give a few other resources as well. First off, the reason I came across these resources is because back in January I participated in a discussion with Jim Coplien, Diana Larsen, and Doug Shimp about sharing, trust-loops, and team interaction.

Aside from each of us sharing our own thoughts we also shared some resources. I already mentioned the books. There were also some online articles/materials that were discussed and I wanted to share those here.

• One recent article is Creating Trust by Rick Brenner -- Rick has a lot of good articles at his site, and I'm a regular subscriber to his free PointLookout newsletters


• I also read some interesting things in "Trust and Trust Building" by Roy J. Lewicki and Edward C. Tomlinson, particularly the definitions of "calculus-based trust" and "identification-based trust" (which I admit were new terms to me)


• Fear, trust and Truth in IT Project Teams


• Building Trust in Emergency Response Teams
  


• The Meanings of Trust, by some folks at the University of Minnesota (not sure if this is a research project/report or someone's in-progress thesis)


• Diana Larsen has a presentation entitled "The First Thing to Build": Leveraging Trust on Agile Teams, which builds upon something I said several years back ("The first thing to build is TRUST!" -- which Alistair Cockburn liked a lot and started using it in the signature of his email & forum posts)
  

Diana Larsen mentioned the following:

Another useful book is Dennis & Michelle Reina's Trust and Betrayal in the Workplace. They've developed an interesting model they call Transactional Trust which is a further explanation of the behaviors involved in "you've got to give it to get it?". They include three kinds;

• Contractual trust - managing explicit and implicit expectations, establish boundaries, delegate appropriately, encourage mutually serving intentions, be consistent, keep agreements (do what you say you'll do)
• Communication trust share information, tell the truth, admit mistakes, give & receive effective feedback, maintain confidentiality, speak to good purpose (avoid gossip, a.k.a "be impeccable with your word")
• Competence trust - acknowledge people's skills and abilities, allow people to make decisions, involve others & seek their input, help people learn new skills

Robert Hurley wrote an article for Harvard Business Review, Winning Your Employee's Trust. It's more about the relationship between leaders and staff. The interesting part, to me, is a model he developed out of his research. It links back to that idea that people's capacity for trust comes both from within themselves and from situational context, in a sophisticated (and unconscious) calculation of numerous elements. Fascinating, I thought.

Another article you might find interesting is called, Promises, Lies and Apologies: Is it Possible to Restore Trust? and is about what circumstances contribute to whether trust can be rebuilt. Particularly apt here in Portland as we deal with the lies our newly elected Mayor got caught in.

If you have some links to some other good resources on trust, please add your comment and share them with me!

BOOK: Software Teamwork - Taking Ownership for Success

My review of Jim Brosseau's Software Teamwork: Taking Ownership for Success is available in the May issue of the Agile Journal. It is nothing less than outstanding!

I found Software Teamwork to be an immensely helpful, intensely practical, profusely insightful field guide to improving team outcomes and changing team behaviors by focusing on interpersonal action and personal leadership. This book belongs on any software team-leader's bookshelf, along with Jean Tabaka's Collaboration Explained and Murray Cantor's Software Leadership.

Other articles in this issue on the theme of "Challenges with Distributed Agile" are:

• Softening Iterations - Setting up for success
• Overcoming Resistance to Change with Distributed Agile
• Agile Adoption Patterns
• KPIs for Agile Teams

What do you wish your CEO knew about Agile?

Esther Schindler has been posting on a number of different Agile-related groups & forums asking participants the question:

If you could get the boss to understand one thing, just ONE THING, related to Agile development... what would it be? Why that?

When she posted this to the Agile CM forum at cmcrossroads.com, my reply was as follows ...

My "one thing" would be a bit more basic than either CM or "Agile" (IMHO), and culled from Steve McConnell's talks on "Critical Insights for C-level Executives" and "The 10 Most Powerful ideas in Software Engineering" both of which are available online from Construx (unfortunately you have to register to download them, although registration is free and they promise not to spam you)

McConnell starts off with what he says are 5 insights that C-level Executives already know:

• Software projects are late
• Software projects are out of control
• Answers from software staff are often incomprehensible
• Answers from software staff often seem evasive
• Software is the most unpredictable part of the business

Then he goes on to describe what he calls the 7 Critical insights about software development that C-level executives need to know:

• Typical Budgeting Processes Undermine Effective Development (and don't acknowledge the "cone of uncertainty")
  
• Stage-Gate Processes Are Prevalent In Leading Companies
• Low Quality Is The Single Largest Cost Driver
• People (Staff) Exert The Largest Impact On Project Outcomes
• Software Improvement Works Best When Supported at the Organizational Level
• The Tradeoffs Between Cost, Schedule, And Quality Might Not Be What You Think They Are
• Improved Software Practices Offer Exceptionally High ROIs

McConnell describes the 10 most important/powerful ideas in software development as follows:

• Software Development Work is Performed by Human Beings (people are the single biggest influence factor for success)
• Incrementalism is Essential
• Iteration is Essential
• The Cost To Fix A Defect Increases Over Time, Throughout the Development Lifecycle (even when using iterative/incremental/agile development)
  

• There’s an Important Kernel of Truth in the Waterfall Model
• Ability to Create Useful Software Estimates Can be Improved Over Time (The Cone Of Uncertainty)
• The Most Powerful Form of Reuse is Full Reuse
  
• Risk Management Provides Critical Insights into Many Core Software Development Issues
• Different Kinds of Software Call For Different Kinds of Software Development - The “Toolbox” (there is no single best best practice or method across all software projects/products)
• Software Engineering Body of Knowledge - SWEBOK (existing body of knowledge provides a wide spectrum of support for software development practices, especially CM, PM, RM, QM, Testing, Design, Construction, Management, Maintenance, Methods and Tools)
  

So how would I distill all of that into a single statement to communicate to C-level executives? Tom Gilb get's an honorable mention for his "The Ten Most Powerful Principles for Quality in [Software and] Software Organizations", which he summarizes as a single principle saying:

"Motivate people
towards real results
by giving them numeric feedback frequently
and the ability to change anything for success."

For me, the gist of all the above is that most corporate planning, estimation and management "systems" for software are badly broken because they utterly fail to acknowledge the inherent uncertainty and variation that cannot be removed by "up front" attempts at perfectly stable project plans and/or product requirements (see my article on "The Unchangeable Rules of Software Change"):

• The solution is not going to come about by striving ever harder for perfectly stable plans and requirements earlier in the project!
  
• The only successful way to manage that is through effective and continuous management of risk and change!
  
• And the most effective means of doing that is through the use of iterative and incremental techniques that put people first in order to give frequent feedback and reflection on real-results throughout the course of the project (while still leveraging the existing body of knowledge to serve those people so they can best serve the business).

Many companies seem to behave as if merely identifying risks and having mitigation plans is sufficiently effective, and they just need to do that "up front" and then monitor the risk-list without having to spend much time adjusting, adapting, and refining it throughout the project.

Similarly, many companies seem to behave as if they can effective manage change is they basically strive to prevent changes once the project/requirements is (are) initially baselined.

All that is poppycock! Effective risk and change management comes about only by taking a continuous approach to manage them that use regular increments and iterations to achieve frequent feedback on tangible, valued results. Even that by itself is not enough, because if you do not enable and empower your people to act on those results, collaboratively, throughout the entire lifecycle, then you won't be very effective or efficient at reaching your goals. Your process has to leverage the power of your people rather than being an obstacle that overly constrains/controls them.

That all goes for CM and managing change just as much as it goes for development and managing projects! Stop thinking it is feasible to drive out 100% of the variation and uncertainty early in the project, and rechannel that energy instead on managing risk and change continuously, utilizing iterative/incremental means to attain frequent & regular feedback. Then make sure you empower your people to act on that information by effecting necessary changes as quickly as possible, and using processes that regularly embrace such changes instead of stalling or preventing them.

Top-down Agile Adoption in March Agile Journal

The March issue of the Agile Journal is about scaling-agility and agile adoption in the enterprise.

Lean view of Deming's 14 Points for Management.

There has been a really great discussion thread on the Lean Development YahooGroup on the subject of "How do I find bottlenecks?"

I particularly liked a reply by Alan Shalloway that linked things back to W. Edwards Deming's 14 points for management from his Theory/System of Profound Knowledge. Allan's translation has a bit of a "Lean" slant to it, and doesn't explicitly mention eliminating/reducing variation quite so much. Here is how he summarized it:

Re respect for people, the best place to start, IMHO, is Deming. Here are his fourteen points (Chapter 2 of Out of the Crisis, by W. Edwards Deming, MIT Press, 2000; originally published in 1982.):

1. The world has changed and managers need to adopt a new way of thinking. Delays, mistakes, defective workmanship and poor service are longer acceptable.


2. Quit depending on inspection to find defects and start building quality into products while they are being built. Use statistical process control.


3. Don't choose suppliers on the basis of low bids alone. Minimize total cost by establishing long term relationships with suppliers that are based on loyalty and trust.


4. Work continually to improve the system of production and service. Improvement is not a one-time effort; every activity in the system must be continually improved to reduce waste and improve quality.


5. Institute training. Managers should know how to do the job they supervise and be able to train workers. Managers also need training to understand the system of production.


6. Institute leadership. The job of managers is to help people do a better job and remove barriers in the system that keep them from doing their job with pride. The greatest waste in America is failure to use the abilities of people.


7. Drive out fear. People need to feel secure in order to do their job well. There should never be a conflict between doing what is best for the company and meeting the expectations of a person's immediate job.


8. Break down barriers between departments. Create cross-functional teams so everyone can understand each-other's perspective. Do not undermine team cooperation by rewarding individual performance.


9. Stop using slogans, exhortations and targets. It is the system, not the workers, that creates defects and lowers productivity. Exhortations don't change the system; that is management's responsibility.


10. Eliminate numerical quotas for workers and numerical goals for people in management. [We add: Eliminate arbitrary deadlines for development teams.] This is management by fear. Try leadership.


11. Eliminate barriers that rob the people of their right to pride of workmanship. Stop treating hourly workers like a commodity. Eliminate annual performance ratings for salaried workers.


12. Encourage education and self-improvement for everyone. An educated workforce and management is the key to the future.


13. Take action to accomplish the transformation. A top management team must lead the effort with action, not just support.

These go back 60 years. And (I can't help myself) these principles are in the context that process causes 94% of the errors - so work on the process to support the people! (people and process, people and process, people and process, ...) ;)

Alan Shalloway, CEO, Sr. Consultant
Net Objectives, Gold Level Sponsor of Agile 2006.
Integrating people, process and technology through training, coaching and consulting.

Alan's website also has some really great articles, papers, presentations and resources on Agile, Lean, Scrum, XP, Design Patterns, and all things related to Agile development and object-oriented design.

For some slightly different interpretations and summaries of Demings 14 points and Seven Deadly Sins, see the following:

• Wikipedia entry on W. Edwards Deming
• Demings 14 points and Seven Deadly Sins of Management from Ends of the Earth
• A summary of Deming's 14 points from the University of Cambridge Institute for Manufacturing
• Phil Cohen's summary of Deming's 14 points (which seems steeped in the language of removing/reducing variation)

There has also been a thread on another discussionlist (sorry - the name escapes me at the moment) on the relevance (or lack thereoff) of Deming's writings and philosophies in the world of today.

What are your thoughts?

Aikidoka Leadership, Influence and Conflict Resolution

There are a few good books about conflict resolution & leadership that use Aikido style/philosophy throughout. I highly recommend them for anyone interested in the connection between leadership and martial arts philosophy:

• The Magic of Conflict, by Thomas Crum


• The Randori Principles: The Path to Effortless Leadership, by David H. Baum (and Randori Partners)


• Verbal Judo: The Gentle Art of Persuasion, by Dr. George Thompson


• Articles by Judy Ringer on conflict resolution using Aikido principles


• ARTICLE: Aikido & Conflict Resolution: What's the Connection?

There must be some of you out there who have some other links to share on this topic! Leave a comment with your favorites!

Everyone wants to be LUVEd!

I had a posting on Scott Berkun's project management (pmclinic) list that was rather well received. I thought folks here might be interested in it ...

Someone else had written:

> I've found that powerful people respect people who do not back down from them. Make your point forcefully.

I responded with:

That could backfire really badly! That might work with some, for others it will only make things worse. Either way, what they are looking for is respect for their perspective. They want to be LUVed:

• Listened to,
• Understood, and ...
• Valued.

Making any assumptions about what it means to them to be LUVed and what behaviors they feel demonstrate LUV could easily be jumping to conclusions down a very wrong and unconstructive path.

Chances are the "annoyance" is because, somewhere, somehow, the two people involved have different notions of what it means to feel respected and to be treated respectfully and be LUVed. What you regard as disrespectful and disruptive may seem just the opposite to him. He may feel that by giving what you say substantial thought and vocalization on multiple sides to be an act of mindfulness rather than dissension.

I would suggest getting together one-on-one for an open, honest, and candid yet compassionate discussion about what each of you need and what you should/can expect from one another. Dont attribute feelings/motives/intent to him, instead describe his (or her) actual, factual, observed behavior and how it makes you feel, what that makes you think, and its consequences/impact on you and others.

Something is certainly out of alignment between the two people in question, but it may not be objectives or intent, but rather differences in values and belief as to what constitutes respect, progress (versus disruption) and what things are most/more important for overall success.

So in terms of advice, I would add an 'E' to the end of the LUV acronym to make it LUVE: Listen, Understand, Value/Validate, Empathize:

• Listen attentively to what the other person has to say
• Understand it to the best of your ability (you don't have to agree with it, just "seek first to understand")
• Value/Validate what was said. That doesn't mean agreeing with it; It does mean finding the value in it and validating that value to the speaker.
• Empathize with the speaker. Try to identify the feelings they are experiencing and demonstrate your understanding of it, and that it is okay for them to have those feelings.

I wish it was as easy to do habitually as it was to write about. If I could develop the above habit, I would be 10X more effective in both my personal and professional life!

The New Rules: Agile beats Big

The July 24 issue of Fortune Magazine has an article entitled The New Rules as the cover story, with the cover saying "Sorry Jack! Welch's Rules for Winning Don't Work Anymore (But We've Got 7 New Ones That Do)"

I think the new rules it discusses are very much about "Agile is better than Bigger!" and "Bigger isn't necessarily better!" The list of new rules is:

Old Rule: Big Dog Owns the Street.
New Rule: Being Agile is Best; Being Big can Bite You!

Old Rule: Be #1 or #2 in Your Market.
New Rule: Find a Niche, Create Something New.

Old Rule: Shareholders Rule.
New Rule: The Customer is King.

Old Rule: Be Lean and Mean.
New Rule: Look Out, Not In.

Old Rule: Rank your Players; Go with the A's.
New Rule: Hire Passionate People.

Old Rule: Hire a Charismatic CEO.
New Rule: Hire a Courageous CEO.

Old Rule: Admire my Might.
New Rule: Admire my Soul.

All in all I thought it was pretty fair-minded. There was even a sidebar to the article that gave Welch a chance to respond to the criticisms. You'll probably need to read the article for further insight into what exactly is meant by each of the "new rules" above. There was plenty of commentary across the industry on the article! (Just Google on "The New Rules" +Fortune +"Sorry Jack" and look through the results)

Leadership/EQ Rites of Passage and the Mythical Manager Month

A bit of a follow-up on my previous blog-entry about Matthew Edwards and his recently published a book on Creating Globally Competitive Software: The Fundamentals for Regular People.

I wrote:

I have a lot of respect for Matt, he and I went thru a lot of "stuff" together over a very short+intense period (more on that in a moment) and managed to come through it while spreading a little bit of light. During that time I also pointed Matt in the direction of Agile development as a possible "way out of the madness", and he did his part to help make that a reality.

Here's the story on that ... I worked with Matt back in 1999-2002 on what was then a hideously dysfunctional "death march" project that we were trying to pull out of it's own self-created and self-perpetuated hole. The product was an internal one, and Matt, a former testing Guru, was one of my key customer reps. The project suffered from just about everything under the sun:

• Bad management (failure to set+manage expectations & appropriate interfaces)
• Dysfunctional customer & internal organization (warring tribes, turf wars, political silos, and a severe lack of trusting/trustworthy mgmt leadership),
• Management that felt senior architects/designers aren't supposed to get their hands dirty in "coding"
  
• A tech-lead with great technical & project knowledge/skill/experience and strong passion for quality design but with an equally great reluctance to lead, overly trusting and possessing piss-poor leadership & communication skills at that time (me)
• Managers that had great communication skills, but no clue about successful software development, and no interest in learning it
  
• A highly talented team of young, promising developers, but with a total lack of software development experience/maturity (which wouldnt necessarily be a bad thing if not combined with all of the above)
  

And so much more ... in fact that project managed to take two of the best-known worst practices ("the mythical man-month", and "too many chiefs/generals, not enough indians/soldiers") and combine them into an even worse one that I dubbed "The Mythical Manager-Month":

The Mythical Manager Month -- adding more managament to a late & failing project just makes everything thing worse and everyone more miserable.

I have to say, that project really taught me a lot about leadership and communication, particularly ...

• how leadership differs from management, and from cheerleading
• the importance of planning your communication and having a communication plan
  
• the huge impact of really good managers versus really bad ones,
• the difference between credibility and trust
  
• the difference between power/influence and authority
  
• how incredibly selfish, two-faced, and despicably unethical some folks can be
• how to recognize malevolent manipulators who appear to "befriend" you to gain your trust, but will betray and backstab to get what they want
  
• and how to recognize (and handle) a demagogue masquerading as a "heroic manager."

The first two years of that project were both a painfully magnficent failure, and a painfully magnificent teacher. It was definitely a leadership "rite of passage" for me, and leading the successful turnaround of project (in which agility played a large part) was a deeply educational and visceral personal experience that has largely shaped my career & objectives since.

The books by Patrick Lencioni on team dysfunctions and how to overcome them, as well as organizational silos, politics & turf-wars would have done me a world of good back then if they'd been available (and if I'd had enough previous appreciation of those problems to have read-up on them and other works related discovering and raising my Emotional Intelligence).

That project marked my transition from "unconscious incompetence" about leadership & communication to "conscious incompetence" and really motivated me to navigate the path to "conscious competence." I yearn for the day when it becomes unconscious competence.

I'm not quite there yet. It's been a long leadership journey (much longer in experience and learning than in actual years) since that project, and I still have a long ways to go. But these days my bookshelf at home is replete with just as many books about leadership, EQ, influence, and communication as my technical bookshelf at work is with books on software development, and I think about a lot more than just the technical strategies/techniques/practices and lessons learned in my day-to-day work.

Book Review: Collaboration Explained

My review of Jean Tabaka's Collaboration Explained: Facilitation Skills for Software Project Leaders appear's in this month's issue (April 2006) of The Agile Journal.

I think the book has a lot of useful information, methods and techniques about creating collaborative software teams that are pretty hard to find in other books because most other books on the subject aren't targeted specifically at software development and software project/technical leadership. See the Featured Book section for the review.