Implementing An Agile Project Environment 

Implementing An Agile Project Environment

SO How Do You IMPLEMENT AN AGILE ENVIRONMENT?

The latest PMP Exam Syllabus now contains 50% of Agile Questions!

Managing a project using an agile approach requires that the project team adopt an agile mindset.

So let’s look first at gaining your all-important Agile Mindset:

You Need An Agile Mindset

Managing a project using an agile approach requires that the project team adopt an agile mindset. The answers to the following questions will help to develop an implementation strategy:

• How can the project team act in an agile manner? 
• What can the team deliver quickly and obtain early feedback to benefit the next delivery cycle?
• How can the team act in a transparent manner?
• What work can be avoided in order to focus on high-priority items?
• How can a servant-leadership approach benefit the achievement of the team’s goals?

Project Managers Must Harness Servant Leadership

Agile approaches emphasize servant leadership as a way to empower teams. Servant leadership is the practice of leading through service to the team, by focusing on understanding and addressing the needs and development of team members in order to enable the highest possible team performance.

Servant leaders practice and radiate agile

The role of a servant leader is to facilitate the team’s discovery and definition of agile.

Servant leaders approach project work in this order:

• Purpose. Work with the team to define the “why” or purpose so they can engage and coalesce around the goal for the project. The entire team optimizes at the project level, not the person level
• People. Once the purpose is established, encourage the team to create an environment where everyone can succeed. Ask each team member to contribute across the project work
• Process. Do not plan on following the “perfect” agile process, but instead look for the results. When a cross-functional team delivers finished value often and reflects on the product and process, the teams are agile. It does not matter what the team calls itsprocess. 

The following characteristics of servant leadership enable project leaders to become more agile and facilitate the team’s success:

• Promoting self-awareness
• Listening
• Serving those on the team
• Helping people grow
• Coaching vs. controlling
• Promoting safety, respect, and trust
• Promoting the energy and intelligence of others

Servant leadership is not unique to agile, but once having practiced it, servant leaders can usually see how well servant leadership integrates into the agile mindset and value.

When leaders develop their servant leadership or facilitation skills, they are more likely to become agile. As a result, servant leaders can help their teams collaborate to deliver value faster.

Successful agile teams embrace the growth mindset, where people believe they can learn new skills.

When the team and the servant leaders believe they can all learn, everyone becomes more capable.

Responsibilities of The Servant Leader

Servant leaders manage relationships to build communication and coordination within the team and across the organization.

These relationships help the leaders navigate the organization to support the team.

This kind of support helps to remove impediments and facilitates the team to streamline its processes.

Because servant leaders understand agile and practice a specific approach to agile, they can assist in fulfilling the team’s needs.

Servant Leader Facilitation Skills

When project managers act as servant leaders, the emphasis shifts from “managing coordination” to “facilitating collaboration.” Facilitators help everyone do their best thinking and work.

Facilitators encourage the team’s participation, understanding, and shared responsibility for the team’s output.

Facilitators help the team create acceptable solutions.

Servant leaders promote collaboration and conversation within the team and between teams.

For example, a servant leader helps to expose and communicate bottlenecks inside and between teams. Then the teams resolve those bottlenecks. Additionally, a facilitator encourages collaboration through interactive meetings, informal dialog, and knowledge sharing.

Servant leaders do this by becoming impartial bridge-builders and coaches, rather than by making decisions for which others should be responsible.

Servant Leaders Must Remove Organizational Impediments

The first value of the Agile Manifesto is individuals and interactions over processes and tools.

What better responsibility for a servant leader to take on than to take a hard look at processes that are impeding a team’s or organization’s agility and work to streamline them?

For example, if a department requires extensive documentation, the role of the servant leader could be to work with that department to review required documentation and then assist with creating a shared understanding of how agile deliverables meet those requirements. The servant leader would then go on to evaluate the amount of documentation required so teams are spending more time delivering a valuable product instead of producing exhaustive documentation.

Servant leaders should also look at other processes that are lengthy, causing bottlenecks and impeding a team’s or organization’s agility.

Examples of processes or departments that may need to be addressed include finance, change control boards, or audits. Servant leaders can partner and work with others to challenge them to review their processes to support agile teams and leaders.

For example, what good is it for the team to deliver working product every 2 weeks only to have the product fall into a queue or process that could take 6 or more weeks to release due to lengthy release processes?

Far too many organizations have these “bottleneck” processes that prevent teams from quickly delivering valuable products or services. The servant leader has the ability to change or remove these organizational impediments to support delivery teams.

Applying Interpersonal Skills AND Technical Skills

