Agile Team Dynamics

Agile has an inherent focus on teams. The Agile principle, “Individuals and interactions over processes and tools” stresses the importance of how people work together. Therefore, strong Agile team dynamics is a key component of a high functioning  Agile organization.

In this presentation, you’ll learn about the signs to look for in a dynamic Agile team room and how to get a team performant – and happy.

Agile Room (Team) Dynamics: Getting Teams Performant (and Happy)

What You’ll Learn in this Presentation:

  • The signs to look for in a dynamic Agile team room.
  • How to get a team performant (and happy).

Why (Room) Team Dynamics are Important

  • Agile focus on people strongly related to teams.
  • In a team environment, team dynamics translates directly into productivity.
    • A happy team will inherently be more productive. Agile is no exception.
    • Conversely, an unhappy team can be extremely non-functional.
  • When a team isn’t working well, everyone suffers.

The 11 Signs of Good Room Dynamics

  1. Deliverables are EVERYONE’s responsibility.
  2. Team Lead and Architect roles may be designated, but delivery is
  3. EVERYONE’s responsibility.
  4. Everyone is engaged & respected.
  5. Healthy debate and conflict happens – and compromise.
  6. Whiteboard sessions.
  7. Members help each other.
  8. Team members have confidence in each others’ abilities.
  9. No egos.
  10. Buzz in the room.
  11. Celebrations of small successes.
  12. Music.

Deliverables are EVERYONE’s Responsibility

The team must be working as a team towards a common goal.

    • Everyone has the same understanding of the overall project objective.
    • No silos.

Certain team members may be focused on specific stories or tasks, but they are not solely responsible for them.

      • Everyone on the team is aware of what everyone else is working on and are willing to assist when needed, even when not asked.
      • Refusing to help others is not an option.

Team Lead and Architect Roles may be Designated, but Delivery is EVERYONE’s Responsibility

Leadership roles, such as Architect or Team Lead, are necessary and important.

    • These roles involve responsibilities that require certain skills and don’t make sense for the whole team to do.
    • They do not denote seniority over other team members.

The whole team works together to keep the project
on track.

      • There is a collective focus in the room on the overall delivery objective – success is a team objective; it is not the responsibility of one or two individuals.

Everyone is Engaged & Respected

In a dynamic Agile room, everyone:

  • is an equal,
  • listens,
  • is heard, and
  • participates.

There is no:

  • avoiding the team or
  • disrespectful behaviour.

There are no heroes

Healthy Debate and Conflict

Debate and conflict are normal.

    • Debate, arguments, and conflicts happen often in the room.
    • Facilitated by the fact that everyone feels free to speak up and that their opinions will be respected.
    • The focus is on the good of the project and maximizing value to the customer.
    • Personal attacks are not tolerated in any way whatsoever

Whiteboard Sessions

  • Whiteboards are an important feature of the room used to communicate design diagrams, task lists, etc.
  • Whiteboards are used as a common focal point for design discussions, tasking meetings, etc.
  • Everyone is allowed to participate in these discussions, at their own discretion.
  • Closely related to healthy debate.
  • No whiteboard in the room is left blank!

Members Help Each Other

A stuck developer is an unproductive developer.

  • Nobody is afraid to ask for help from other team members.
  • Assistance is offered without question.

Collective sense in the room that helping each other is critical. Works in two ways:

  • If we help each other, the team will benefit.
  • I may need you to help me one day.

Standup is a common mechanism to point out difficulties and ask for help.

Team Members Have Confidence in each Others’ Abilities

Everyone on the team is aware of and respects their own and other team member’s abilities.

  • Varying skill sets and levels of proficiency are known and appreciated – not everyone is a rocket scientist.
  • Team members don’t sign up for tasks that they’re not capable of completing.
  • Likewise, when team members take on a task, this decision is respected by other team members.

The team accepts that delivery relies on a team with diversified skills and levels of experience.

No Egos

  1. No cowboy programmers.
  2. No ‘last minute’ heroes.
  3. Yes Servant Leaders.

Buzz In The Room

