Agile 2006: Team Dynamics – Esther Derby

Monday 15:30-16:15

Abstract

Only 5% of teams ever reach the “high performing” stage – but being aware of how teams form and what practices are needed can help to increase the chance of becoming a true high performing team.

Summary

It takes social engineering to make great teams – it doesn’t happen by accident. Good teams that people have worked on tend to be small, passionate, and focused on one common goal.

In teams with more than ten people, communication overhead grows, and teams tend not to perform as well. Good teams usually have an agreed-upon approach to the work – XP has specific practices that promote this – pair programming, refactoring, coding standards, and so on.

Teams should be made up of people with complementary skills – not the same skills, although there should be some overlap. Good teams have interdependent interim goals – such as user stories – which mean they can be successful quickly. As is especially true of agile teams, they make commitments to each other and are not hierarchical.

Team creation goes through several stages (refer to the powerpoint for the diagram of the model):

Orientation: “why am I here?”
The team need to get clear on this first!

Trust building: “who are you and can I trust you?”
Mistrustful teams are guarded, hold back and are less creative. Trustful teams accept feedback and deal with conflict. They trust in each other’s professional competence, and that their intentions for the team are good. In teams with one star performer, trust for others is low, and they tend to be less productive.
Avoiding conflict erodes trust, by resolving issues people build trust.

Goal clarification: “what are we doing?”
When teams aren’t clear on this, they become apathetic, and irrelevant competition starts to happen.

Commitment: the team ask “how will we do it?”
If this is absent, the team will snipe at each other. People who don’t have power and control over what they commit to, don’t commit. Removing the fear, and allowing people to make small promises means they can commit to something realistic.

Implementation: in agile projects, this is done through stand-up meetings, retrospectives, reviews, and talking to customers.
High performance: at this stage, teams are having fun, and producing. Only around 5% of teams ever reach this stage.

Renewal: There are some critical skills necessary to achieve high performance. Teams must navigate conflict. Often people don’t hear each other properly, and conflict can be down to misunderstanding – in these cases it’s good to review the data. Peer-to-peer feedback – not just up and down – is necessary to build trust on high performing teams.

Agile 2006 – Introduction to Agile Project Management – Sanjiv Augustine

Sunday 15:30-16:15

Abstract

Agile project management is different to traditional project management, lean principles can be utilized to manage at the value stream level and reduce waste.

Summary

Agile teams are self organizing – team members have a clear set of responsibilities, and they have the control and power to fulfil them. Trust the team, and they will learn to self organize, it requires a shift in mindset.

Often in large organizations, much of the agile mindset is already happening at grass roots level. Agile adoption just makes it explicit.

It is important in agile project management to manage at the value stream level. This concept comes from lean software development and manufacturing principles. This is the job of the agile project manager.

In traditional waterfall project management, work was done in large batches: design, dev, test, rework – there is a lot of “inventory”. In contrast with agile, small pieces of work move more quickly through the system. In agile projects, the focus should be on project throughput. Reduce utilization – developers should work on only one project at a time, and focus on only one story to avoid the waste in switching tasks.

With more trust between customer and team, a lot of waste in the process is reduced through collaboration. With agile, requirements do not need to be bloated upfront since change is allowed – this lifts a load since corrections are easy and fast.

Reflections, or retrospectives, should be used in agile projects to analyze, adapt and improve processes and practices. The team should answer the questions: what’s going well, what can we improve, and what obstacles or issues are facing the team.

Key points

  • Manage at the value stream level.
  • Reduce utilization of developers – they should only work on one story at a time, one project at a time.
  • Reduce waste through collaboration, and investigate other techniques.