Agile Team Dynamics II

[REFACTORED: I have updated this post to answer some of the specific questions I received. Thanks also for the many comments posted - but since there was an increasing number of inappropriate postings, especially foul language, I am moderating these now.]

Most of the challenges some of our projects teams face are generally not technical -- they tend to be business (or political) issues; a new team getting to know one another and evolving their style as a team; or, the team getting to grips with the business domain they are operating in. This is mainly the case when the team is made up of finetix staff, client mgt, client developers, and other consultants. In these situations, the team dynamics seem to be the most common thing we have to help teams out with. Politics are another (but never-ending) story.

I have been sitting in on some of the daily stand-up meetings, sprint demos, retrospectives and planning meetings on a few of our agile projects. It has been interesting to see the dynamics of these "cross-entity" teams at play as they follow the Scrum process. As is the case in most situations, you can't just flip a switch at the beginning of the project and expect the entire team to be executing the process perfectly. There is always some coaching/mentoring/educating required to make sure EVERYONE is doing what they need to do. On one of the projects, during the Scrum and the planning meetings you could observe that boundaries of responsibilities were being crossed (e.g. Product Owner vs Scrum Master vs core team). So, one of the things we did (other than re-emphazing the process) was to have the team create and agree to some rules to help improve the team dynamics and to emphasize that they need to stick up for one another. The following rules were posted in the team room:

• Emails should be BANNED for inter-team communication. If you have a question, issues, problem with someone on the team or the way things are being done, SPEAK to the person or the team.
• Decisions made by the team UNANIMOUSLY should be communicated to the entire team - wikis, etc - emails ARE good for this. Examples, include decisions regarding designs, clarifications of ambiguities, development process, etc.
• The entire team must UPDATE ALL TASKS in the Sprint Backlog before they go home at night. No exceptions.
• The whole team is accountable for all tasks and estimates.
• If you don't agree with something that a team member says or does, or if someone puts you on the defensive, SPEAK UP and stick up for yourself and let them know how you feel (really feel - "Honesty Is The Best Policy"). If the team is not making unanimous decisions it is not working together as a whole.
• If the team believes it has hit a barrier or estimates suddenly jump, such that THE TEAM thinks it will not deliver on time, then it is time to raise it to the Product Owner (for potential de-scoping). If the team still honestly believes that it can make the deadline, then thats OK – it just needs to agree collectively to get through the workload accordingly.
• If(or when!) there are issues, problems, etc it is very important that the whole team understand the issues clearly and the entire team understand the solution. This way a) you all know what happened without ambiguity and b) the team knows how to deal with it going forward, and c) reduces dependencies on individuals.
• There is no such thing as 'lost time' – either a task was not completed due to impediments or estimates are recalculated due to needing more time, or you put a task on hold and pick up a new one.
• There is only one PRIMARY metric – deliver or not deliver ....

The result was that in the 3 subsequent sprints the team delivered when they said they would (and yes, there were 1 or 2 things dropped from scope), and you could actually see some pride and smiles in their achievements.

The reality of introducing agile to new clients and different IT organizations is that the change management required can be very tough and has to be constantly and diligently applied. It would be great if every client was up for doing every project in an 'pure' agile manner, but that is not reality. What we can do though is gradually educate and show them what it means to be agile and why that is a good thing. The retrospectives are really key for everyone involved but the changes needed to refactor the teams and organization have to be embraced by everyone.