Process and People

People IssuesEdit

People in the processEdit

People are central to the way that software gets developed and the managers in the software process are primarily concerned with managing the motivation of their team members.

Needs and motivationEdit

Maslow's hierarchy of needs categorizes five needs of people. Three of these - social needs, esteem needs and self-realization needs are the main concerns of people managers.

  • Social needs: In the software process this translates to creating opportunities for interaction and communication
  • Esteem needs: In the software process this translates to bonuses and stock option, recognition and service awards, positive appraisals
  • Self-realization: In the software process this translates to what might be termed progression. Allowing people to train and learn new skills and progress to positions of responsibility.

Personality typesEdit

Maslow's needs provide good guidelines for understanding team member motivation, but this is not enough. People managers also need to understand the different personality types of team members and how that effects how their motivation and individuals and as a team.

  • Task oriented: motivated by the task undertaken. They must "believe" in what they are doing
  • Self oriented: their motivation is external to the task. The task represents means of achieving their own goal
  • Interaction oriented: motivated by social interaction and actually being at work

In spite of this categorization, it's never clear cut. People's motivation may change depending on the task, personal circumstances or other factors.

People MotivationEdit


It is important for managers to motivate the members of the team working on a project. Motivation keeps the people interested in what they are doing which is good for everyone concerned.

There are many theories of motivation:

These theories describe why people behave in a certain way in order to achieve a certain goal, e.g. get food, be promoted, etc. The goals can be basic (food, shelter, etc), personal (self-esteem) or social (acceptance).

In order for a team member to be satisfied and motivated, the manager must help the team member in achieving/satisfying their needs. This could be done by providing a wage, setting-up teams (such as sports teams), providing promotion opportunities, training, etc.

People are not only motivated by their own goals and beliefs but also by groups and cultures that they are involved with. These groups can be a motivating reason why someone does what they do while around that group.

Personality TypesEdit

Not only should the “need hierarchy” be taken into account but also “Personality Types”.

The following are personality types:


The work is the motivation


Work is a way to achieve a personal goal


The motivation comes from the involvement of co-workers because the person likes to go to work.

Models for Process & PeopleEdit


Agile Processes & TeamsEdit

Individuals and interactions over processes and tools - Agile Manifesto

In our quest for repeatability, we have sacrificed individualism - Jim Highsmith[1]

At the heart of any discussion about the differences between agile and plan driven development is the approach to people. This approach is probably the defining difference between agile and plan driven methodologies.

Process doesn't turn people into star performers. People turn people into star performers - Jim Highsmith[2]

In the Agile philosophy, the belief is that by putting the individual at the centre of the process you allow them to be as creative as possible.

A key element in getting teams to work together is the physical organization of the team to maximize communication. Discussions of Extreme Programming will often include guidelines on layouts, seating arrangements and floor plans. See Chapter 3 of Agile Software Development: The Cooperative Game, Second Edition, [3] for an example.

Another common element of Agile projects is the use of a highly visible dashboard to track progress and highlight problem areas. Dashboards are updated frequently and keep in high-visibility, high-traffic areas. For distributed teams, a virtual dashboard is often used.

Agile Teams are considered to be self-organizing, that is, that while they have a leader who keeps the team on track for meeting goals, it is up to the team to understand and organize tasks.

Teams & CommunicationEdit

Teams in Software DevelopmentEdit


In software project management one of the most important issues is an effective software team organization, formation and management. It is essential to form a competent team for a project that is a short or long-term project, taking into account project scope, organisational structure and processes within the organisation. Balancing the know-how, procedures and skills of the team members, who form a group, which works as an entity.

To improve weak areas, necessitate identifying personal strength and ability of the team members who benefit to the project success. Complex parts of identifying types of personality and other factors a specially in multinational organisations and teams required more than knowledge, includes experience in project management. There have been researched and proposed assemble types of team members model for software team formation.

Myers-Briggs Type IndicatorEdit

MBTI was developed a model to identify the psychological type of a personality through a questioner. This model was developed during 40’s based on the theories of psychological types for women entering the industrial workforce, to identify which position is most suited.

All of us have different psychology and some are better at one thing while weaker at another. MBTI proposed model identifies four pairs of opposite psychological inclination. Those four pairs are called dichotomies. Each preference is assigned a letter E for Extraversion etc, resulting in 16 combinations.

ESTJ - Extraverted, Sensing, Thinking, Judging

INFP - Introverted, Intuitive, Feeling, Perceiving

Extraversion-Introversion stand for attitude, Sensing-Intuition and Thinking-Feeling stand for Functions and Judging-Perceiving stand for Lifestyle. After completion of the test and answering to questions, MBTI identifies for what position is the person better suitable.

Tuckman’s StagesEdit

Another model was developed by Bruce Tuckman in 1965. This model is called Forming-Storming-Norming-Performing. In order for team to form and grow team must follow these Tuckman’s group development stages.

Forming stage is when team meets and identifies tasks and goals to be achieved. This stage is very important because project stakeholders meet face-to-face, get to know each other in person. If project is not collocated for future collaboration and work is recommended to have face-to-face meetings frequently.

During Storming phase propose ideas on the project; define what development model to follow. This stage might be harsh and tolerance between team members is required.

Norming stage brings project participants closer together in human sense. Teamwork is developed through collaboration agreeing on workflow, rules, behaviour and values.