In addition to servant leadership, team members emphasize their interpersonal and emotional intelligence skills—not just technical skills. Everyone on the team works to exhibit more initiative, integrity, emotional intelligence, honesty, collaboration, humility, and willingness to communicate in various ways so that the entire team can work together well.

The team needs these skills so they can respond well to changes in project direction and technical product changes. When everyone can adapt to the work and to each other, the entire team is more likely to succeed.

Paving The Way For Others to Contribute

In agile, the team manages its work process and its work product. That self-management and self-organization applies to everyone serving and supporting the organization and project.

Servant leaders work to fulfill the needs of the teams, projects, and organization.

Servant leaders may work with facilities for a team space, work with management to enable the team to focus on one project at a time, or work with the product owner to develop stories with the team.

Some servant leaders work with auditors to refine the processes needed in regulatory environments, and some servant leaders work with the finance department to transition the organization to incremental budgeting.

The servant leader focuses on paving the way for the team to do its best work. The servant leader influences projects and encourages the organization to think differently.

The Responsibilities of a Servant Leader

Servant leaders can have many possible titles, but what is most important is what they do.

Here are some examples of the responsibilities a servant leader may have: Educate stakeholders around why and how to be agile.

Explain the benefits of business value based on prioritization, greater accountability and productivity of empowered teams, and improved quality from more frequent reviews, etc.

Support the team through mentoring, encouragement, and support. Advocate for team members training and career development.

The oxymoron quote “We lead teams by standing behind them” speaks to the role of the leader in developing their team members.

Through support, encouragement, and professional development, team members gain confidence, take on larger roles, and contribute at higher levels within their organizations.

A key role of the servant leader is to nurture and grow team members through and beyond their current roles, even if that means losing them from the team. Help the team with technical project management activities like quantitative risk analysis. Sometimes team members may not have knowledge or experience in roles or functions.

Servant leaders who may have more exposure or training in techniques can support the team by providing training or undertaking these activities.

• Celebrate team successes
• Support and bridge building activities with external groups
• Create upward spirals of appreciation and good will for increased collaboration

The Agile Project Manager Role

The role of the project manager in an agile project is somewhat of an unknown, because many agile frameworks and approaches do not address the role of the project manager.

Some agile practitioners think the role of a project manager is not needed, due to self-organizing teams taking on the former responsibilities of the project manager.

However, pragmatic agile practitioners and organizations realize that project managers can add significant value in many situations.

The key difference is that their roles and responsibilities look somewhat different.

Remember, the value of project managers is not in their position, but in their ability to make everyone else better.

Agile Project Managers MUST Use Servant Leadership

The project manager role is defined as “the person assigned by the performing organization to lead the team that is responsible for achieving the project objectives.”

Many project managers are accustomed to being at the center of coordination for the project, tracking and representing the team’s status to the rest of the organization.

This approach was fine when projects were decomposed into siloed functions. However, in high-change projects, there is more complexity than one person can manage. Instead, cross-functional teams coordinate their own work and collaborate with the business representative (the product owner).

When working on an agile project, project managers shift from being the center to serving the team and the management.

In an agile environment, project managers are servant leaders, changing their emphasis to coaching people who want help, fostering greater collaboration on the team, and aligning stakeholder needs.

As a servant leader, project managers encourage the distribution of responsibility to the team: to those people who have the knowledge to get work done.

The Agile Team Composition

A core tenet in both the values and the principles of the Agile Manifesto is the importance of individuals and interactions. Agile optimizes the flow of value, emphasizing rapid feature delivery to the customer, rather than on how people are “utilized.”Remember to build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.

When teams think about how to optimize the flow of value, the following benefits become apparent: People are more likely to collaborate. Teams finish valuable work faster.

Teams waste much less time because they do not multitask and have to re-establish context.

The Agile Team Member Dynamic

Agile teams focus on rapid product development so they can obtain feedback. In practice, the most effective agile teams tend to range in size from three to nine members. Ideally, agile teams are co-located in a team space.

Team members are 100% dedicated to the teams. Agile encourages self-managing teams, where team members decide who will perform the work within the next period’s defined scope.

Agile teams thrive with servant leadership. The leaders support the teams’ approach to their work. Cross-functional agile teams produce functional product increments frequently.

That is because the teams collectively own the work and together have all of the necessary skills to deliver completed work.

Regardless of the overall agile approach, the more a team limits its work in progress, the more likely its members can collaborate to expedite work across the board.

Team members in successful agile teams work to collaborate in various ways (such as pairing, swarming, and mobbing) so they do not fall into the trap of mini-waterfalls instead of collaborative work. Mini waterfalls occur when the team addresses all of the requirements in a given period, then attempts to do all of the design, then moves on to do all of the building.

Using this scenario, at some point in the building or the testing following the building, the team may realize it had assumptions that are no longer valid. In this case, the team wasted time in addressing all of the requirements. Instead, when team members collaborate to produce a small number of features across the board, they learn as they proceed and deliver smaller finished features.

Agile projects benefit from project team structures that improve collaboration within and among the teams. The diagram below shows you how:

Agile Team RolesThe Cross-functional team member

Cross-functional teams consist of team members with all the skills necessary to produce a working product. In software development, cross-functional teams are typically comprised of designers, developers, testers, and any other required roles.

The cross-functional development teams consist of professionals who deliver potentially releasable product on a regular cadence. Cross-functional teams are critical because they can deliver finished work in the shortest possible time, with higher quality, without external dependencies.

The Product owner

The product owner is responsible for guiding the direction of the product. Product owners rank the work based on its business value.

Product owners work with their teams daily by providing product feedback and setting direction on the next piece of functionality to be developed/delivered. That means work is small, often small enough to be described on one index card.

The product owner works with stakeholders, customers, and the teams to define the product direction.

Typically, product owners have a business background and bring deep subject matter expertise to the decisions. Sometimes, the product owner requests help from people with deep domain expertise, such as architects, or deep customer expertise, such as product managers. Product owners need training on how to organize and manage the flow of work through the team. In agile, the product owners create the backlog for and with the team.

The backlog helps the teams see how to deliver the highest value without creating waste. A critical success factor for agile teams is strong product ownership.

Without attention to the highest value for the customer, the agile team may create features that are not appreciated, or otherwise insufficiently valuable, therefore wasting effort.

Team facilitator

The third role typically seen on agile teams is of a team facilitator, a servant leader. This role may be called a project manager, scrum master, project team lead, team coach, or team facilitator. All agile teams need servant leadership on the team.

People need time to build their servant leadership skills of facilitation, coaching, and impediment removal. Initially, many organizations invite external agile coaches to help them when their internal coaching capability is not yet fully developed.

External coaches have the advantage of experience, but the disadvantage of weak relationships in the client organization.

Internal coaches, on the other hand, have strong relationships in their organization, but may lack the breadth of experience that would make them highly effective.

“I” shaped people

Some people have deep specializations in one domain, but rarely contribute outside of that domain. These people are known in agile communities as “I-shaped people” since, like the letter “I,” they have depth, but not much breadth.

“T” shaped people

T-shaped people supplement their expertise in one area with supporting, but less-developed skills in associated areas and good collaboration skills. As an example, a person who can test some areas of the product and develop different areas of the product is considered to be a T-shaped person.

A T-shaped person has a defined, recognized specialization and primary role, but has the skills, versatility, and aptitude for collaboration to help other people when and where necessary. This collaboration reduces hand-offs and the constraints of only one person being able to do the job.

Agile Teams are Generalizing Specialists

Agile teams are cross-functional, but the people often do not start off that way. However, many successful agile teams are made up of generalizing specialists, or “T-shaped” people. This means team members have both a focus specialty plus a breadth of experience across multiple skills, rather than a single specialization. Agile team members work to develop such characteristics due to intense collaboration and self-organization to swarm and get work done quickly, which requires them to routinely help each other. A single person’s throughput is not relevant.

Focusing on a single person’s throughput may even be harmful if it creates a bottleneck for the rest of the team. The goal is for the team to optimize the delivery of finished work to get feedback.

If the customer desires great results, such as rapid feature delivery with excellent quality, the team cannot be structured just with specialist roles in an attempt to maximize resource efficiency.

The team’s objective is flow efficiency, optimizing the throughput of the entire team.

Small batch sizes promote working together as a team. The product owner’s job is to make sure the team works on the highest-value work.

Agile Team Structures

Teams have adopted agile principles and practices across many industries. They organize people into cross-functional teams to iteratively develop working products.Instead of having all team members co-located, some organizations have distributed or dispersed teams.

Distributed teams have cross-functional teams in different locations. Dispersed teams may have each team member working in a completely different location, either in an office or from home.

While these arrangements are not ideal due to increased communication costs, they may still be workable.In one large, U.S.-based financial institution there was a program with a set of teams where the team members were based on the East Coast of the United States and several locations throughout India.

When the team first started, it was one large dispersed team (UX, analysts, developers, and testers) doing a “follow the sun”2 development practice where some working time overlapped across the team members to do warm hand-offs with the work. Team members conducted daily stand-ups together and used webcams to include all team members.

