There are some great books on agile team dynamics nowadays. My personal favorites include:

• Collaboration Explained by Jean Tabaka
• Agile Retrospectives by Esther Derby, Diana Larsen, Ken Schwaber
• Right-Brain Project Management by Michael Aucoin
• Great Boss Dead Boss by Ray Immelman
• The Blind Men and the Elephant by David Schmaltz

The problem is that most people do not get the time they want or need to read about these topics. So, I have created the following: Top 10 Team Practices list and one-page printer friendly version to remind us of some of the basic points.

If you lead a team then print the sheet and post it somewhere visible and do a mental inventory of the practices from time to time. If you are a member of a team that could do with a boost, print a copy and post it on your manager’s wall, I am sure they will thank you for it! (actual results may vary.)

1) Empower them – By giving control for local decision making and work sequencing to the team we gain the advantages of additional insights, better motivated teams, and more practical plans with less waiting. 

2) Listen to them – The team is closer to the technical details of the project and also best placed to determine the most successful solutions to project challenges and problems. Encouraging the team to solve the project problems has two main benefits. It demonstrates they are valued for their insight as well as their output, which makes people feel more involved and appreciated. Also, solutions suggested by the team are more likely to be embraced and executed with enthusiasm. It is better to have a 70% optimal solution executed with 80% enthusiasm than a 100% optimal solution executed with 40% enthusiasm.

(The “Balanced Blend” Manifesto takes Shape)

Don’t really buy into all the hype of agile? Think it works up to a point, but real-life is actually more complicated and demands more of a hybrid approach? – Don’t worry, you are not alone.

Since helping define DSDM in 1994, I have spent the last 14 years helping organizations adopt agile methods like DSDM, Scrum, XP, FDD, etc and have come to realize, like many others, that these methods are not the solution. Instead they are the over-simplified starting points that you need to blend into what already works within the organization. Then overlay and support with additional approaches to create successful project ecosystems.

We need simplified schematics of systems to assist comprehension and discussion. However, all too often these simplified models are put into production as the entire solution and then problems occur.  Like a simplified model of a car braking system, it is useful in helping us understand how the system works in theory, yet is full of design flaws for practical implementation.

In real life, servo’s and pumps are needed to amplify the braking force from the pedal. There is not a single shared-fluid system, but instead two diagonally opposed systems (so a leak does not result in total brake failure or pulling to one side in a left and right split system). In addition to the basic system shown here, cars also employ an array of supporting systems for fluid level monitoring, ABS, wear detection, etc.

Luckily people do not read about the basics of car braking systems and then decide to replace the one on their car with their own design. However plenty of people read about agile methods and decide to implement that as their new software production system.

The good news is that the state of existing software production systems is often very poor and so implementing any kind of better conceived system is an improvement. (A basic sub-optimal braking system is probably better than relying on throwing an anchor out the window and hoping it snags on something to stop you!) The problems occur when the current system is not optimal, but understood and working; and it is then replaced by an oversimplified alternative.