Abstract
Development teams are organized to
In this lesson, we look at some of these issues and at some common organizations that have been considered to deal with these.
Major issues in organizing a development team are
Communication
maximize communication within the team
establish responsive communication points with stakeholders
Staffing
does the team contain all the skill sets reuqired to complete the work?
Productivity
are we making effective use of our team members’ skills?
There are two key aspects here
Brook’s law is well-known truism of software development:
"Adding manpower to a late software project makes it later. – Fred Brooks, _The Mythical Man-Month, 1975
Why?
Brooks argues that
He suggests that partly, this is an attribute of the problem being solved.
Essential versus accidental complexity
He suggests that sometimes we add complexity by our choices of process or design, but that some problems are just plain complicated. As a consequence, he suggests that there is an
that we will always commit along the way, and that this is independent of the number of people we have working.
But he also argues that
More personnel implies more communications paths
Reducing Internal Communications Costs
Our options are limited
We can divide this into
Historically, the former has been emphasized
Over time, more and more emphasis has shifted to communications with the users.
Users, Customers, and Stakeholders
“Users” is an incredibly vague, catch-all term that serves to hide as much as it reveals.
Avoid it when possible.
Customers are the people who have the authority to accept or reject the system, to pay for it or not.
“Pay” is not necessarily a simple monetary transaction.(e.g., internal projects)
Stakeholders are the people with an interest in the structure and behavior of the system.
Example:
A company’s upper-level management approves budget to develop a system. They are the customers.
The output of the system is a series of reports used on a monthly basis by the company’s middle and low-level managers. They are stakeholders, because they have an interest in the content and format of those reports.
Much of the input of the system will be supplied by the company’s clerical staff, sales people, and technicians. They are also stakeholders, because the system will directly impact their daily jobs.
We look to customers for general guidelines on what will make the valuable and acceptable to them.
We look to stakeholders for much of the insight into how the system needs to work.
There are a few “obvious” ways to organize developers into a team.
One might be the basic democracy (or anarchy) of everyone working as peers.
Dangers of Hierarchical Teams
Distance between teams (where real work is done) and higher mgmt may hide problems.
I like van Vliet’s example:
"The following scenario is not entirely fictitious:
bottom: we have severe troubles in implementing module X;
level 1: there are some problems with module X;
level 2: progress is steady, I do not foresee any real problems;
top: everything proceeds according to our plan."
Level in hierarchy often equates with rank / rewards
Roles/Teams | |||||
---|---|---|---|---|---|
Sub-systems | Coding | Architecture | Analysis | Testing | GUI |
A | Y | Y | Y | Y | |
B | Y | Y | Y | Y | |
C | Y | Y | Y | ||
D | Y | Y |
Clearly this has limited benefit if an organization is so small that they have just one architect, one tester, …
In this model, team members with critical skills can be swapped from project to project depending on where each project is within the SDPM. For example, a good architectural designer may leave projects once they enter the high-level design phase.
Dangers of Matrix Organization
Anarchy, hierarchy, and matrix are all pretty generic forms.
Next we look at some specific organizations that have been attempted.
Mills (1970)
Motivated in part by studies showing vast differences in productivity between different individuals within an organization
Programming productivity studies have found that the “best” people in many organizations were orders of magnitude more productive than the average. (Not than the worst, but than the average.)
Some of this correlates with varying degrees of experience, both in general and with the specific problem domain and development environment at hand. But some of this seems to indicate that some people just are better at this than others.
Aims to allow the potentially most productive people to work unhindered
Organization of the Chief Programmer Team
Observations
SWAT ==
Skilled With Advanced Tools
A team organization for iterative process models
Small teams, often sharing a workspace
Typically, one team manager
Common in open-source development
Total team can be huge and diverse.
Closing Thoughts
If you were formed into groups, this week, to work on a project, how would you organize yourselves?
Does it make a difference to your answer whether this is a distance course?