{"id":733,"date":"2018-12-18T18:20:50","date_gmt":"2018-12-18T16:20:50","guid":{"rendered":"https:\/\/www.doelenconsultancy.nl\/?p=733"},"modified":"2020-11-14T21:11:08","modified_gmt":"2020-11-14T19:11:08","slug":"team-enabling-conditions-real-team","status":"publish","type":"post","link":"https:\/\/www.doelenconsultancy.nl\/en\/team-enabling-conditions-real-team\/","title":{"rendered":"Team enabling conditions: Real team?"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Is a team a real team? This question might be silly to ask but coaching non-IT teams makes this very relevant. A real team is bounded, is interdependent of each other and is relatively stable. A team is bounded when it is clear who is member or not. In scrum teams this is defined: a scrum team consists of the development team, product owner and scrum master. The pig and chicken rule in a daily scrum makes this explicit. The guys who have a stake do the talking the rest is silent. In non-IT teams the design of the team is not that clear.<\/p>\n

A team is interdependent when you need to work together to deliver the results. Sometimes so called team can be in fact a co-acting team: Team members are not depending on each other to deliver the outcome. Richard Hackman introduced this team typology and I found it very interesting in use.<\/p>\n

\"\"<\/p>\n

In some non- IT teams I saw co-acting teams can have very dull daily scrums. Team members just share their update and simply don\u2019t listen to the other. I notice even Scrum Teams can be co-acting teams when team members think they are only responsible for performing their task and hand a story over to the tester. In business intelligence teams this can be dominant when the Data Warehouse Developers don\u2019t connect to the reporting developers.<\/p>\n

A team has a reasonable stability of membership when it is in the same composition for at least a quarter. Research from Hackman and Rally (Now CA Agile<\/a>) indicated stability has a significant impact on performance. The longer members stay together as an intact group, the better they do. As unreasonable as this may seem, the research evidence is unambiguous. Whether it is a basketball team or a string quartet, teams that stay together longer play together better. Consider crews flying commercial airplanes. The National Transportation Safety Board found that 73% of the incidents in its database occurred on a crew\u2019s first day of flying together, before people had the chance to learn through experience how best to operate as a team \u2014 and 44% of those took place on a crew\u2019s very first flight. Also, a NASA study found that fatigued crews who had a history of working together made about half as many errors as crews composed of rested pilots who had not flown together before (1)<\/em>.<\/p>\n

The 2014 study from Rally (2)<\/em> stabile teams are on average 60 % more productive. Teams with 95 % dedication or more where 2:1 more productive then teams who were 50% or less dedicated. This is in line with lean studies on research sharing. Rally measured also predictability and responsiveness. Stable teams score 40% better predictability and 60 % on responsiveness.<\/p>\n

Creating a real team<\/strong><\/p>\n

Even with Scrum Teams creating clarity on who is part of the team and not can be necessary. In some cases Team Managers or Project Manager find it difficult to define their new role. Giving clarity will enable the team.<\/p>\n

The team typology helps a team to learn if they are interdependent. Simply asking them if their team is a basketball team or a bowling team gives a good indication. By actively coaching a team to pick up activities where they are depending on \u2014 each other can help in creating a a real team.<\/p>\n

Maintaining team stability can be challenging. Managers can have a tendency to pull a resource out of a team to fix a burning issue. Others might just throw more bodies into the team to make up for a delay. All pattern\u2019s that impact team stability. Just by showing the statistics on team stability or by collecting this can help. In one case I was responsible for 16 teams and management was not happy with the productivity. I simply showed the stats: 50 % of the staff was added or replaced during 12 weeks. This is not enabling a stable team and improving productivity.<\/p>\n

In another case I used cell division model to grow and split teams and create 4 teams. After the first split I quickly changed the strategy. The team would not bond because they knew they would be split up later.<\/p>\n

Creating a team canvas (3)can help creating a real team bij defining the People and Roles area.<\/p>\n

\n
\n
\n
\n
\n
 <\/div>\n

\"Image<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/figure>\n

In the next article I will focus on Team enabling condition 2: a compelling purpose.<\/p>\n

\n<\/p>

(1) Collaborative Intelligence \u2014 Using Teams to Solve Hard Problems, J. Richard Hackman, 2011.<\/em><\/p>\n

(2) The Impact of Lean and Agile Quantified: 2014.<\/em><\/p>\n

(3) Team Canvas : <\/em>http:\/\/theteamcanvas.com\/about\/<\/a><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\tContact<\/span>\n\t\t\t\t\t<\/span>\n\t\t\t\t\t<\/a>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t