The project room immediately appears to be a hive of activity.

    • Everyone is busy and engaged.
    • The team is located around a central table.
      • No outliers.

There’s lots of talking:

      • Pairs working together.
      • Ad hoc discussions.
      • Whiteboard sessions.

Whiteboards are covered with stuff.

It’s not exactly neat and clean.

Celebrations of Small Successes

In Agile, a successful project is not one event but instead is the cumulative effect of a series of small successes.

Agile teams recognize this and celebrate small successes often by:

    • Showing appreciation for other team member’s efforts.
    • Going out to lunch together.
    • Bringing food or drinks into the project room at the end of the day.

Music

Music can often be heard in an Agile team room because…

Developers enjoy listening to music while they work.

  • The atmosphere is relaxed.
  • Everyone gets a chance to play what they like.
  • Nobody criticizes other’s musical preferences (within reason  ).
  • It’s not too loud.

No headphones!

  • This is a sign of somebody who’s not fully engaged with the team.

How to Maintain Healthy Project Room Dynamics

These are the things that Agile Teams implement to maintain healthy project room dynamics:

    1. Group negotiation of team rules.
    2. Team lunches.
    3. Storming as a given.
    4. Pairing negotiation.
    5. Always listen in.
    6. Conflict amongst team members.
    7. Decisions.
    8. Engage the larger development team.
    9. Incorporating new team members.
    10. Humour & Food.

Group Negotiation of Team Rules Guidelines

  1. Collective confirmation regarding:
    •  Stand-up.
    • Story writing structure on the board.
    • Scrum board.
    • Bug tracking and wiki usage (e.g. Jira & Confluence).
    • Retrospectives.
  2. Guidelines can always be changed as the team settles in. Usually done as a result of end-of-sprint retrospectives.
  3. First order of business: Team Lunch!

Team Lunches

  1. Scheduled in calendar in a repeating cycle (~ 3-4 weeks).
    • 1st team lunch.
    • Team building activities to break the ice.
  2. Initiated by any member of the team.
  3. Important that whole team attends!!!!!
  4. Takes about 3 lunches for team to warm-up to each other.
  5. Discuss 5 Stages of Team Development

Storming as a Given…The 5 Stages of Team Development

  1.  Forming
    • Little agreement, lack of purpose.
  2. Storming
    • Conflict, power struggles, increased clarity of purpose.
  3. Norming
    • Agreement, clear roles & responsibilities.
  4. Performing
    • Clear vision and purpose; focused on common goal.
  5. Adjourning
    • Project/task complete; hopefully with good feelings about outcome.

What Happens if the Team Changes

  1. Why might the team change?
  2. New team formed for new project.
  3. Maternity leave.
  4. Somebody leaves the company.
  5. New hire added to supplement the team.
  6. Somebody is added that has a specific skill set.
  7. Team members moved between teams to cross-pollinate skills and practices.

You Are Expected to Storm

  1. Must be verbalized by the Team Lead, Project Manager or team coach to ensure team has common expectations.
  2. Introduce concept at first team lunch.
  3. Allows team members to disagree passionately (and even get annoyed with each other) and know that it is an expected part of growing pains.
  4. Early retrospectives review where we think we are on the 5 steps of team formation.
  5. The whole team storms, some are more noticeable than others.

Pairing Negotiation

  1. Discuss briefly how you like to pair.
    • Want pair to point out typos or mistakes immediately?
    • Drive for several hours and switch?
  2. What are habits you have (or not aware of that have been pointed out to you in the past)?
  3. What are your normal work hours?
  4. Give pair permission to speak-up or stop you if you are doing something they don’t like.
  5. This is especially important at the beginning of project for all “new pairs.”
    • Additional reading: Pair Programming Illuminated by Williams & Kessler.

Always Listen In

  1. Pay attention to discussions going on in the room!
    • It takes a village!
    • At the end of the day, it’s EVERYONE’S fault if something goes wrong (especially
      true if a new or junior member caused it).
  2. Tune in and out of conversations around you.
    • Saves time when you have to switch pairs or a task.
  3. Do as much pairing as possible and practical.
    • Ideally identify tasks that should be paired on during tasking.
  4. Verbally communicate code changes that may impact others as soon as it’s pushed.
  5. Headphones? Seriously??

