ORGANISATION AND TEAM STRUCTURES
Usually every software development organisation handles several projects at any time.
Software organisations assign different teams of developers to handle different software projects.
With regard to staff organisation, there are two important issues
- How is the organisation as a whole structured ?
- How are the individual project teams structured ?
There are a few standard ways in which software organisations and teams can be structured.
We discuss these in the following subsection.
Essentially there are three broad ways in which a software development organisation can be structured
- Functional format
- Project format
- Matrix format.
In the functional format, the development staff are divided based on the specific functional group to which they belong to.
This format has schematically been shown in the following figure.
The different projects borrow developers from various functional groups for specific phases of the project and return them to the functional group upon the completion of the phase.
As a result, different teams of programmers from different functional groups perform different phases of a project.
For example, one team might do the requirements specification, another do the design, and so on.
The partially completed product passes from one team to another as the product evolves.
Therefore, the functional format requires considerable communication among the different teams and development of good quality documents because the work of one team must be clearly understood by the subsequent teams working on the project.
The functional organisation therefore mandates good quality documentation to be produced after every activity.
In the project format, the development staff are divided based on the project for which they work (See Figure b of the following figure.
A set of developers is assigned to every project at the start of the project, and remains with the project till the completion of the project.
Thus, the same team carries out all the life cycle activities.
An advantage of the project format is that it provides job rotation. That is, every developer undertakes different life cycle activities in a project.
However, it results in poor manpower utilisation, since the full project team is formed since the start of the project, and there is very little work for the team during the initial phases of the life cycle.
Functional versus project formats
Even though greater communication among the team members may appear as an avoidable overhead, the functional format has many advantages.
The main advantages of a functional organisation are:
• Ease of staffing
• Production of good quality documents
• Job specialisation
• Efficient handling of the problems associated with manpower turnover.
The functional organisation allows the developers to become specialists in particular roles, e.g. requirements analysis, design, coding, testing, maintenance, etc.
They perform these roles again and again for different projects and develop deep insights to their work.
It also results in more attention being paid to proper documentation at the end of a phase because of the greater need for clear communication as between teams doing different phases.
The functional organisation also provides an efficient solution to the staffing problem.
The project staffing problem is eased significantly because personnel can be brought onto a project as needed, and returned to the functional group when they are no longer needed.
This possibly is the most important advantage of the functional organisation.
A project organisation structure forces the manager to take in almost a constant number of developers for the entire duration of his project. This results in developers idling in the initial phase of software development and are under tremendous pressure in the later phase of development.
A further advantage of the functional organisation is that it is more effective in handling the problem of manpower turnover.
This is because developers can be brought in from the functional pool when needed. Also, this organisation mandates production of good quality documents, so new developers can quickly get used to the work already done.
In spite of several important advantages of the functional organisation, it is not very popular in the software industry.
This apparent paradox is not difficult to explain. We can easily identify the following three points:
The project format provides job rotation to the team members. That is, each team member takes on the role of the designer, coder, tester, etc during the course of the project. On the other hand, considering the present skill shortage, it would be very difficult for the functional organisations to fill slots for some roles such as the maintenance, testing, and coding groups.
Another problem with the functional organisation is that if an organisation handles projects requiring knowledge of specialized domain areas, then these domain experts cannot be brought in and out of the project for the different phases, unless the company handles a large number of such projects.
For obvious reasons the functional format is not suitable for small organisations handling just one or two projects.
A matrix organisation is intended to provide the advantages of both functional and project structures.
In a matrix organisation, the pool of functional specialists are assigned to different projects as needed.
Thus, the deployment of the different functional specialists in different projects can be represented in a matrix (see Figure 3.14) In Figure 3.14 observe that different members of a functional specialisation are assigned to different projects. Therefore in a matrix organisation, the project manager needs to share responsibilities for the project with a number of individual functional managers.
Matrix organisations can be characterised as weak or strong, depending upon the relative authority of the functional managers and the project managers.
In a strong functional matrix, the functional managers have authority to assign workers to projects and project managers have to accept the assigned personnel.
In a weak matrix, the project manager controls the project budget, can reject workers from functional groups, or even decide to hire outside workers.
Two important problems that a matrix organisation often suffers from are:
- Conflict between functional manager and project managers over allocation of workers.
- Frequent shifting of workers in a firefighting mode as crises occur in different projects.
Team structure addresses organisation of the individual project teams.
Let us examine the possible ways in which the individual project teams are organised.
Here we shall consider only three
formal team structures
- Chief programmer
- The mixed control team organisations
Although several other variations to these structures are possible.
Projects of specific complexities and sizes often require specific team structures for efficient working.
Chief programmer team
In this team organisation, a senior engineer provides the technical leadership and is designated the chief programmer.
The chief programmer partitions the task into many smaller tasks and assigns them to the team members.
He also verifies and integrates the products developed by different team members.
The structure of the chief programmer team is shown in fol6 figure.
The chief programmer provides an authority, and this structure is arguably more efficient than the democratic team for well-understood problems.
However, the chief programmer team leads to lower team morale, since the team members work under the constant supervision of the chief programmer. This also inhibits their original thinking.
The chief programmer team is subject to single point failure since too much responsibility and authority is assigned to the chief programmer.
That is, a project might suffer severely, if the chief programmer either leaves the organisation or becomes unavailable for some other reasons.
The chief programmer team is probably the most efficient way of completing simple and small projects since the chief programmer can quickly work out a satisfactory design and ask the programmers to code different modules of his design solution.
Types of projects for which the chief programmer team organisation would be suitable.
Suppose an organisation has successfully completed many simple MIS projects.
Then, for a similar MIS project, chief programmer team structure can be adopted.
The chief programmer team structure works well when the task is within the intellectual grasp of a single individual.
However, even for simple and well understood problems, an organisation must be selective in adopting the chief programmer structure.
The chief programmer team structure should not be used unless the importance of early completion outweighs other factors such as team morale, personal developments, etc.
The democratic team structure, as the name implies, does not enforce any formal team hierarchy is shown in the following figure.
Typically, a manager provides the administrative leadership. At different times, different members of the group provide technical leadership.
In a democratic organisation, the team members have higher morale and job satisfaction.
Consequently, it suffers from less manpower turnover. Though the democratic teams are less productive compared to the chief programmer team, the democratic team structure is appropriate for less understood problems, since a group of developers can invent better solutions than a single individual as in a chief programmer team.
A democratic team structure is suitable for research-oriented projects requiring less than five or six developers.
For large sized projects, a pure democratic organisation tends to become chaotic.
The democratic team organisation encourages egoless programming as programmers can share and review each other’s work.
To appreciate the concept of egoless programming, we need to understand the concept of ego from a psychological perspective.
Most of you might have heard about temperamental artists who take much pride in whatever they create. Ordinarily, the human psychology makes an individual take pride in everything he creates using original thinking.
Software development requires original thinking too, although of a different type. Human psychology makes one emotionally involved with his creation and hinders him from objective examination of his creations.
Just like temperamental artists, programmers find it extremely difficult to locate bugs in their own programs or flaws in their own design.
Therefore, the best way to find problems in a design or code is to have someone review it.
Often, having to explain one’s program to someone else gives a person enough objectivity to find out what might have gone wrong.
This is called egoless programming because it tries to avoid having programmers invest much ego in the development activity they do in a democratic set up.
However, a democratic team structure has one disadvantage—the team members may waste a lot time arguing about trivial points due to the lack of any authority in the team to resolve the debates.
Mixed control team organisation
The mixed control team organisation, as the name implies, draws upon the ideas from both the democratic organisation and the chief-programmer organisation.
The mixed control team organisation is shown pictorially in the following figure igure.
This team organisation incorporates both hierarchical reporting and democratic set up. In the following figure, the communication paths are shown as dashed lines and the reporting structure is shown using solid arrows.
The mixed control team organisation is suitable for large team sizes.
The democratic arrangement at the senior developers level is used to decompose the problem into small parts.
Each democratic setup at the programmer level attempts solutions to a single part.
Thus, this team organisation is eminently suited to handle large and complex programs.
This team structure is extremely popular and is being used in many software development companies.