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.
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.
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.
In spite of this categorization, it's never clear cut. People's motivation may change depending on the task, personal circumstances or other factors.
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.
Not only should the “need hierarchy” be taken into account but also “Personality Types”.
The following are personality types:
Task-oriented
The work is the motivation
Self-oriented
Work is a way to achieve a personal goal
Interaction-oriented
The motivation comes from the involvement of co-workers because the person likes to go to work.
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.
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.
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.
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.
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 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 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:
“Advantages of a cohesive group are:
However, the cohesive group is affected by following factors:
The main purposes for 5 maturity level of P-CMM:
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 http://en.wikiversity.org/wiki/Crystal_Methods#Close_or_osmotic_communication]
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.
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.
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.
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.