Solutions

Customer Onboarding
Capabilities include project timelines, resource management, and stakeholder collaboration.

PSA
Manage, track and enhance your project delivery processes efficiently.

Customer Success
Manage account goals, tickets, and stakeholders while gaining full customer journey insights from onboarding to renewal.

Project Management
Everything you need to run your projects on Salesforce. Choose from Waterfall, Agile or Water-Scrum-Fall, track time and use repeatable project templates.
Features

Customer Health

Resourcing

Reporting & Dashboards

Timelines & Collaboration

Time Entry

Meeting Automation

Financials & Billing

Productivity
Why Cloud Coach
Customers
Resources

Library

Blog

Videos

Partners

Competitor Comparisons

Articles
Book a Demo

A CLOUD COACH ARTICLE

How to Create an Agile Workforce

The decision to embrace Agile project management comes from the top. And while executive leadership might make the decision, it’s up to the entire company to implement it. The first step in adopting an Agile approach is therefore to assess the current organizational culture and potential buy-in to this new philosophy.

The harsh reality is that if either management or company culture will not support the Agile approach, it would be a lost cause to pursue it.

Building Agile Teams

Transitioning to Agile project management is not about introducing sprints and firing all your managers. It’s more nuanced and, if your new Agile team is going to survive and thrive, it must be handled with care and attention.

First you need to decide what type of Agile structure best fits your team or organization. Then you need to plan each role—including whether to re-assign existing employees or recruit new talent—and establish clear responsibilities for each of those roles.

Below, we explain each of these structures in more detail.

ADDITIONAL LINKS

Different types of Agile structure

As with most aspects of Agile project management, there is significant room for flexibility when it comes to your team structure. However, it’s generally accepted that there are 3 broad categories to which most teams conform:

Generalist—This is arguably the most flexible structure, because it basically means that no one in the team has irreplaceable specialist skills. Within a sales team, for example, you’ll find multiple reps who can easily “sub in” for one another if the need arises, applying their core sales knowledge to different sectors.

Specialist—Specialist teams are the opposite: every member has highly-valuable and niche skills, allowing the team to deliver complex projects. Each member is exclusively responsible for all tasks within their domain. While powerful, specialist team members will sometimes be sidelined during project phases where their skills aren’t required. Specialist structures are most common in large organizations with enough diversity of work.

Parallel—Here every team member changes tasks between sprints. The most common example is having everyone developing software for one sprint, then all transitioning to testing for the next. These teams naturally require diversely experienced employees and it’s a structure that can only be deployed for very specific types of projects.

Agile roles & responsibilities

One unique aspect of Agile is the way in which it handles roles, responsibilities and job titles. In this section we’ll overview the most common roles, but we should note that it’s entirely flexible depending on your organization and the Agile methodology you’ve chosen. Kanban teams, for example, rarely apply specific roles at all!

Team lead or Scrum Master—Fundamentally, the team leader exists to serve the team members and give them the best possible platform for success. They facilitate communication, ensure the team follows proper Agile values, and acquire any resources teams need to perform optimally. They are not project managers.

The equivalent role within Scrum teams is the Scrum Master.

Product owner—They are the voice of the customer. This role is about maximizing the value produced by the team. This will include prioritizing the team backlog, defining the goals of each sprint, and making sure the customer’s needs are consistently met. They will be communicating frequently with every stakeholder and team member involved in the project.

Team member—Team members complete the actual tasks that make up a successful project. They are the engineers, salespeople, developers, and designers building your product. The exact roles & responsibilities of these members varies significantly between organizations and projects.

Stakeholder—One of the crucial differentiators with Agile is how closely teams work with the client and stakeholders. This collaboration is so significant that it’s usually defined as a role within the team; stakeholders will regularly review progress and deliver feedback, helping inform and shape the project over time.

You might be wondering—where is the project manager role?

Agile project management…without a project manager?

The traditional project manager is something of a relic in the Agile world. A flat team structure and self-organization are central to the methodology, and so the traditional manager—prescribing tasks, managing scope, monitoring cost and progress, assessing workload—doesn’t really fit in.

But yes, we insist that this is still a powerful project management philosophy. As you may have gleaned, the most crucial traits of the project manager are largely absorbed by the other roles.

For example, assigning tasks is a collaboration between the product owner and team member. Scope and scheduling belong to the team lead.

What about larger teams?
We’ve seen that Agile teams (especially those using the Scrum methodology) can be scaled massively with great success—up to teams of hundreds or a thousand. At this magnitude, there must be an additional element of project coordination to keep everything stable and on-track.

At this level, some sort of project manager role might be created. Once again, their responsibility would not extend to allocating tasks. But communicating with external stakeholders, managing risk and generally coordinating project efforts could be invaluable.

Don’t expect the term project manager to ever make a resurgence in Agile teams, however—that word is a pariah for Agile workers!

What to look for in a product owner

The product owner’s job is to make sure that your customer gets the best and most valuable product possible. As you can imagine, this is a demanding and extremely important role. While the specific remit of your product owner might vary, there are a few common traits held by successful product owners:

