Webinar
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.
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.
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.
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!
You might be wondering—where is the project manager role?
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!
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:
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:
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.
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 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.
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:
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.
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.
We’d be happy to provide a bespoke 1:1 demo on how Cloud Coach can benefit for your business.