Key roles (analysts, product owners, UX designers, and development leads) in the U.S. would come in early to answer any questions from their India-based team members and help to resolve impediments. As the product started getting larger, and more funding came through, they decided to break into five smaller teams.

To do this, they decided to build co-located, distributed teams in various locations. They made the decision to build cross-functional, co-located teams in each of these locations consisting of developers and testers. They also had a core set of analysts, based in the two U.S. locations, who worked with their U.S.-based product manager and product owners and then worked with each of the teams, respectively. Although they had some structure in place where they conducted product reviews as an entire program, most of the other activities were conducted at a team level, based on what worked best for each team, to allow them to self-organize.

Try to use 100% Dedicated Team Members

What happens when the team members’ time is not 100% dedicated to the team?

While this condition is not ideal, unfortunately, it sometimes cannot be avoided. The key problem with having someone invest only a capacity of 25% or 50% on the team is that they will multitask and task switch. Multitasking reduces the throughput of the team’s work and impacts the team’s ability to predict delivery consistently.

Important Point.

Multitasking slows the progress of the entire team, because team members waste time context switching and/or waiting for each other to finish other work. When people are 100% dedicated to the team, the team has the fastest possible throughput.

People experience productivity losses somewhere between 20% and 40% when task switching, and this loss increases exponentially with the number of tasks.

When a person multitasks between two projects, that person is not 50% on each project. Instead, due to the cost of task switching, the person is somewhere between 20% and 40% on each project. People are more likely to make mistakes when they multitask. Task-switching consumes working memory and people are less likely to remember their context when they multitask.

When everyone on the team is 100% allocated to one project, they can continuously collaborate as a team, making everyone’s work more effective.

Not all teams have all the roles that they need. For example, some teams need support from database administrators or research analysts. When a team has temporarily assigned specialists, it is important to ensure that everyone has the same set of expectations. Is this specialist 100% allocated to the team and for how long?

Set expectations with everyone (the specialist and the team) to clarify the level of commitment so the team can deliver. Part-time assignments create risks for the project.

Establish Team Work-spaces

Teams need a space in which they can work together, to understand their state as a team, and to collaborate. Some agile teams all work in one room together.

Some teams have a team work-space for their stand-ups and charts, and work on their own in cubicles or offices.

While companies are moving toward open, collaborative work environments, organizations also need to create quiet spaces for workers who need uninterrupted time to think and work.

Therefore, companies are designing their offices to balance common and social areas (sometimes called “caves and common”) with quiet areas or private spaces where individuals can work without being interrupted.

When teams have geographically distributed members, the team decides how much of their workplace is virtual and how much is physical. Technology such as document sharing, video conferencing, and other virtual collaboration tools help people collaborate remotely.

Geographically distributed teams need virtual work-spaces. In addition, consider getting the team together in person at regular intervals so the team can build trust and learn how to work together.

Some techniques to consider for managing communication in dispersed teams are fishbowl windows and remote pairing: Create a fishbowl window by setting up long-lived video conferencing links between the various locations in which the team is dispersed. People start the link at the beginning of a workday, and close it at the end. In this way, people can see and engage spontaneously with each other, reducing the collaboration lag otherwise inherent in the geographical separation. Set up remote pairing by using virtual conferencing tools to share screens, including voice and video links. As long as the time zone differences are accounted for, this may prove almost as effective as face-to-face pairing.

A good idea is to form teams by bringing people with different skills from different functions together. Educate managers and leaders about the agile mindset and engage them early in the agile transformation.

Beware of Organizational Silos

The best place to start when forming agile teams is by building a foundational trust and a safe work environment to ensure that all team members have an equal voice and can be heard and considered. This, along with building the agile mindset is the underlying success factor—all other challenges and risks can be mitigated.

Often, siloed organizations create impediments for forming cross-functional agile teams.

The team members needed to build the cross-functional teams typically report to different managers and have different metrics by which managers measure their performance.

Managers need to focus on flow efficiency (and team-based metrics) rather than resource efficiency. To overcome organizational silos, work with the various managers of these team members and have them dedicate the necessary individuals to the cross-functional team. This not only creates team synergy but also allows the organization to see how leveraging its people will optimize the project or product being built.

As an agile project leader, first focus on how you can create a team that is cross-functional and 100% dedicated to one team.

Even if it means just getting key team members, such as the developers and testers, to work and communicate together on a daily basis, that is a step in the right direction toward agility.

Want to Pass Your PMP 2020?