» Scrum Teams
In my previous article, I argued that using a distributed team with the Scrum Framework was a bad idea and advised against it. There is sufficient information to show that distributed Scrum teams perform poorly compared to those that are co-located. However, everyone does it anyway! As Jeff Patton once said, “if you want to run a marathon with ankle weights, don't complain to me about your time!”
Recent studies show that 3 out of 4 Scrum Software Development Teams are distributed, meaning that at least some of the team members are not in the same location. Co-location is one of 12 factors that can contribute to or detract from high-performing teams. This article explores the 12 factors that contribute to high performance when using the Scrum Framework, and then explores how distribution affects those factors.
Last month I wrote about bad Scrum and other abuse of the Scrum Framework. One of the common abuses that I see in organizations using Scrum is that they don't properly use the 3 Scrum roles. To be effective, these three Scrum roles need to be implemented properly and protected. Like bowlers in a bowling alley, we need each of the roles to stay in their lane.
A few months ago I had a conversation with a development manager whose teams had transitioned to Scrum earlier in the year. The development manager said he was really happy with the transition to Scrum and how productive, transparent and collaborative the teams had become. Then almost as an afterthought, he mentioned another benefit of Agile Transformation that excited me.
One question that I get frequently from leaders during Agile training is about how to make sure everyone is busy. How do we make sure that we are getting the most out of every person? They have a seemingly perverse focus on individual efficiency rather than on team effectiveness and throughput. Rather than focusing on creating an environment for high performing teams, they try to make sure that everyone is busy all the time. This is another form of local optimization.
I work with a lot of teams and help them to adopt Agile thinking and methods. While I am pretty passionate about Agile and many of the team members are as well, I work with many team members who are afraid of Agile. Why would people fear Agile if it is such a great thing? Perhaps it isn't viewed as such a great thing by everyone. Here are some reasons why they might fear agile, Scrum and the idea of 'going Agile'.
People don't use the pigs and chicken metaphor in the Scrum Framework much anymore. I tend to agree with the reasons for avoiding it - it tends to create an Us vs. Them mentality.
Us is the Scrum Team, or the pigs. The "committed" individuals who are responsible for delivering the solution. "Them" is anyone else - the chickens. The chickens are only involved and not committed like the pigs.
I've been an advocate for co-located teams for quite some time. However, I seem to be in the minority when pushing for co-location. Am I crazy for thinking that if we put people together, we will get better results? Am I the only one who believes that co-location is an essential ingredient to high performing teams?