Here is an infographic on “what is a team?”. I created it to help explain the concept in an upcoming workshop. Now I think it will be part of my basic Agile training.
- Shared Purpose or Goal
- Team Boundary – who is part of team and who is not.
- Shared responsibility to achieve the goal
- Shared work and shared results
- Maybe 5 or maximum 8 people on the team.
This was inspired by the discussion of a team at Value, Quality, Flow. They drawn on lot’s of influences, so hard to list them all here.
Lyssa Adkins ran a very practical session at DeepAgile that shared several tools for team formation or for tuning up existing teams. She often uses these right at the project start since team members may know very little about one another – even if they have been working together for years. Here is a run-through of three of the exercises.
Constellation – Understanding each other through motion
I love this exercise. It provides the team members as well as the coach important information about everyone on the team. It is called constellation since everyone arranges themselves around an object on the floor (in our case a roll of tape) depending how they feel about a statement such as “I like getting results”. People align their bodies with the statement: standing beside the object signifies strong agreement while standing far away to signifies strong disagreement. It is very powerful since people are engaging their whole bodies.
Journeyline – sharing our pasts
In Journeyline, each participant draws a timeline of their life with peaks, valleys and major life events. In turn, each person describes their Journeyline to the team. Team members listen and note skills or talents (on sticky notes) that stand out. These are then posted at the bottom of the Journeyline and reviewed as a team. This approach is about figuring out who the person is and what special perspectives they bring to move the project forward. When we did this, it helped the demo subject feel more positive about their talents. Nice.
Marketplace – sharing our talents
In marketplace we pretend we are a vendor in an open-air market place and decide what wares we have to sell. What are our special skills and talents that pertain to this project? We even get to create a banner to attract people. Under the table are things that are true for us, but may not directly relate to the project. The debrief is the same as Journeyline. Usually a coach will use one or the other (in the training session half of us did marketplace and half did Journeyine).
Below is my marketplace as an Agile coach.
(This is part of a series on DeepAgile 2010 Games Weekend).
Part of my standard training for Product Owners is to help them understand how they relate to everyone else in an Agile/Scrum world. Hence the drawing below.
Project Community Diagram
The Product Owner is not part of the team since their role is to ask for more to keep productive tension in the system. I like the way Ron Jeffries narrates about the Product Owner Role without ever using the term. This is a good story. So is the follow-up one.
I like the XP notion of the customer team to reflect the group representing the customers interests. (If anyone can suggest a good link/definition, I’ll add it.)
Why is the ScrumMaster outside? Their primary role is to act outside of the system to help it function and grow. Why is the ScrumMaster cheering on top? Ooops. That’s a bug. If I had time to re-draw, I’d put them underneath holding up the whole system as a servant leader.
So what do you do, if you don’t like the way I have parsed the world? Please help me understand your perspective – draw a picture to show me the world through your eyes.
Simon Roberts and Jens Korte gave a solid presentation of the how and why of team chartering. The process as they define it leads to team agreements so that there is a container for allowing the team to self-organize. The full presentation in prezi style is here.
The importance of team agreements was recently reinforced in Jean Tabaka’s post on 78 Things I Have Learned in 6 Years of Agile Coaching (which is a great post).
(Part 3 of 5 blogs on the Scrum Gathering in Orlando)
Perhaps the most important point is that the working agreements need to come from the team and not managers or coaches. This can be tricky in the early stages of adoption where more leadership is needed.
Also of note is establishing team norms of how team members want to work and communicate together.