Tactical scaling factors.
This article is organized into the following topics:
- What is organizational distribution?
- Strategies for working with outsourcers
- Procuring Agile Services
- Being an Agile Customer
- Being an Agile Vendor
What is Organizational Distribution?
Organizational distribution is a tactical scaling factor that addresses the issue of how homogenous your team is from the point of view of what organizational unit, or what company, people come from. On the most desirable end of the spectrum having everyone come from the same group or division within a single organization is often the easiest situation that you’ll face, whereas at the other end of the spectrum the hardest is often having outsourced much of the work to other companies. The following table overviews common levels of organizational distribution and the potential risks that you face because of them.
| Level of Organizational Distribution | |
| Single Division – Everyone works for the same group/area within a single company/organization. | |
| Single Company – Everyone works for the same organization but people from multiple business divisions/areas are involved. | |
| Contractors – Some of the people on the team on contractors working for another company (such as an IT services company or a Design/UX company). These people are typically “on site” in a similar way that full-time employees are. In the case of geographically distributed teams, the full time employees (FTEs) and contractors are geographically distributed in similar ways (e.g. you can’t tell that some is an FTE or a contractor simply by knowing the location at which they’re working). | |
| Outsourcing – Some, or even most, of the work is outsourced to one or more services providers. |
Very often organizational distribution and geographic distribution go hand-in-hand.
Strategies for Working with Outsourcers
Three issues:
Procuring Agile Services
It starts with procurement. If you want a service provider to provide a team that is capable of working in an agile manner then that is what you need to procure. A traditional procurement process that is looking for a team to work from a detailed requirements specification up front, that is expected to focus on development and then hand off their work for another team to perform “final testing”, is pretty much hobbled from the very beginning. It is very possible, and highly desirable, to have a procurement process that is capable of procuring agile software development services. In fact, there is a wealth of knowledge out there about agile contracting if you choose to look into it.
Being an Agile Customer
The customer must work in an agile manner. There are several key strategies to support this:
- Negotiate how you will work together up front. Goes beyond procurement
- Take a light-weight, evolutionary approach to requirements. Big up front requirements will kill you.
- Provide a technical roadmap. The service provider needs to know your technical direction, standards, ….
- Fly a few key people to the service provider. F2F for key decisions, Big Room Planning, Architecture, … You need to understand their reality.
- Fly a few of their key people to you.
- Consider co-locating your Product Owner with the service provider. They need easy access to the PO, just like any other team. Otherwise, have a junior PO on their end who works daily with your PO.
- Provide your development guidelines to the service provider.
- Actively govern the team. Outsourcing is risky. Keep an active eye on what is going on. Regular demos (weekly), team dashboard, automated quality metrics, …
- Respect the service provider. They aren’t simply coding monkeys, or testing monkeys.
- Ensure they have a whole team.
Being an Agile Vendor
The service provider must work in a disciplined agile manner. There are several key strategies to support this:
- Be trustworthy. Regardless of the culture of your country, be truthful when answering questions. The greatest impediment right now for Indian outsourcers is the perception, rightly or wrongly, that when they answer a question the answer can’t be trusted. Most customers, particularly those in North America and Europe want to be told the truth, whether it’s good news or bad. Unfortunately, many Indian service providers will still tell customers what they think they want to hear, instead of what they think they need to hear.
- Be truly transparent.
- Have one-week iterations/sprints.
- Include code analysis tools in your builds.
- Provide the customer access to your team’s automated dashboard.
- Align your culture to that of the customer. A significant challenge with outsourcing is the different cultures of the customer and the service provider. It is the responsibility of the service provider to align their culture with that of the customer – you will work with a German company differently than an American company and differently yet again with a UK-based company.