I just finished attending an excellent Certified ScrumMaster training course by Mike Cohn. I knew most of the material already but it was an excellent refresher course and it was also great to hear Mike’s experience and opinion on several topics, not to mention that of the other students.
When Mike covered the topic of using cross-functional or feature-oriented teams, rather than component-oriented teams, one fairly predictable question came up. ”But how do you ensure that what team X does is compatible with what team Y does?” I know I’ve heard this question before, usually from someone who is an architect, DBA, or in a similar role. For instance, if you have one DBA on each of three teams, how can you then prevent the database designs from wildly diverging? This is particularly a concern in large enterprises where many applications will share some architectural component, such as a database, or exposing a public API.
Of course there is a good answer to this question, which is to organize communities of practice. It’s helpful that there is a name to this practice, and I’m glad that it’s included in the Scrum training.
But what I found interesting is that the question was asked at all. The answer seemed obvious to me. If you have some architectural component that is shared by many teams, why wouldn’t the interested parties simply talk to each other? Why wouldn’t it occur to people to talk about what they’re doing with others who are doing similar things? It just seems natural that the testers would get together and chat about their various test automation tools and maybe (hopefully) agree on one to use across teams. It seems like the programmers would just naturally get together across teams and chat about what the public API is going to look like.
It’s almost as though when you draw boxes around a group of names and call it an “org chart” we see those boxes as big walls, which you aren’t supposed to go outside of. What kind of bizarre behavior is that?
A good development practice – whether it’s termed agile or not – ought to be a way to help you do your work, not to limit you. Having a cross functional team, daily standups, and user stories, doesn’t mean that’s all the communication you are allowed to have. These are not limits.
Make friends. Put information on a wiki. Send out broadcast email. Organize informal meetings. Talk amongst yourselves. It’s really OK.