Conflict Amongst Team Members – Know the Personality Types

  1. Not easy initially, but team building helps.
  2. Kindergarten rules.
  3. Always give an opt-out option and if not possible – the lesser of two evils.
  4. Include everyone in their own way.
  5. Don’t allow others to be interrupted by stronger personalities in a discussion.
  6. Pay attention to non-verbal cues & ask follow-up questions.

Myers Briggs Personality Test

  1. Based on the theory of psychological types.
  2. Rational (judging) – thinking & feeling.
    • Irrational (perceiving) – sensation & intuition.
  3. Knowing your personality type and the types on your team will help you better interact with them.
  4. Online Myers Briggs Test:

Myers Briggs Personality Test

Conflict Amongst Team Members – Storming

    • Let people storm, but monitor that they move beyond that stage.
      • If two people are storming, let them work it out.
    • Don’t enable avoidance, just to be “nice”.
      • Don’t allow team members to avoid each other via not pairing when they could or should be.
    • Pay attention to non-verbal cues.
      • Folded arms.
      • Raised eyebrows.
      • High pitched voice.
    • Be aware of the differences among:
      • Difference of technical opinion vs.
      • Personality conflict vs.
      • Personal styles.

Conflict Amongst Team Members – Storming

Let people storm, but monitor that they move beyond that stage.

    • If two people are storming, let them work it out.

Don’t enable avoidance, just to be “nice”.

Don’t allow team members to avoid each other via not pairing when they could or should be.

Pay attention to non-verbal cues.

    • Folded arms.
    • Raised eyebrows.
    • High pitched voice.

Be aware of the differences among:

    • Difference of technical opinion vs.
    • Personality conflict vs.
    • Personal styles.

Conflict Amongst Team Members – Intervening

Only step in when it becomes unhealthy/uncomfortable for the team and absolutely necessary.

    • If you must intervene, discuss with them separately & privately and provide and objective
      point of view, then arrange a mediation if absolutely necessary.

Anyone on the team can step in.

Come to consensus and then be consistent. Don’t agree to disagree and then implement multiple flavours of the same solution.

Decisions

The team is responsible for delivery, but technical decisions are not the responsibility of the whole team…

    • Some members of the team, such as PMs, BAs and QAs, do
      not have the skills, experience and background to be involved
      in these decisions.
    • Larger final decisions that have impact on overall architecture are usually arrived at as a result of discussion of one or two senior team members. These decisions are then communicated to the rest of the team to seek consensus.
    • Day-to-day technical decisions are made by the team consistent with the shared technical direction.
    • If options impact scope, budget or future feature options, PM and/or BA present to Client for the final call if necessary.

Engage the Larger Development Team

It takes the development village.

Interact with other co-workers beyond your team during your project’s lifetime.

Don’t spin wheels too long.

  • Ask around if stuck. Your company’s knowledge isn’t limited to your project room.
  • Know and engage your options before spending 2 to 3 days on a problem .
  • Document and share answer!
  • By asking around, people you talked to will remember next time they encounter a similar problem.

Incorporating New Team Members – Make New Members Feel Welcome

When the team is disrupted, storming is expected again in addition to the other 4 stages.

    • Good time for team lunch.

New team members are responsible for asking questions partly to learn and partly to challenge the status-quo. They are by definition “fresh eyes”.

    • This is an opportunity to learn where team’s process and documentation is lacking.

Existing team members should be confident in the existing decisions that were made by the team.

New Team Member – Make Yourself Fit In

Accept that you represent a disrupting force.

    • The team will storm. Don’t take it personally.

Don’t be afraid to ask questions.

      • But respect history.
      • Previous decisions may seem insane, but they were probably made for reasons that made perfect sense at the time.

Go out of your way to fit in with your new team mates.

    • It’s okay to rock the boat…but don’t tip it over!

How to Make a Team Happy

  • Humour & Food
  • Food & Humour
  • Humour & Food
  • Food & Humour
  • Did I mention Humour?……..
  • What about Food?