Agile Team Dynamics


An interesting post on Agile Team Dynamics.

"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 our 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."


Some Team Rules from the post…

  • 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 that’s 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 ….

Original URL:



Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s