Collaboration: At the Extremities of Extreme
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Deborah Hartmann Preuss on Oct 29, 2009
Traditional management models don't tell leaders how to support their Agile teams without undermining their emerging self-organisation. Allusions to musical performance and "conducting the orchestra" abound - but not everyone agrees this is apt. Is the "conductor" model a good practice or an anti-pattern? In his TED talk, former conductor Itay Talgam shows us video of several types of conductors, and talks about what their style does to the "teams" they lead. And perhaps we also need to take into account the styles of the teams themselves.
In this 20-minute talk, entitled "Lead like the Great Conductors," Talgam says from experience that the ability to stand up and bring order out of chaos feels fantastic, and that it's a great temptation for the conductor to think "it's all about me." In fact, the small gestures of that one person are quite insufficient to bring about the magnificent music of the orchestra. it is the product of everyone contributing their stories, their skills. Different conductors engage these skills in different ways, and may in fact help or hinder this process.
Talgam showed films of, and then discussed, the styles of five famous conductors. They are outlined here, but it's really worth watching the body language in the films he shows. It's amazing how much one can influence a group without words!
Depending on which model one references, it's easy to understand why some espouse the idea of Agile leadership as "conducting', while others insist that the the orchestral conductor model has no place within a self-organising team model.
The fact is that not all teams are alike, and perhaps they should not be led in the same way. The Hershey-Blanchard "Situational Leadership" model was referenced several times at the recent ScrumGathering in Munich. Joseph Railin, in Creating Leaderful Organizations calls it a "Followership Model" because it suggests that the key to helping team members growing into leadership lies in matching one's leadership style to the team's level of readiness to follow.
Hershey and Blanchard identified four different states of "readiness to follow". Note that "able" indicates ability to do work tasks both intellectually (training) and emotionally (personal maturity).

Ideally teams progress through these to reach "Able, Willing". What we've learned from the Tuckman "-orming model" suggests that events or situations can cause teams to thrash back through previous states (for example: new team members or economic instability). It's also worth noting that, by some definitions, until a group is at least "willing" it cannot really be considered a team.
For each of the four follower orientations, Hershey and Blanchard identify a different style of leadership as useful. This means that what worked wonders for one team may not be helpful to the next, or not for every member. It appears that an Agile leader may need a toolkit of different approaches.

In this model, the axes represent attitudes of the leader: "Relationship Oriented" refers to the emphasis required on the relationship between leader and followers, and "Task Oriented" refers to the effort that the leader needs to put into readying followers to do the actual tasks.
Other names have also been used for these leadership styles:
| Telling | Directing |
| Selling | Coaching |
| Participating | Joining, Supporting |
| Delegating | Trusting |
A clear, brief discussion of what the "readiness" states look like and how each style can be applied and misapplied is available on the website of the Science and Technology Commission of Shanghai Municipality. The model, dating from 1972, is also referenced in numerous management and leadership books.
Transforming Software Delivery: An IBM Rational Case Study
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Ok. Forget the vision of the magnificent theater where you see just one guy jumping and waving and you feel the music filling the empty space. Now imagine a more personal journey, a small room with a musician with the instrument in the hands, a paper with notes and eyes closed, waiting for inspirational wave. Fingers bleeding because of practice. Sweat, tiredness.
Now, back to theater, empty, and the conductor asking for pieces, indicating the feeling it must transmit, repeating difficult parts, explaining the idea, the wholeness of music body.
At the end, it sound great, but not only because each individual musician, not only because the conductor waving, not only because the rehearsals. It was all due to the process.
So, in other words, one musician is not all the orchestra. Many musicians are not the orchestra. Each has a part of the orchestra, and conductor has another part. Conductor is not a separated part of the self-organized team, it is part of the team and adds to the final product.
William Martinez Pomares
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
1 comment
Watch Thread Reply