In late 2008, we started a major transformation of our SAP NetWeaver development approach, processes and organization: We made a bold move with my 2000 people organization spread out into development labs world-wide to adopt Lean and Agile Software development methodologies in a systematic and consistent manner. The transformation was a major change effort and I have blogged about it on our SAP Community Network before (see my blog posts Square One, Good Riddance and Different people). Looking at where we stand today as an organization, our ability to deliver customer value, to deliver reliably, to adapt in an agile manner, to interact with customers and to innovate our product portfolio in a high quality manner, I consider this multi-year transformation a big success!
With the move to systematic, standard Scrum methodology within the organization, cross-functional teams moved into the focus of our interest. "Cross-functional team" meaning people across the necessary disciplines working closely together as "one team", namely software developers, software architects, information developers, UX designers, Scrum Masters and Product Owners to name the usual suspects. The great thing about these "cross-functional" teams is the ability to optimize the interaction between everybody that you need at the table to get the product done: efficiently and effectively. The more closely we can get this team to cooperate and interact, the better. They will share a better understanding of the overall goal of what they are trying to achieve, communication paths have been shortened as much as possible, diverse skills will increase the ability of the team to develop better ideas and approaches to the problem at hand, delivering more customer-centric results. All of this is also supported by the principles behind the Design Thinking methodology. And last but not least, once being "standardized" on Scrum approach, you can start training and developing complete teams in certain further skills, e.g. agile test practices, increasing likelihood to establish new software engineering practices in a sustainable manner.
Well functioning teams are a huge asset! While we sometimes like to see software developers as creative artists that can barely be forced into any constraint -- at least that's the romantic point of view that I myself tended to fall into when I was still developing software myself --, a fact is that almost all bigger software development projects are not done by a single individual but quickly by a number of people that somehow need to collaborate to get something relevant done. So the infamous "lonely guy behind a door" is something one does not necessarily see as the ideal working setup if you want to keep your customers happy and your business secured. Well functioning Scrum teams with predictable and transparent progress on the tasks at hand can be a big relief here.
Most of the time where I have seen teams to be dysfunctional or failing, have less been a general issue with working in cross-functional (Scrum) teams but rather could be attributed to the following:
1. Bad cut: The team did not work on a common problem, but was just a collection of people working on unrelated individual topics; sometimes "cutting" teams in a different way made this issue disappear
2. Bad chemistry: There were individuals in the team that did just not buy into the team as such; sometimes just assembling teams a bit different made this issue disappear
Very often I have been hearing discussions about the question whether teams have to be co-located, i.e. all team members being in the same physical location, or could -- or even should -- rather be distributed, e.g. across different locations or timezones.
I think either position -- when taken rigorously -- is somewhat shortsighted. Here's why I think so:
We form cross-functional Scrum teams to make the group internal communication and interaction as efficient and "personal" as possible and get diverse skills to the table. Of course there are modern means of communication like phone, instant messaging/chat, Skype, telepresence etc. that have made the physical distance less of a problem. Still, if you imagine that a team sits in the same office physically and makes use of these communication means mentioned, you would ask yourself whether it wouldn't be more efficient to just ask the question across the table or listen in on some side-discussion going on spontaneously on the whiteboard behind at the wall? Would be strange, wouldn't it? So while it is not impossible to work together even when distributed, it is probably more efficient to be co-located. At least in most cases.
At the same time, there are good reasons to accept or even actively establish a "distributed" team: e.g. if your product manager needs to be local to your customers in a certain region or a certain market. Or if there is specific or outstanding talent that you did not find "locally" but had to look for abroad. And this was considered more valuable than the potential loss in optimal communication efficiency associated with it.
So I think the important thing here is: there may be very good and valid reasons to accept that a team is distributed, but those reasons should be well considered and consciously decided. Not arbitrary "accidents". And they must for good reason outweigh the benefits of co-location.
Rules should cover the common sense 80% case. Exceptions always apply.
- SAP Managed Tags:
