This is the ‘Team Performance - Agile Team Formation: PMI ACP’ tutorial of the PMI-ACP Certification course offered by Simplilearn. We will learn about other aspects of Team Performance here.
After completing this lesson, you will be able to:
One of the Agile principles states, “Build the team around motivated individuals; give them the support and encouragement they need.” An Agile leader needs to motivate the team. Some of the well-known motivation theories are:
Abraham Maslow's ‘Hierarchy of Human Needs’ is depicted as a five-level pyramid. The four lower levels represent the most fundamental needs, called ‘Deficiency needs’ or ‘D-needs.’ The fifth level is self-actualization, where people reach their full potential. Maslow indicates that the lower level needs have to be satisfied before one can move to the higher level needs.
Frederick Herzberg established a theory based on the two factors, Motivators and Hygiene factors.
Motivators are those factors that give immense satisfaction, arising from intrinsic conditions of the job, such as recognition, achievement, or personal growth. Examples of Motivators are challenging work, recognition, and responsibility.
Hygiene factors are necessary but do not give motivation; although the absence of these will result in dissatisfaction. Examples of Hygiene factors are status, job security, salary, fringe benefits, and work conditions.
An Agile project team requires hygiene factors to establish a minimal level of team performance. Also, motivators determine if the team can achieve high performance.
David McClelland's ‘Achievement Motivation’ theory is based on ‘Maslow’s Hierarchy of Needs’ theory. McClelland’s theory describes three types of dominant motivators, which are Achievement, Affiliation, and Authority or Power.
The following traits characterize people with 'Achievement' motivators –
The following traits characterize people with 'Affiliation' motivators –
The following traits characterize people with 'Power' motivators –
Barry Boehm (Refer to the pronunciation tips table) created team motivational factors from his extensive project work. He established the ‘Theory W’ of Software Project Management, which states, ‘Make Everyone a Winner.’ His theory was supported by two principles, ‘Plan the Flight and Fly the Plan’ and ‘Identify and Manage Your Risks.’ Boehm identified the following team motivators:
Planning to get more details on measuring Team Performance? Click for course description!
Teams are important in Agile and therefore, the space where they work is important too. Team Space, also known as ‘War Room,’ refers to the environment in which the team performs their everyday work. Team space also has other names such as ‘team room,’ ‘project room,’ or ‘delivery room.’
Establishing a team space involves gathering an entire team in one room. Agile emphasizes a number of important factors to improve the effectiveness of team space that fosters communication and motivation, leading to higher productivity.
Bad team spaces can lead to chaotic and unproductive team output. Often, lack of communication is cited as the single biggest cause of project failure. As depicted in the image, some signs of bad team space are:
The focus should be on reducing distractions to avoid communication gaps, thereby consistently delivering the predicted outcome and value.
Co-located teams work together in the same physical location. Each team will have all the skills required. Collaboration and coordination are easier in the co-located teams. However, usually, the co-located team would be independent and be able to work on its own. The image depicts a co-located team in Location A.
In Distributed teams, the team members work in geographically dispersed locations. Some of the characteristics of these teams are:
The given images depict distributed teams across Locations A and B.
One of the myths around Agile is that it only works on co-located teams. Agile can work on both distributed and co-located teams. A co-located team is an advantage regardless of the methodology because it makes coordination and collaboration easier. An Agile team, like any other team, can work around these difficulties and make the methodology work even on a distributed team.
The differences between the co-located teams and distributed teams are listed here. In co-located teams:
In distributed teams:
Osmotic Communication refers to the information that is overheard in the background of the team room and some of it is absorbed. It is one of the benefits of having a co-located team.
As depicted in the image, there are no impediments that impact the flow of information across the work area. Therefore, in such an environment, osmotic communication happens naturally.
Collaboration and coordination are required for a project. Collaboration is the process of bringing together the knowledge, experience, and skills of multiple team members to contribute to the development of a new product. It requires some level of coordination between the team. The act of collaboration enables the team to achieve potentially a lot more than the “sum of the parts”.
Coordination is the act of sharing information among the team members. Collaboration and coordination require some level of interaction. A few guidelines for using the interaction modes to foster greater collaboration and coordination are as follows:
There are many enabling technologies for collaboration. Broadly, they may be classified as Synchronous and Asynchronous.
Through synchronous technologies, all participants can view information and or meet at the same time. Examples are teleconferencing and video conferencing, web-hosted meetings, and virtual collaboration sessions.
Through asynchronous technologies, all participants can view information and provide feedback at different points in time. Examples are e-mail, exchange of drawings and documents, project information and models, and workflow and groupware software.
Two scenarios are given, where the issue of the communication gap is addressed.
Natasha Lisovskii, the ScrumMaster at Nutri Worldwide Inc., was monitoring an R&D project of developing a new Customer Relationship Management software package. Despite following the Agile methodology, the project was behind schedule. The given image shows how the team members were working in silos and communicating through emails and physical documents. There were hardly any face-to-face interactions or daily stand-up meetings.
Most of the information sharing took place through emails and physical documents. ScrumMaster monitored the R&D Project. The Business Analysts extracted knowledge about requirements from customers and handed them to the developers. Developers translated the information into executable codes. Then, testers wrote verification scripts to validate the results.
There were huge communication gaps at every stage of this process resulting in a difference in the original request and the final delivered product. Every team member was working in silos; however, the ScrumMaster had a full view of the project. Based on the scenario, list the changes that the Agile coach of Nutri Worldwide Inc. should implement to reduce the communication gap within the team.
Listed are some of the recommended changes that could be introduced to help the team overcome the issues:
Tony Orlando, the Executive Vice President of Sales and Marketing at Fairfax, was asked to report on the primary reason behind project failures. The reason cited was the contradictory goals of different stakeholders working on the same project. The given image depicts the main challenge faced by the team.
The developer wants to write structured code. The Marketing, Sales, and Finance personnel want the product to succeed, while the customer demands a good user experience. There is little interaction between these stakeholders in an IT project, leading to differences in the goals of the business unit and the IT unit. Tony cited that the failure of new initiatives was due to the huge disconnect between business units, such as marketing, sales, and finance, and IT goals.
It was out of these seemingly contradictory goals that the Agile development framework was born. Its principles are very important in business, today. In Agile, the focus shifts from the project to the product. Sufficient communication channels and iterations are required for the success of the organization. The given image shows the necessary communication channels and iterations.
Brainstorming session is a tool to generate ideas from a selected audience to solve a problem or stimulate creativity. It is important to create an environment that would encourage and facilitate a free flow of ideas. Brainstorming could also be used by the project teams for solving a process problem, inventing new products or product innovation, solving inter-group communication problems, improving customer service, budgeting exercises, and project scheduling.
Some of the steps to set up an effective brainstorming session are as follows.
Want to get certified in PMI ACP? Click here!
There is no single prescription to make a brainstorming session successful, but the steps to conduct an effective brainstorming session are given below:
An important metric used by the team in planning is “Velocity”. It helps forecast delivery timelines. Velocity is calculated by adding the number of story points assigned to each user story that the team has completed during the iteration.
Key points to remember are as follows:
Velocity is a reliable measure because it is based on empirical data, past observations, and not on somebody’s perception of the data. It is an observation of the team’s capacity to complete work per iteration and not an estimate or a target. Velocity is based on the team’s sizing of work items in reference to estimated time; not on the time dictated or imposed by anyone other than the team members.
It is based on the team’s estimation and not the estimation done by some external entity such as customers or stakeholders. Velocity is comparable across iterations for a given team on a given project. The velocity of a team can only be compared with itself from iteration-to-iteration.
The goal of the team should be to maintain a consistent velocity and not necessarily to maximize velocity. It is not comparable across teams or projects. The image below depicts the velocity trend across iterations, where the blue line indicates actual velocity.
If a team completes four stories in a given iteration, with story points A, B, C, and D as 5, 3, 7, and 5 respectively, calculate the velocity.
Velocity can be calculated by adding the story points assigned to each user story. By adding the story points given here, velocity is 5+3+7+5 = 20.
If the velocity of the team is 14, identify the stories that will be earmarked for Iteration 1 and Iteration 2 during release planning? (Note: Story A has the highest priority followed by Story B and so on)
If the team knows its normal rate of velocity, it can use this information for planning the work. In this example, the team’s velocity is 14. The team can select stories to work on, in future iterations, based on the sizes of the stories. For instance, in iteration 1, the team can work on stories A, B, and C, which add up to a size of 14 (5 + 8 + 1).
Another combination of stories can also be picked, such as C, D, F, and G, which adds up to a size of 14 (3 + 3 + 5 + 3). In collaboration with the product owner, the team can select the best possible combination.
Velocity measures the number of story points delivered during iteration. The unit of measure for velocity is determined during the estimation session. They are Story Points and Ideal Time. Story points are the unit of measure if the team plans to commit to user stories based on relative sizing.
The ideal time is used as a unit of measure if the team plans to commit to user stories based on hours or days. Stories are the actual work items that determine the value of the story points. Ideal hours reflect the effort to implement the story points. Note the following points:
The given bar chart shows a graph plotting the velocity of a team over 13 iterations. Notice that the velocity of the team varies largely between 25 and 45, with one outlier observation in iteration 1 and 7. Leaving the outliers, the average velocity of sprints is 38. Such historical data is useful for the team, as the average velocity from iterations will be used to compute the overall capacity of upcoming releases.
As Agile was started by software developers and it emphasizes on sharing, community, and high visibility, there are a large number of Agile tools available as open source products. Some of the open source Agile tools are:
Let us summarize the topics covered in this lesson:
This concludes the Team Performance - Agile Team Formation: PMI ACP tutorial. In the next domain, we will learn ‘Adaptive Planning - Agile Planning and Time boxing: PMI ACP.’
Name | Date | Place | |
---|---|---|---|
PMI-ACP® Certification | 6 Feb -27 Feb 2021, Weekend batch | Your City | View Details |
A Simplilearn representative will get back to you in one business day.