Introduction

Velocity Partners clearly provides experienced nearshore teams who are steeped in agile experience. We don’t just talk about agile or pretend to be agile, it’s in our culture and DNA. That being said, we often get asked about team structures when we’re engaging new clients. What are our ‘models’ for engagement? What does a typical team setup look like? And, of course, how much does it all cost?

I thought it might be helpful to answer some of those questions from a real-world example perspective; particularly because there is some flexibility in models and approaches. This article is focused on sharing nearshore models that I have personally seen work well. I will defer cost discussions to our Managing Partners 😉

Context

In 2009 I was working as the Director of Software for a company that provided a SaaS, e-Mail marketing tool. That company was iContact and we competed with the likes of and .

I had personally been leveraging agile methods, Scrum mostly, for nearly a decade at the time, so I was fairly passionate about that approach. iContact had gone “all in” on Agile, not only within the technical groups, but across the whole company. And it had become a true differentiator for us in our customer growth.

But we were growing so quickly in our technical teams that we realized we couldn’t fuel that growth solely from our local area. Not, and continue to hire the caliber of staff that we were looking for within our agile teams. Se we began to look for an outsourcing partner that not only provided outstanding skills, but who shared our agile principles and deeply understood what it meant to operate as an agile organization and develop high-performance agile teams.

I’m going to use Scrum terminology here because it’s so common. But many, if not all, of the principles would apply if you were setting up agile teams of any form (XP, Kanban, Hybrid, SAFe, etc.).

Whole Team View

When I approached Velocity Partners, my vision for the engagement was not staff augmentation in the traditional sense. That is, cobble together some of their engineers with our own team just trying to fill in our recruiting gaps. I’m not implying this is a bad approach, just not nearly as effective as I wanted us to be.

In my experience, distributed agile teams deliver the most value when they’re, well, a team. A team that is co-located and operating largely autonomously and in a self-directed manner. A team that is reasonably skilled and collaborative. And a team that isn’t disrupted by rotating team members off and on.

So from my perspective, I was looking for a firm that could provide me with entire outsourced Scrum Team(s). That model would include:

• A Scrum Master
• A technical team leader (less title or attitude, but more so in skill)
• A healthy mix of experienced Developer(s)
• And a healthy mix of Tester(s)

The team would have the requisite skill-sets to deliver end-to-end User Stories that were fully demonstrable at the end of each sprint. And it would be aligned with one of our onshore, Product Owners to deliver on their Product Backlogs goals and objectives.

It was important to us to grow our capacity “in teams” rather than headcount or “resources”. We wanted to deal with people and create a sense of empowerment and ownership with our offshore teams, just as we tried to do with our internal teams. In essence, we didn’t want to differentiate much (at all) between our on vs. offshore teams.

Why Nearshore?

In three words – collaboration & lean interaction.

Collaboration is an essence of agile effectiveness, so time zones and team separation matters when you’re trying to build high-performance agile teams.

I found the 1-2 time zone difference to be incredibly compelling when considering the 4-12 time zone differences I’d been accustomed to in previous outsourcing experiences. Another way of saying it—it is incredibly difficult to impossible to achieve agile teamwork in teams that are in China or India when you’re based in North America.

Does it sort of work, perhaps. But you inevitably miss out on real-time communication and lean throughput when you have this wide of a communication and collaboration gap in your team.

Why South America?

In two words – culture & attitude.

I’ve done an incredible amount of offshore development in my software leadership career. Probably the biggest challenge I’ve faced is the cultural integration of the teams. For example, in many cultures you simply don’t challenge or disagree with your customers. Instead you basically do as you’re told and deliver to the plan—no matter what and even if you’re building the wrong thing or building it poorly.  What’s up with that?

Thank goodness for the agile mindset and the focus on the customer, value, and quality. What I’ve always wanted in my offshore teams is the professionalism, courage, and willingness to engage with me as a partner. To work with me to create the best products by solving our customer challenges simply, elegantly, creatively, and innovatively. I want the mindset of my offshore teams to essentially be the same as my internal teams.

From my perspective, you get that with South American teams and I can’t begin to articulate the difference that makes to the bottom line.

Velocity Partners – Team

As the diagram represents, we “wrap” each team with a supporting structure and some specific roles and responsibilities. Often our clients view this as overhead, particularly from an agile perspective. However, it’s much lighter weight in practice than it appears here. Let me explain the roles and the interactions that help deliver excellence from our and your teams.

Customer Roles

Product Owner:  In nearly all situations, we’re looking for our client to define a Product Owner in the classic Scrum sense of the role. This would be someone to define a Product Backlog, define priorities, service business domain questions, and ultimately approve the work the team delivers.

The more the Product Owner shares mission, vision, goals and directional awareness to our team, the better the results. As the team partners with the Product Owner to solve customer problems rather then deliver a by-rote list of features.

Technical Liaison:  Is often an optional role. When we first engaged Velocity Partners teams at iContact, we didn’t have this role. Instead, we brought several team members on-site to work with our teams for 4-6 weeks. That served as sufficient training for them and then they went back home to bring that technical knowledge to the remainder of the team.

Sidenote

Later at iContact, as we matured in what we asked our nearshore team to accomplish, we found that our their team lead needed to be augmented by onshore expertise. Therefore, we “assigned” 2-3 onshore team members to the nearshore team This was driven by technical domain experience. We felt so comfortable with our nearshore team lead that our onshore folks truly became a part of that team and fell under their leadership, so as to not break the wonderful teamwork model we’d established.

Velocity – U.S. Roles

Senior Partner – Engagement Oversight:  Every client has a Senior Partner who is ultimately responsible for their overall engagement. This isn’t simply a pre-sales role, but an ongoing one. When I was at iContact, Brian Estep was my Senior Partner. He would check-in periodically, participate in retrospectives, and serve as an escalation point for any questions or challenges. Other Senior Partners include: Peter Stroeve, Barnaby Sheridan, and Steve Macmillan.

Senior Partner – Nearshore Operations:  This role is currently filled by Barnaby Sheridan. Effectively Barnaby is in charge of all engagements and teams. He conducts many of our on boarding efforts and collaborates in our Sprint #0 and Best Practices workshops.

He works with nearshore leadership to ensure we’re effectively balancing across all of our clients needs, maintaining our high skill levels, and our agile discipline. He is the operational “go to” person for our Senior Partner team.

Velocity Nearshore

Solutions Manager:  Is a role that is unique to Velocity Partners. We take some of our more senior engineers and agile practitioners, and ask them to assume this part-time role for each agile client team. The role is fixed at 15% of their capacity per engagement and team.

The role has essentially a four-fold responsibility:

1. Serve as a technical solutions sound board for the team;
2. Provide an escalation point for assistance in risk mitigation;
3. Provide coaching support for x-team;
4. Serve as a “connection” to client leadership and technical resources.

Team Lead:  Each Velocity Partners team has at least one team lead caliber engineer assigned to it. Often these folks are technically sound, but also have strong leadership capabilities. Point being—they are seasoned and experienced. The often serve as the nearshore Scrum Master for the team as well.

Between the Solutions Manager and the lead, the nearshore team has experienced and nuanced leadership to provide support and guidance.

Wrapping Up

My intent in this article was to share some insights into the Velocity Partners model based on my own direct experience. Is this the only way to engage them? No. But in my humble opinion, it’s the best way to do it because of the alignment with solid agile principles and practices.

If your considering Velocity Partners to augment your teams and increase your capacity, surely you’ll get a chance early on to craft a structure that will work for you. My hope is that you’ll consider my example in your thinking.

Stay agile my friends,

Bob.