“How many of you have been on a team in a state of shared vision?” This is the question Jim McCarthy used to kick off last night’s Agile Boston presentation. “Now, stay standing if you thought that team was at least 2x as effective as a team without one… 5x more effective… 10x more effective.”  The majority of us stayed standing throughout.

Yes, that’s just what it is. So how do we create teams with this shared vision – those unstoppable, awe-inspiring teams that are so wonderful to be part of?

Jim and his wife Michelle have spent the last 15 years studying teams in their teamwork laboratory in search of an answer to this question. From this has evolved a set of commitments and protocols they call the Core Protocols.

Read More…..

A Hacker Chick Guest post by Trudy Prins, a wonderfully passionate software development manager at RIPE NCC in The Netherlands. I asked if she might share what she believes makes a successful software team. I hope you enjoy her answer and this glimpse into how she leads her teams as much as I do…

As a Software Engineering Manager, I believe a successful engineering team is a happy team. Happiness boosts productivity, creates an environment for excellence, and offers fertile ground for growth on both a company and a personal level.

So, what makes a happy team?

Frequent knowledge transfers. Team members should have the opportunity to schedule presentations in front of their peers, engage in discussions, follow trends, try out new solutions, have spikes on all kind of topics, go to conferences together and whatever they find suited to share their knowledge & enthusiasm.

Immediate feedback on their performance. I tell them constantly, clearly, and on the  fly what I think they did good, great, or not good at all, without making a big fuss about it or waiting a year until their performance review is up. Their annual review shouldn’t hold any big surprises.

Read More…..

Goodness on the Internets:

An Open Letter to Micromanagers by Scott Berkun.

“Owners of thoroughbreds never stop their horses during a race, every ten seconds, to remind  the horse and jockey how to run, where the finish line is, or that it’d be a good idea to finish first. Why? It would slow them down. Only an idiot would do this…”

and so begins Scott’s letter to micromanagers everywhere. Complete with a link to anonymously send the letter to your favorite micromanager and signed, Hugs and Kisses, The People You are Micromanaging.  I love this guy.

TDD Triage.  Bob Martin addresses a number of questions around Test-Driven Development, hopefully dispelling some of the  religious extremist views on the topic and showing where TDD works and where it doesn’t. These include:

• Is TDD a replacement for architecture? (Nope)
• Is TDD a replacement for design? (Not even)
• Should TDD be used for every line of code? (Usually, but… actually, no)

How Nonsense Sharpens the Intellect. Alright, this is just awesome and reminiscent of Kathy Sierra’s suggestions to insert a little randomness into what we do. A NY Times article explains the science behind why nonsense and randomness actually help us understand things better. And, with that advice, I’ll end this here.

A lot of people say you can’t be a good software manager without really understanding software development. But, let’s face it, people who understand software development are a dime a dozen in our industry. What we really need are people who understand leadership & management. I mean… you know the drill – when was the last time a software project failed for technical reasons?

And so, it was very cool to hear David Spann share his research on Finding and Developing Agile Leader’s at last week’s ScrumClub.

It’s simply not enough to know the latest agile practices. In order for agile projects to succeed, they need leaders who exhibit agile behaviors and, here’s a hint – being a technical guru ain’t one of them.

Now, I don’t want to mislead – David isn’t saying agile leaders don’t have to know anything about software development. What he is saying is that the success criteria for leading agile teams is dependent on the leader’s beliefs and behaviors. That is, how they think and act is  just as – if not more – important than what they know.

Read More…..