Feeds:
Posts
Comments

Archive for April, 2017

Why The Who Matters Less

Theory of the perfect team

Google is known for being obsessed with studying their own performance and then adjust accordingly. At one time Larry Page decided to get rid of all the middle management but then quickly realized that the increased amount of direct reports slowed the company down immediately. So, they brought them back. With its Aristotle project Google wanted to figure out what are great teams made of. At the beginning, they focused all on the individual skills of the team members and their performance but the results were sobering. Having all superstars on the team did not necessarily made a great team. After hundreds of teams studied, a pattern emerged. In all the high performing teams the members felt psychological safety. That means they were not scared to admit an error and talk about their ideas. Furthermore, these teams had all empathy for each other (social sensitivity) and equal voices, which mean that everybody’s opinion is heard when a decision must be made. This does not mean democracy, still somebody can make the decision but people feel that their opinion is considered. For our Scrum teams that means, it is more a cultural challenge rather than a skill challenge and the culture should incorporate those values:

  • Psychological safety
  • Social sensitivity
  • Equal voices

A popular thought for hiring a new employee regarding this: Hire for fit not for skill.

Multifunctional teams

A frequent question I get is: Does multi-functional team mean everybody on the team has to be an expert in everything? This is probably due to 2 facts:

  • We want the team to be independent with a few dependencies as possible to the outside. Therefore, we need all skills inside the team.
  • We advertise that there are no more specialists rather everybody has to be able to help out with other tasks.

Now if there is for example a data base expert on the team, it does make sense that he helps with the database issues but if he has idle time he should help out other team members. On the other hand, when there are a lot of database related tasks and he becomes the bottle neck others should be able to help him out as well.

The approach of A-teams (small engagement units) from the Special Forces is this: Each team member is cross trained. That means he is usually an expert in 1 or 2 specialties e.g. medic, radio, etc. but is also able to do general tasks in other areas. They have what is called T shaped people, a person that is expert in 1 or 2 areas but has general knowledge about all the other topics. Furthermore, every specialty exists twice (in case you lose the medic, there is still another one).

How can we apply that to our Scrum teams? First, it is important that all necessary skills are on the team to be independent. Then, we want every expertise twice, for example 2 persons with highly developed database skills. But we want also T-shaped people that can work on other parts as well (not only their expertise).

Bringing it all together

In sum, it is not so important to have superstars on the team rather than how the team is operating. The number one indicator is psychological safety followed by social sensitivity and equal voices. Secondly, culture has a huge impact on team performance. Even though, culture is probably the most difficult thing to change, moving to a commitment culture is one the most performance improving steps. Lastly, when it comes to who is on the team it is important to have T-shaped people that do have the necessary skills to work independent from the outside. However, they do not have to be superstars.

Takeaways

  • Define team ground rules that lead to psychological safety, social sensitivity and equal voices.
  • Implement a commitment culture.
  • Create a team of T-shaped people covering the necessary skills.

Read Full Post »

Organize Agile Team

We always feel like our teams could be organized better. How to organize teams in an optimal way is a common question in Agile organizations. A question we should always discuss and answer together with the people in the actual teams.

Here I will try to provide an overview of 5 possibilities for organizing teams and the main factors to take into account. Our main considerations should be based on product complexity and maturity, as well responsibility, coordination efforts and sustainability. Depending on our specific context one will suit our situation better than the other, or maybe we will come to the conclusion that we are so Agile we can leave the concept of team all together.

Component based teams: Component based teams focus on specific components in the product that do not deliver customer value in it. They are also sometimes called focus teams for that reason. The focus is usually necessary because of the use of very specific or exotic techniques. Learning the skills and expertise to work in these teams takes years so it is more logical to put experts together. We can compare this kind of teams with functionally specialized teams.

Feature based teams: Feature based teams focus on a specific customer feature or feature areas within a product. For example: search optimization in a web-shop, or payments and conversion. Feature teams are necessary if the product is too large for a single team to optimize or when a single larger base product is differentiated into various market segments in retrospect. For instance, the same web-shop product can be differentiated for selling kitchen appliances, or tailored for selling TV sets.

Product based teams: Product teams carry responsibility for the entire product or product/market combination. This means all of the skills and expertise necessary to develop and run the product reside within the team. Product teams are therefore suited for smaller products with a relatively small feature set. That is why we often see these types of teams in start-up settings. When developing our new product, we do not want it to be complex and we will have a limited feature set if not a single one we want to validate first. Once the product matures, team orientation eventually changes towards feature teams to excel in feature performance and fulfilling customer needs.

Other factors to take into account: There are a number of other things to take into account when discussing team organization with the teams. These are: responsibility, coordination and sustainability.

Responsibility does not decrease or increase given we work on a component or product as a whole. The person working on the component probably wants to do a good job just as well as the person working on ordering functionality. But the thing is, it is just easier to feel responsible for an end-result. The other question is, if we only have component teams, who feels responsible for the end-result?

Coordination is also something to take into account. The need for coordination increases from product towards component teams. Just think about all the planning, hand-overs and dependencies before a group of component teams manages to deliver the final product.

The final thing is sustainability. What if technology becomes end-of -life? Are we going to fire the entire component team? Do we want to split them up over other teams? Could they adopt a totally new technology, and would not this undermine the whole reason for forming the component team in the first place? Technological advance is moving faster than ever. We know that new tech will come and go so better stay as flexible as possible.

One good conclusion so far can thus be to avoid component teams as much as possible and move from product to feature teams when product scope and/or maturity increase.

Customer journey teams: Customer journeys are becoming more and more important in differentiating our digital product or services from the competition. It is not just the core product that matters, but more and more how customers can experience added value from that digital offering; from problem recognition, to orientation, to acquiring, to aftercare, to discarding or switching to a new offering. Teams aimed towards optimizing the customer journey, can therefore be very effective. Pretty much the same goes for a customer journey teams than for product teams though; if complexity increases we can have multiple teams, but eventually we will need team specialized in certain parts of the journey, specific actors, or channels to differentiate further.

No teams: But wait, there is more! Yes, people, because real Agility would be to self-organize in shapes and forms that simply work. Should not we let go of the whole concept of “team”? Should not we trust people to form groups that just tackle the challenges at hand, no matter what form or shape? Like a swarm of bees or a flock of birds. I sure hope to see this sometime! I would expect to see it in an organization operating in a highly volatile and competitive market where constant change is necessary to keep up.

To recap, our main considerations should be based on product complexity and maturity, as well responsibility, coordination efforts and sustainability. Do we want to push the boundary towards customer journey teams or maybe even dare to let go of teams? Whatever we decide, we should decide it together.

Read Full Post »