The power of positivity.

This post was originally published on my old blog: Spike the Poodle

I learned an important lesson this week about how powerful it is when people are outwardly positive about the project and work they are doing.

Having worked on projects in the past where the team were frustrated and had a tendency to demonstrate that quite vocally – something which I am definitely guilty of doing – at first, I really noticed the positive comments that were quite regular in our daily stand-ups:

"I had a really great meeting about how that system works …"
"The developers got together and now we all feel really good about building the new widget …"
"The BA produced some great diagrams that made the requirements much clearer …"

Every time it happens, it's a little boost to the team members, and helps keep up the motivation of the team in general. I particularly remember a comment about my diagrams, and it made me feel good :)

It wasn't until it was pointed out to me this week by somebody on my team that I realised I wasn't really contributing to the positivity myself though. People do notice – and in ThoughtWorks, they will tell you too!

So my resolution for next week is to try and say something positive and complimentary at least twice a day (n.b. "nice haircut" does not count). Try it – it's easier than you think!

A nice touch.

This post was originally published on my old blog: Spike the Poodle

On the storyboard for my current project, the project manager has pinned up photos of all of the team members. Each team member's picture is stuck on to the story they're working on, and there's a space for people who are on holidays. I'm not sure how common this is at ThoughtWorks – given that this is my first project :) – but this is something I'd not seen on projects before.

I think it's cool, and it's useful too. It's helped me remember who's who, having joined the project halfway through, and it's easy to see who's doing what (instead of initials). It made me feel like a real part of the team when my photo was added.

Sometimes the little things can really make a difference :)

Forming, Storming, Norming, Performing

During Agile 2006, one of the presenters (unfortunately I forget who!) mentioned the “forming-storming-norming-performing (adjourning)” model of team development. I recently found a good powerpoint by Glen Alleman on this subject that describes the stages and their characteristics. Since a number of people were interested at the conference, I thought it would be useful to post the link here.

Glen Alleman – Forming-Storming-Norming-Performing

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.