Knowledgeable—When team members have questions, they come to the product owner. That means they must have extensive and reliable knowledge of the product vision, stakeholder requirements and the ability to distinguish “must have” features from the “nice to haves”. They will also be knowledgeable about the current tasks being undertaken by team members and their context in the broader project.
Available—Agile teams work in rapid iterations. When team members have questions, they can’t afford to sit around waiting for replies—they need to come fast. Slow communication will cause bottlenecks or result in less desirable outcomes for the customer.
Authoritative—Despite the multitude of customer representatives and stakeholders, it is the product owner’s sole decision as to which features are built and which are ignored. Prioritizing the backlog with authority is crucial for success.
Communicative—The importance of face-to-face communication in Agile teams has been emphasized since its inception. The product owner must be comfortable with one-to-one conversations, delivering feedback, running sprint reviews, and of course maintaining strong and open relationships with stakeholders.
Proactive—An integral part of the product owner’s role is liaising with stakeholders, asking perceptive questions and getting laser-focused on exactly what they need or want. That requires significant effort: a brilliant product owner is relentless in understanding product needs.

What to look for in a team lead

The team lead is a very different role. Their goal is to ensure the Agile methods are properly followed and that team members have whatever they need to deliver their best work. Common traits of team leads include:

Openness—An Agile team lead is at the disposal of its team members. It’s their job to openly promote the Agile philosophy, raise issues and promote transparency within the team.
Collaborative—Collaboration is at the heart of the Agile philosophy. You should expect the team lead to proactively seek out opportunities to talk with team members and facilitate cross-functional efforts.
Resilient—An inevitable part of leading Agile projects is dealing with scope changes and roadblocks. Resilient team leads will thrive under the pressure and be optimistic in finding solutions to problems.
Flexible—A good team lead doesn’t assume their ideas are always the best ideas. They take advantage of every opportunity to collaborate and get everyone’s perspective. When a better way to do something is discovered, they throw their weight behind it.

Team player—Ultimately, the goal of the team lead is to empower the team. Anyone whose first motivation is their own success or wellbeing is not suited to this role.

Organizational Culture and Buy-In

Now that we’re clear on what an Agile workforce actually looks like and the roles involved, you might want to leap into action. However, before re-assigning roles and hiring a product owner, you need to understand the culture of an Agile team and assess whether your organization can successfully make the transition.

What does an Agile culture look like?

What we’ve looked at so far—the founding principles of Agile and the success of its implementation—are obviously attractive. However, simply saying that you’re “adopting Agile” into your organization is not enough.

There are several characteristics that apply to all Agile teams, whether it’s in traditional software development or another application.

Teams are non-hierarchical
While every team member has a defined role and clear responsibilities, the “flat” management structure of Agile projects allows them to tackle those responsibilities autonomously, in the best way they see fit. They can self-organize without layers of tight management interfering.

Teams are cross-functional
Each team member is an expert in their area, and it’s the proactive collaboration of this expertise that allows Agile projects to be so fast and successful.

Teams experiment
A core part of Agile is innovating new ways of doing, thinking and executing. Agile teams are encouraged to experiment in order to fuel that innovation. One way of doing this is to allow all team members to devote a few hours per week to personal projects—alternative interests which stimulate their creativity, which eventually translates back to project success for the company.

Teams are curious
Success as an Agile team often comes from challenging the status quo. But why are we doing it that way? Is that really the best approach to reach that outcome? This mindset should be encouraged as it unlocks countless opportunities for innovation.

Teams are committed to process excellence
Agile isn’t about being fast; it’s about making the best possible product. It’s paramount that all team members are totally devoted to producing the best work they possibly can, in every iteration.

Is your company ready for Agile?

There are 5 obvious steps that you can take to make implementing an Agile methodology as simple as possible. This means minimizing risks and potential roadblocks and keeping all stakeholders informed:

Inform all stakeholders that you will be adopting an Agile approach. Explain your high-level reasoning and the positive impact you expect this to have.
Give stakeholders the opportunity to voice concerns and receive in-person responses. This can be done through video conferencing and will help reveal (and overcome) barriers.
Ensure you have buy-in from all senior leadership, to present a unified front.
Keep stakeholders regularly updated with progress as your teams transition to this approach.
Constantly evaluate your progress, optimize and have teams share their findings for mutual growth.

One of the biggest barriers to successful adoption comes from stakeholders who oppose the decision. It’s therefore crucial to identify such individuals and work with them closely and personally to overcome these objections. Once future results have justified the change, these barriers should be largely obsolete.

If your company culture doesn’t “fit” with Agile

It’s only too easy to see why some companies would see the Agile philosophy as too exotic or “different”. Despite its proven track record, overhauling company culture is a serious undertaking. Some employees will be more amenable to the changes than others; as we’ll discuss in a later section, the idea of project managers being at the service of their teams remains a novel idea in many businesses.

The best thing you can do is introduce the concept early. Make sure leadership and managers are coached on the changes first, so subsequent employees always have someone to come to with questions.

And while it might be hard to hear, employees that are truly unsuited to the Agile methodology (e.g. those in favor of close micromanagement) may not have a long-term place in the organization.