Cross-posted from Mathemagenic
First, a bit of the context: we are working on a project helping distributed Agile teams to identify challenges they have to deal with and to find solutions for them. Also, as much as I would like to make it a proper research project (with in-depth state-of-the-art review, large scale data collection and time to process all that), it is more of a research-based consulting: we observe a bit, interview some people, scratch the surface of what had been said on it and hope that our research backgrounds would help to fill in the gaps to come back with useful insights.
Second, a disclaimer: I’m not an expert on Agile software development, but have been learning about it in the past few months. And, while my research is pretty much about technology-mediated ways of working, research on distributed teams is not at the core of it. But all that shouldn’t prevent me from writing about it, isn’t it?
Now to the point. I’ll start from the values behind the Agile approach, as articulated in Manifesto for Agile Software Development:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Those values are supported by a set of principles and a variety of methods and practices that address those principles in practice. Now the part that is directly relevant to our case: while it’s not always immediately obvious, Agile methods are designed for a co-located team, articulated in one of the principles:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
From one side, this makes the whole exercise of figuring out how Agile can work in a distributed team pretty pointless: it’s not designed for it. From another, there are various reasons for distributed Agile teams and examples where they work (some links). So the question is not if distributed Agile is possible, but how to make it work.
For me it translates into the focus on understanding what is actually happening face-to-face and then figuring out what of it and how exactly can be supported in a distributed settings.
This is a simplified picture of what we have observed in our case. It is heavily based on Scrum as a main method, which could be described in terms of roles, ceremonies and artifacts. In a sense those are the known ingredients for the success, so a lot of effort goes into figuring out how they can work when the team is distributed. This involves, for example, finding tools and adjusting processes to support ceremonies (e.g. daily stand-up meetings) and figuring out how to share and update artifacts online.
However, next to those known ingredients there is a big black box: co-located team. Co-location and face-to-face interaction is one of the cornerstones of Agile, but from what I’ve seen there is not that much understanding of what exactly happens there. Which is fine when the team is co-located – we have evolved to make the best uses of face-to-face and don’t even have to think of what and how we do. But when the team gets distributed that lack of attention to the black box results in all kinds of challenges. And, given that Agile philosophy places so much value on informality, putting efforts into articulating and formalising the blackbox ingredients doesn’t get much momentum.
So, this is more or less what we are doing in the project: bringing research instruments to open the black box and then working together with the teams to figure out how to make it work in distributed settings.
[As you have probably guessed two previous posts are directly related to this one: Why sharing a team room might be not so good and What a coffee corner provides, how to call it and a research agenda. More to come
]
VN:F [1.9.1_1087]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.1_1087]