As a software developer for 6 years, I’ve had a range of experiences with different teams, from negative to positive.
One of the best experiences I had was in a certain project team at a financial organization.
There were a number of factors that made the project successful, but I think the team structure was a key aspect of it.
To summarize:
-
We had developers who specialized in different aspects. 2 developers who were good at UI and 2-3 developers who were good at writing business logic and database interfacing code.
-
The code was strictly divided into Presentation, Business and Data layers.
-
Every developer had a basic knowledge of the whole system. Even if they weren’t experts in everything, they had a general idea of how everything hung together and could write code in any layer if necessary.
-
Some tasks involved the developer in a whole vertical slice of functionality (involving work on all layers).
-
Other tasks involved just the area of the application that the developer specialized in (e.g. just a UI task, or just a database task).
I think this worked well because:
-
Developers were able to learn the whole system, and jump into a different layer if necessary.
-
Developers retained specialization, and if a developer needed help with something they weren’t familiar with, there was always a go-to person.
-
The architecture was rigid, but the people were flexible, as they should be.
Is there a formal term for this kind of team structure? Does it sound like an Agile/SCRUM arrangement?
(It didn’t seem entirely planned at the time.)
Any thoughts?
I don’t think there is a formal name for that kind of team – other than sensible ! 🙂 To this end I certainly agree with Robert Harvey.
Every solution will (usually) cover general areas such as UI, BL, Data; you’ll also usually cover cross-cutting concerns like logging, deployment packaging, etc; and all of this will be using certain technologies. So, for a team to be appropriate for the project it will need to cover all of those things well – as a start.
That’s the “horizontal”view taken care of, the vertical view (implementing slices of functionality) is where those people need to interact – and that’s where XP practices like peer-programming come in, and where cross-training can really start to happen.
As a contrast to this, you might be interested by the “Surgical Team” approach, as outlined by Frederick Brooks in his famous book “The Mythical Man-Month“.
There’s also a link on that page to “Organization and Team Patterns“, which might be of interest.