I frequently get asked about the dynamics of building agile organizations from an organization structure point of view.
The most important point is that you don’t create a high-performance agile organization by the defined structure. Managers don’t do it; neither do VP’s or Directors.
Surely we set the stage. But the teams are the ones that create the organization. We don’t have to optimize the structure for every technical hurdle or risk. Or create a structure that perfectly balances skill-sets and experience across all functional roles.
Whew! I’m glad, because I never figured out how to do that perfectly anyway.
We simply pull together a reasonable view to structure and attempt to be as balanced as we can be. Then we form the teams, provide some intelligent constraints, get out of their way, and allow them to grow & perform. It’s as simple as that!
Over time, the teams learn and adapt and will suggest changes. We need to be supportive of the insights & learning, and help them adjust structures for increased productivity, quality, and value-based delivery.
What I thought I’d share in this article are some of the personal guidance I’ve developed for myself and my leadership teams when I’ve “built” agile organizations.
Remember, these aren’t guaranteed rules, just things that I’ve found very helpful in setting the stage for enabling great agile teams to emerge.
Self-Directed, Cross-functional Team
First of all, we have a responsibility towards creating self-directed teams. These are teams that are composed of a cross-section of skills and capabilities to implement their Product Backlogs – the work the teams will be given.
Beyond raw technical skills, experience also comes into play, especially from a business domain perspective. For example, I usually try to place a more experienced engineer on each Scrum team who has the technical chops in the areas the team will be exploring. Sometimes we refer to them as a Technical or Team Lead or similar title. The title though isn’t what’s important. What’s important is that we have inserted a seasoned and experienced person on each team.
But it’s never perfect
I think we’ve all realized though that there will always be constraints. You might not have a particular skill-set in house or enough testers to go around. I think our job as leaders is to wisely distribute the skills we do have in a fair and balanced way across a set of teams. We should make this process as transparent as possible to our teams. And, if we have discovered gaps, we need to share our intentions and plans to fill those over time.
One way to handle these short-term gaps is splitting or sharing folks across teams. While not optimal, sometimes it’s all we can do.
Oh and, ask the teams for feedback
Oh and one more thing. I always suggest vetting your proposed organization alignment and team structures with your team members. They’ll ask questions, provide feedback, and even raise issues that you never thought of. It will help you better align your initial stab at teams.
But beyond that, it will increase the understanding of the teams as to your “design choices” and help to create buy-in when you roll out your teams.
Distributed Teams – Good?
Let’s make one thing perfectly clear – distributed teams are hard. They’re out of the “sweet spot” of agile team construction, that is: co-located and cross-functional teams.
Does that mean you can’t make agile approaches work in distributed teams? Of course not. But it does mean that you should adjust your thinking when it comes to setting up the teams. Here is my baseline guidance:
- As often as possible, keep teams entirely together. Even if that means you have to make some skill-set, budget, or strategic compromises.
- If you do have to distribute a team, try to do it intelligently. For example, try to keep the developers together in the same place…or the testers. So they can have a modicum of teamwork.
- Sufficiently invest in tooling that will foster collaboration. For example, development tools, agile tools, video conferencing, interactive sites, etc. Let your team(s) explore and define their needs and simply respond to their requests.
- It’s actually quite hard to have a Scrum Master or Product Owner who is separated from their team. If you must do this, consider asking someone on the team to serve as a local “liaison” for the remote person to “connect to”.
- Invest in getting the entire team together at the beginning of the project (charter / initiation). Do some training, team building, and run the first sprint as a localized team. This will pay huge dividends longer term.
- Make sure you allocate sufficient funding for frequent team member travel to/from your different sites.
And I think most importantly, coach your teams to really invest in solid agile teamwork and collaboration practices no matter the distance. For example, the team needs to commit to daily stand-ups, backlog refinement, and sprint planning AS A TEAM no matter how challenging the time and/or cultural differences.
And one final point, you’ll get your best results with co-located, self-directed, cross-functional agile teams. So whenever possible, consolidate your distributed organization towards this goal. In other words, be relentless about moving your teams closer together over time.
Part-time Team membership – Good?
I often get asked can you have part-time team members on a solid agile team? I think the correct answer is...it depends, but I try to avoid the situation as much as possible.
If for example, everyone on a given team were at 50% availability, then I’d say it’s a terrible idea. We’d clearly need some team members to be fully engaged and focused on the tasks at-hand.
But if you asked me whether we could have a part-time performance testing person on a team? I might say yes. Or whether a part-time technical writer can be on a team? Again, it might make sense.
In my mind there are two reasons to have shared or part-time people assigned to Scrum or Agile teams. First, they might have specialized skills that aren’t’ needed full-time on every team. A good example of this would be a technical writer. The second reason is the ebb and flow for some specialized folks.
For example, I made the mistake once of placing UX folks full-time across a group of Scrum teams. The end result was that they couldn’t effectively deliver on many aspects of their jobs because the focus of the teams was on feature execution and the UX folks needed some time for design “look ahead” and research.
We ended up connecting them part-time to the teams when needed and this created a much more effective balance for them.
Do we really need a Scrum Master?
For someone as wordy as I am, the short answer is yes. I even recommend that organizations find a Scrum Master-like person (a coach) for new instances of Kanban. This role, if staffed with the right people and done well, is a game changer in accelerating new agile adoptions.
Do they need to be certified? Perhaps not, but they need experience in lieu of or in addition to certification.
Can you do a “time share” with an internal team member as a Scrum Master? Sure, you can do anything you wish. But I’ve found that part-time (or multi-tasked) Scrum Masters aren’t a good idea. I much prefer to invest in professional and experienced Scrum Masters. And, if ‘m running short of funding, I’ll overload them a bit with two teams each.
Not finding/hiring/training Scrum Masters in your organization is one of the most shortsighted cost decisions you can make when you’re planning for your agile transformation. Yet, I see it all of the time - sort of a penny wise and pound-foolish mistake.
And while I won’t get into it much here, taking that approach with Product Owners is potentially even more dangerous.
Team Size
When considering team size, one of the first things I think about is the general Scrum advice of teams in the range of 7 +/- 2. I’ve found that to be sound size advice for forming agile teams.
I’ve also found that even within that range, smaller is often better. For example, in my experience teams of 5-6 people are a sweet spot from a productivity and efficiency perspective. I’ll give you an example:
I once worked at a company called ChannelAdvisor as a Director and Agile Coach. We had one team that had grown to about 12 individuals. We were growing as a company and we had a habit of growing our Scrums teams with new hires and then, when they reached a certain size, we would split them.
This team was working really well, but it was large. Before we could naturally split it, a business priority shift happened and we split the team to double our focus on another business initiative. So we split them into two teams of six. I’ll never forget this example.
In the first sprint of the original team, their velocity only took a marginal impact, 1-2 points. So we had literally cut them in two, BUT their velocity didn’t reflect a change. How can that be you might ask? We determined that reducing the team from 12 to 6 individuals simplified the communication and their effectiveness – to the point where half the team was nearly as productive as the larger group.
I try to keep teams as small as possible and still contain the requisite skills to get the job done.
Team Cohesion – Does it Matter?
I’ve encountered organizations that move team members around from team to team as if they’re playing a game of musical chairs. Sure, there’s always a reason for it. Often something like – this project is late so we’re reassigning more team members to the project for the next 30 days to recover it.
The people are treated like commodities or as if they’re fungible. They’re not by the way and I’ve written about this before. But that doesn’t seem stop us from treating them as if they were.
The impact of this can be severe – especially within agile teams. When I’m in a leadership role in an agile organization, the last thing I do is disrupt the cohesiveness of my teams. I consider well-formed, high-performance teams to be a critical aspect of my delivery proposition.
It takes so much time to build a cohesive team that I wouldn’t think of changing it willy-nilly.
So the answer to this question, and I know you realize it to, is YES team cohesion and stability matters. Try to keep your teams together as long as they’re healthy and performing, even when the business pressure is on.
Sitting Together
There is an incredible amount of debate surrounding how to setup your team areas for collaboration. One extreme is to keep team members in cubes or offices that separate individuals and impede teamwork and collaboration. The other extreme seems to be “throwing everyone” into a large room at a single table.
Both of these have a grain of truth in them and the goal should be somewhere in between the two. There is a relatively old convention or tactic within the Extreme Programming community called “Caves & Commons” that makes the point well. It implies that agile teams need both – “caves” for private, individual immersion and work and “commons” for collaborative work.
I believe the best spaces (and team dynamics and results) include both types of space for the teams’ use.
I’ve written about this “space dilemma” before in another article. And the following InfoQ article does a nice job of exploring the options as well –
http://www.infoq.com/articles/agile-team-room-wishlist
Identity & Ownership
I have two loose rules when I’m trying to guide and determine what teams work on. First, I work with the business, Chief Product Owner and the PO team to decompose the business products/projects towards a meaningful set of focused themes.
Then I try to staff the teams to align with these Product Backlog themes. Clearly each stream gets a Product Owner. Not only do I want the team to be staffed in order to successfully deliver on the business expectations, but I want the backlog stream to enable their having an identity and end-to-end ownership of all of the work. By that I mean they own the maintenance, feature development, technical evolution, and future release roadmap for their product or feature area.
I’ve found that giving each team a sense of holistic identity and ownership is key to establishing team empowerment, ownership, and ultimately delivering great results.
Wrapping Up - 4 Biggest Mistakes
To wrap-up this discussion, I believe there are four primary mistakes that most organizations make when building their initial team structures for agile execution:
- Not engaging their teams in the organizational modeling process;
- Not viewing their organizational modeling as an iterative, learning process;
- Not applying appropriate training and staffing of their SM and PO roles;
- And not leveraging the opportunity for change, at all levels, that an agile transformation offers.
I’ve had the wonderful opportunity of creating a few high-performance agile organizations. The advice I’m sharing in this article isn’t theoretical or academic. It’s based on my own hard-won experience and realization of what works. And yes, I realize how challenging some of my advice will be for most leaders.
Nonetheless, I stand by it and hope you try it. I promise you it will be worth your efforts.
Stay agile my friends,
Bob.
This is an article by Mike Cottmeyer that takes a different approach to constructing your teams. He’s looking at alignment to various business dimensions. I don’t agree with some of the intent behind it, BUT it is an interesting read related to my articles theme.
http://www.leadingagile.com/2015/02/what-is-an-agile-team-and-how-do-you-form-them/