Major issues in organizing a development team are
Major issues in organizing a development team are
Communication
Major issues in organizing a development team are
Communication
maximize communication within the team
Major issues in organizing a development team are
Communication
maximize communication within the team
establish responsive communication points with stakeholders
Major issues in organizing a development team are
Communication
maximize communication within the team
establish responsive communication points with stakeholders
Staffing
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?
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
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
irreducible number of errors
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.
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.
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 |
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
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?