An agile team consists of everyone it takes to deliver value to the customer. The typical team consists of analysts, developers, and testers. Of course the team is not limited to these roles. The team could also include technical documenters, DBAs, or whoever else has a hand in creating value.
In traditional organizations, "team" is defined as a functional group. The development "team", the "testing" team, the "analyst" team, etc. This makes sense in a traditional, waterfall-ish environment.
In an agile, cross-functional environment, it is not helpful to define "teams" around functions. Okay, "maybe" its okay in a production support capacity, but that's still pushing it as there will still need to be cross-functional work with production support.
Teams have a common, unified goal. Functional "teams" do not. For example, a functional "team" that consists of a dozen Java programmers, with each programmer on a different project, can hardly be called a "team". They have no common goal, other than to adhere to the (hopefully) high development standards that have been put in place.
I propose that instead of calling these functional groups "teams", we call them communities. Here's a simple definition of community that I found on dictionary.com: "A group of people having common interests". The Java "community" will work together to make sure that they have common standards of excellence, share knowledge and experiences, and provide each other guidance as needed. However, these people will have different goals, depending on the project on which they have been assigned.
Monday, November 9, 2009
The Cross Functional Team vs. the Functional Community
Subscribe to:
Post Comments (Atom)
1 comment:
I really like your idea of using the word "community" instead of teams. I would also like to add a couple of observations. When programmers belong to one VP or a number of directors, and when QA testers belong to Shared Services VP and also divided into groups under different directors and so on (same for DBAs..etc), you get no real devotion to projects from these 'team' members. You are almost always fighting for their time and commitment because they are on different projects and ultimately their directors or VPs are the ones who decide if these individuals are doing good or not. I also think that directors and VPs in traditional organizational structures like to keep their staff in a cloud. It is very common for directors to say that their people are very busy and they have a long list of projects they are working on. So, go away. What I think is that a lot of directors are afraid of dedicated (real) teams because they think they will lose control and power once their staff are clearly working on a short list of projects at any time.
Post a Comment