Performing stage comes after with a well developed teamwork and interdependent structure and workflow. Teams are able to productively function as a entity without a supervision.

Agile Software Teams and Distributed TeamsEdit

In agile development great emphasis is on people well being. Small, well formed teams of good developers, collocated, formed in agile development perform better then well-organized processes and tools. It is crucial to form well organised and experienced team, especially in agile, short or long term projects. Well formed team in agile can do better than a bad team regardless what effective processes it follows.

The best advantage is collocation of the team. Effective collaboration between software team members and stakeholders is the key in successful software projects. Agile and adaptive team is better answer then using linear waterfall model. Software should be developed in iterations for dynamic purposes of the project. Iterations are also beneficial to developers, that can gain experience and overall improvement of themselves.

Combination of small teams up to ten members, also possible to apply greater number up to forty team members in agile development. Bigger teams and distributed teams have other advantages like more technology onboard and possibility to incorporate more skilled participants. Also there are numerous negative aspects of distributed teams like time zone – put off collaboration between team members on regular working hours and cultural habits and specifications.

Group workingEdit

Group compositionEdit

Group composition would depend on what kind of project we are taking. The key point would be: “Let the appreciate people do appreciate work.”

“You need a mix of people for every task. Some people are good at having insightful ideas, but not at implementing them; Some are good at design concepts, while others are better at implementation; Some people enjoy finishing off and putting the ‘polish’ on the product, while others hate it. Occasionally you may have to get people to do things they fundamentally dislike. You may have to do some things yourself that nobody else will do.”(Gerry, 2008)

A developer with good performance on programming would be the best choice. Their behaviour on themselves likes a good example shown for other people. However, if most of developer are less experience and unsatisfied performance in a team, the critical thing should be using a appreciate process to control and manage them as a criterion.

Group cohesivenessEdit

Group is better than the sum of its parts. Every member in the team is unique and important. Every team member should have the cognition and spirit of team-work. How to improve and cohesiveness in the development team? Following initiative would be useful for reference:

  • Deeply understand our colleagues work with you
  • Learn from the mentor within the team

“Advantages of a cohesive group are:

  • Group quality standards can be developed
  • Group members work closely together so inhibitions caused by ignorance are reduced
  • Team members learn from each other and get to know each other’s work
  • Egoless programming where members strive to improve each other’s programs can be practiced.” (Gerry, 2008)

However, the cohesive group is affected by following factors:

  • Organizational culture
  • Group individuals

Developing cohesivenessEdit

Developing group cohesiveness on the primesEdit

  • Same wish in one team
  • Efficient communication
  • Trust each other

How to develop group cohesivenessEdit

  • Social events
  • Developing a group identity and territory
  • Explicit team-building activities (Training &Outdoors) (Gerry,2008)

Openness with information is a simple way of ensuring all group members feel part of the groupEdit

  • Give people a plenty of time on communication between each other
  • Motivate people interested over award
  • Let people pride in work
  • Let people in accomplishment
  • Let people in contribution
  • Encourage people’s achievement in working

Reduce the setup time for fresh people, help them adapt the organization’s culture and develop process as soon as possibleEdit

Using P-CMM for improving the way in which an organization uses its human assets.Edit

The main purposes for 5 maturity level of P-CMM:

  • Continuous Capability Improvement
  • Construct active and efficient group
  • Motivate improving performance
  • Training resource for future use

Group communicationsEdit

Office space and team collocationEdit

Office space and team collocation is involved with the managing of the environment that the people work in and the communications between the people there.

Group communications should not be centralised but set up in such a way that people can talk to whoever they need when they need to. Employees should be allowed to organise their own meeting and their own work spaces.

Agile methods, such as Crystal Methods, greatly encourage team collocation and free-flowing communications between team members. [See]

Teams, of sizes 6 to 12, can benefit from close proximity and the “caves and common” room arrangements. Ideas can be discussed, problems resolved more effectively, etc.

If team members are situated away from each other, such as in distributed project, then there is far less informal communication which leads to increased discussions in formal meetings. This is somewhat alleviated by used of instant messaging (not liked in some organisations) or phone calls but this increases the communication overhead.

When global projects are concerned, then issues such as language, culture, working hours & time-zones need to be considered.

Team ProductivityEdit

Small teams are capable of achieving high productivity. They can benefit from having a close proximity to the other members in the team but also from shared knowledge as a result through interaction. This is also known as “Tacit Knowledge”. In small teams information is easily shared and problems are quickly resolved. Also fewer communication formalities exist such as too many meetings and intensive documentation.

Distributed projectsEdit

Many projects are executed in a distributed fashion. This means that project team are interacting with each other without actually sharing the same office space. Team members may be on different floors in the same building or even in different buildings. Distributed projects therefore cannot benefit from tacit knowledge or settle with informal communications. Potentially more formality procedures need to be in applied.

Global projectsEdit

Major multinationals are now executing projects in a global manner. This is the next step after working in distributed projects. In global projects the challenges lie in the management of team members who are located in different countries. These challenges include issues around management, time zones, cultural differences etc. On the other hand software companies are more and more outsourcing their software development to low cost countries and companies find new ways to collaborate globally.


  1. Agile Software Development Ecosystems, Highsmith p373 Ch 26
  2. Agile Software Development Ecosystems, Highsmith, p92 Ch7
  3. Agile Software Development: The Cooperative Game, Second Edition, 2006