Motivation and Self Organization teams from Agile Perspective

Motivated individuals

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

This principle highlights the Agile methods’ reliance on the motivation of each team member to achieve project success. Most of the practices of these methods make the assumption that team members are going far beyond simply following orders and doing what was assigned.

They expect that each person is exercising his or her professional judgment to take the path that he or she believes is best at each juncture of the project, or at least to raise questions and concerns to be discussed with the team, management, and the customer.
But the Agile methods do not just expect motivated individuals to appear. The second sentence of this principle highlights a few conditions that the Agile Manifesto authors believe are important to building a motivated team: an appropriate environment, support for them as professionals, and trust that they will indeed exercise good professional judgment.

These things highlight the Agile methods’ differences from the more conventional command-and-control mode for managing projects. The traditional methods assume that intrinsic motivation is rare, and so they enforce specific behaviors. The Agile methods build an environment where each individual is challenged to build his or her capabilities and where motivation is an expected outcome of the environment.

Perhaps a better way to state this principle would be, “Build project environments that generate motivated individuals.” This statement aligns more readily with the way the Agile methods are engineered.

Self-organizing teams

"The best architectures, requirements, and designs emerge from self-organizing teams."

The Agile methods embrace the recent movement toward self-managed, self-directed, or (as this principle says) self-organizing teams. This philosophy is a movement away from traditional command-and-control management and toward one that counts the team as an entity that has its own knowledge, perspective, motivation, and expertise. In this environment, the team is treated as a partner with management and the customer, capable of providing insight, affecting decisions, and negotiating commitments.

The Agile Manifesto sees this structure not only as a way to achieve a more motivated team but also (as this Principle states) as a way to achieve technical excellence. The Agile methods each count on the team itself to keep the technical issues under control and “on the radar scope” when project decisions are being made.

Different agile methodologies suggest different practices to start and provide required environment in order to make motivated individuals and self directed teams.

Adaptive Software Development suggest Development team as an independent agent that should be involved with other agent such as management and customer. and Speculate for Project initiation and adaptive planning and The Adaptive (Leadership-Collaboration) Management Model

Dynamic System Development Method says that DSDM teams must be empowered to make
decisions

XP suggest The Planning Game and Collective ownership

Feature-Driven Development (FDD) suggest Class (code) ownership and Feature teams

Lean Software Development suggest Self-determination and Motivation

And finally Scrum says that The members of the Scrum development team are key participants in Sprint (development cycle) planning in a Scrum project. They participate fully along with other stakeholders in planning each Sprint, and their commitment
to achieving the Sprint goals is a key criterion for an acceptable Sprint plan.

During each sprint, the Scrum team has full authority to do whatever they believe is necessary to achieve the Sprint goals. They even have the authority to abort the Sprint if they discover that the agreed-upon goals cannot be met. Thus, the Scrum team self-manages and (it is expected) also self-motivates.

But the basic philosophies of these methods are remarkably similar, here is brief description:

Trusting the technical team
Abandonment of command-andcontrol style management; replacing it with clear respect for the team:

◗ Include the team in all deliberations about the project.
◗ Give them unfettered access to the customer.
◗ Seek their input on all technical issues.
◗ Believe their concerns about schedule goals.
◗ Expect them to learn (along with everyone else) as the project progresses.
◗ Gain their willing commitment to all plans.
◗ Negotiate with them to reach acceptable plans.
◗ Empower them with broad authority.
◗ Provide the tools and support they need.
◗ Trust them to exercise their best professional judgment in all circumstances.

This essentially means entrusting the development team with the authority to self-organize and self-manage.

Staffing with “motivated individuals”

You may be asking yourself, “Where am I going to find all of these motivated people?” “And what will I do with the unmotivated lumps I am stuck with now?”

It is true; most of your staff members are not superstars. In fact, most of them are pretty average. The point behind the Agile methods is not that you must find a whole bevy of highly motivated and technically expert people. Rather, it is that by adopting an Agile Method and what ASD calls the “leadership-collaboration” management style, you can motivate most of your current staff to behave more like superstars.

Behavioral psychology has long told us that people tend to live up to (or down to) the expectations placed on them. This is as true with your technical staff as with any other population. The average person, in an environment where his or her expertise and knowledge is valued, will not only bring those attributes to bear on the topic at hand but will also seek to improve them, to make himself or herself more capable of rising to such
challenges in the future.

Pair Programming
XP’s practice of “Pair Programming” is unique and foreign to almost all organizations. It states that pairs of individuals working together perform all technical work. These pairs are expected to form and trade partners from time to time. All designing, test case development, coding, and testing is done in pairs. While one member of a pair is “driving” the computer, the other is watching, assessing the partner’s work, and asking questions.

The pair switches roles on a regular basis. Although this practice sounds wasteful of your most precious resource (your engineers’ time), XP’s proponents claim just the opposite. They claim that a pair working together can be as much as 50% more productive than the two individuals would be if they worked separately. This is expected for a variety of reasons:

◗ The real-time review being done by the observing partner results in many defects being discovered and corrected within minutes of being created, instead of showing up later in tests when the diagnosis and correction could be more time-consuming.

◗ The person in the observer role tends to think about the big picture, making him or her more likely to identify architecture, design, or testing issues early, so they can be corrected before much rework would be required.

◗ The constant interaction between the individuals allows them to learn from each other, sharpening both of their skills and making each of them more capable.

◗ Because two individuals become intimately familiar with every part of the system, the loss of any one person cannot cripple the project.

◗ It provides a way for any new project member (even a recruit fresh out of school) to become a contributing member of the project very quickly.

Chief Programmer
FDD includes a Chief Programmer role. This role is generally reserved for highly respected team members who have superior technical knowledge. By placing such individuals into this role, FDD seeks to capitalize on their expertise and reputation to strengthen the skills of the rest of the team. In addition to their normal technical tasks, Chief Programmers act as coaches and mentors on technical matters, being a resource to team members who have questions about the work they are contemplating.

Method Coach
Some Agile methods (e.g., XP and Scrum) recommend that the project have a person whose job is to coach the team in using the method. This is a good recommendation in any environment where the team is being asked to change how they do their work. Changing old habits can be difficult, and a coach may be indispensable in helping people recognize old habits and exchange them for new ones.

A coach can keep things running efficiently by being the person who is always concerned about the method and how well it is serving the project’s needs. And, of course, when team members do become aware of the method (because it is impeding their work), the coach will be prepared to help them work through the problem and come up with ways of working that serve the team better. The Coach ensures that the Method you have adopted is indeed creating a project environment in which the team can self-motivate and self-manage.