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.

Wrapping Up

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.

In part two of this article, we will continue to explore more consideration factors for your agile team building efforts.

Stay agile my friends,

Bob.