Time and time again, when I’ve observed organizations undertaking an Agile transformation, team structures get overlooked and underestimated. Many organizations think they can just use Agile practices without thinking about reorganizing teams.
Unfortunately, they’re wrong.
Fortunately, there is something they can do to fix this.
As a corporate learning designer and certified Agile trainer who has helped companies like Walmart, Google, American Express, AT&T, and USAA implement Agile transformations, I’ve seen firsthand how traditional team structures affect the process.
Below, I’ve laid out just what problems companies tend to encounter when they continue to rely on traditional team structures during an Agile transformation, as well as what you can do to prevent them.
At the risk of being obvious, traditional team structures aren’t Agile. This is because they aren’t able to bring a project to full completion totally on their own. Instead, they require handoffs to different teams or departments.
Handoffs aren’t just like the telephone game, they are the telephone game. Each time you have one you create an opportunity for miscommunication, delays, and outright blockages. Reducing handoffs is critical for Agile to work properly.
To better understand the problem, imagine your strategic goal is to design and build a car. You’ve got teams to figure out the aerodynamics, to design the interior, to design the software, to figure out the marketing, and yet more teams to build or implement all of these components.
In the best-case scenario, these teams have to spend an enormous amount of energy synchronizing between each other. In the more likely scenario, a tremendous amount of time and energy is wasted because these teams don’t know what their colleagues are doing. It turns out that the interior design doesn’t match the exterior, the software experience doesn’t fit with the story marketing wants to tell about the car, etc.
Alongside those issues, potential insights into how the various systems of the car can better work together are lost because each team is only focused on their area of expertise. Another way of putting it is that traditional teams function as silos. Each team is only responsible for one component and isn’t thinking about the overall end goal.
In contrast to traditional teams, Agile teams should be a cross-functional, self-sufficient unit. Instead of handing work off to the design team, for example, the team will have a designer on it. This means that they are capable of beginning tasks or projects to 100% completion without the need to do any handoffs or work with external people.
Instead of a designer suddenly getting a brief and trying to understand the overall goal of a project they just heard of, they’re integrated in that project. They know how their role is critical to the overall success of the project and are less likely to misunderstand their brief and do work that doesn’t contribute to the project’s success.
That increased visibility also means it’s far more likely that the designer is ready to do their work on the project when it’s needed. They have full visibility of their work pipeline and regularly communicate with their team members about what’s happening with the project.
Agile practices weren’t just built for these types of team structures, they actually require them to unlock the full benefits of systems like Kanban or Scrum. If you try to implement Agile without these team structures you risk building a beautiful Kanban board that only shows you that you’re blocked all the time.
The best way to go about it is to start small. Find one team and one project where you feel you have the right mix of people on the team to function independently and fully complete a project. Give them the opportunity to figure out which Agile methods they would like to use to bring that project to completion.
This starts with listening. Instead of simply coming in and deciding what the ideal makeup of each of these cross functional Agile teams should be, ask people what they need to complete their work. It’s essential that the way these teams are put together and function reflect the reality on the ground and not a reality imagined by managers.
That commitment has to continue through implementation. Internal leaders must be committed to this approach and keep their eyes open to identify cases when teams need adjustments. Those adjustments are likely going to happen over time anyways as needs evolve within the organization. But that’s a part of Agile, you always need to be ready to adapt.
If you want to go even deeper on cross-functional Agile teams, the AgileSherpas blog has some great resources you can use:
Agile implementation takes time, particularly when you’re also trying to convince an organization to abandon traditional team structures and silos. That’s why getting training, buy-in, and a general understanding of why team structures need to change are all so critical. However, once you have these things in place and have implemented a pilot program, you can start to think about scaling.
At this stage, you can determine whether you need another pilot team to iron out the kinks before potentially adding more and more teams. Ideally, once you have a successful cross-functional Agile team things can snowball (in a good way), allowing Agile ways of working to gradually take over the department and then the organization.
Starting small like this is so important because it’s unlikely you have the people you need to transform your entire organization into self-sufficient Agile teams. However, you probably have the people to create at least one such team.
In the long run, you’ll be far better off with one successful Agile team as opposed to an entire organization of unsuccessful ones. This approach also gives you more time to iterate and figure out how to best implement Agile based on your unique needs. This helps ensure you can stay Agile over the long term.
One thing to bear in mind is that while Agile transformations require Agile teams, that doesn’t mean both are one-size-fits-all. Getting the right training, and advice from experienced Agile coaches makes all the difference. We can spot problems coming down the line and help you avoid them.
That’s why I recommend you use Agile marketing training and coaching to leverage the right experience to improve your chances of Agile transformation success.
Speaking of transformations, why don't you take a minute to see how ready you are with our Agile Marketing Transformation Checklist?