Agile Checklist Part 4
Another important aspect of agile projects are the feature or scrum teams. It's very easy to define teams that belong together from an organisational point of view. That's ok if the members are those involved in the components affected by the feature to be developed. Often though, code is structured similarly to a components organisation (seriously!), and features span several components and thus several organisational units. And often misunderstandings occur between these units, because there is less communication across units than within them.
Therefore it is important to build teams involving all the units affected by a feature.
For example, say software is required to handle a new communication protocol which enables a new sort of application, i.e. a protocol layer, some sort of an abstraction layer, and an application need to be developed. The communication experts are in one department, the application people in another, maybe there are even architecure, and test departments. Even though it might be useful to form a team in the communication department that discusses/decides how best to implement the new protocol, its far more important to form a team containing those people from each of these departments that have been committed to design/implement/test the code for the feature, even (and especially) if these people don't know each other and work in different locations!
This may sound obvious but it is difficult to manage and therefore not always practised.
Feature or scrum teams need to communicate intensively, usually on a daily basis, and getting everyone together regularly (at least for the kickoff and integration phases of a sprint) avoids the sort of misunderstandings that often occur across component interfaces.
Also ensure that the team kicks off together, avoiding the situation where people are being phased in and added to the team as development proceeds. Otherwise there are continually disruptions getting people up to speed.
Another important aspect of agile projects are the feature or scrum teams. It's very easy to define teams that belong together from an organisational point of view. That's ok if the members are those involved in the components affected by the feature to be developed. Often though, code is structured similarly to a components organisation (seriously!), and features span several components and thus several organisational units. And often misunderstandings occur between these units, because there is less communication across units than within them.
Therefore it is important to build teams involving all the units affected by a feature.
For example, say software is required to handle a new communication protocol which enables a new sort of application, i.e. a protocol layer, some sort of an abstraction layer, and an application need to be developed. The communication experts are in one department, the application people in another, maybe there are even architecure, and test departments. Even though it might be useful to form a team in the communication department that discusses/decides how best to implement the new protocol, its far more important to form a team containing those people from each of these departments that have been committed to design/implement/test the code for the feature, even (and especially) if these people don't know each other and work in different locations!
This may sound obvious but it is difficult to manage and therefore not always practised.
Feature or scrum teams need to communicate intensively, usually on a daily basis, and getting everyone together regularly (at least for the kickoff and integration phases of a sprint) avoids the sort of misunderstandings that often occur across component interfaces.
Also ensure that the team kicks off together, avoiding the situation where people are being phased in and added to the team as development proceeds. Otherwise there are continually disruptions getting people up to speed.
posted by Stephan at 12:31 PM
0 comments
