Quando o Agile atende à terceirização

como as organizações de TI introduzem maneiras ágeis de funcionar , eles costumam entrar de frente para um modelo de negócios existente que parece incompatível: a terceirização tradicional. O modelo ágil, com seu forte foco no trabalho em equipe, freqüentemente se choca com o modelo de terceirização tradicional, que requer contratação com fornecedores cujas equipes são treinadas principalmente para seguir as instruções em vez de trabalhar em colaboração. Mas as organizações podem apresentar o Agile e continuar a terceirizar. Quando as empresas criam parcerias fortes com fornecedores, as organizações de TI podem se misturar interno e equipes de fornecedores em unidades coesas que alcançam desempenho inovador.  

To make the agile approach successful, IT organizations often assume that they must insource most of their development processes and forego sizable outsourcing benefits, such as reduced fixed costs and increased access to valuable skill sets. But organizations can introduce agile and continue to outsource. When companies create strong partnerships with vendors, IT organizations can blend in-house and vendor teams into cohesive units that achieve breakthrough performance.  

Introdução

Em um relacionamento de terceirização tradicional, uma equipe de TI “joga um projeto sobre a parede” para um fornecedor; O fornecedor, por sua vez, completa suas tarefas e lança o projeto de volta. Embora esse arranjo funcione bem para projetar projetos que usam o modelo de cascata, que determina que o trabalho em cascata de uma etapa para o outro, essa configuração falha quando encontra o processo de trabalho ágil. O Agile sustenta que uma equipe compartilha informações, resolve problemas, cria produtos mínimos viáveis ​​e falha rapidamente. E pede que os membros da equipe trabalhem como iguais e que recebam a flexibilidade de mudar de direção rapidamente. Para que o modelo ágil tenha sucesso, uma equipe não pode dar uma volta para outra; Os membros de ambos devem executar juntos. Essa abordagem, que chamamos de distribuída ágil, cria esquadrões compostos por funcionários da empresa e do fornecedor. Todos os membros da equipe participam como iguais e trabalham com uma mentalidade de uma equipe para entender as necessidades do usuário final e encontrar soluções. (Consulte o Anexo 1.)

Agile demands that an interdisciplinary team works closely together during agile sprints (development intervals of one month or less). Agile maintains that a team shares information, solves problems, creates minimum viable products, and fails fast. And it asks that team members work as equals and that they be given the flexibility to change direction quickly. For the agile model to succeed, one team cannot punt to another; the members of both must execute together.

To foster this working relationship, companies should partner with vendors, tearing down the walls and enabling agile team members to work side by side, whether virtually or physically, to achieve their goals. This approach, which we call distributed agile, creates squads that are composed of company and vendor staff members. All team members participate as equals and work with a one-team mindset to understand the end user’s needs and to find solutions. (See Exhibit 1.) 

Many organizations have formed productive and enthusiastic teams by taking this distributed agile approach, while sustaining the cost savings originally generated by outsourcing. (See the sidebar “Distributed Agile in Action.”) Getting started requires three steps.

Avalie os modelos ágeis distribuídos. Nós definimos três. (Consulte Anexo 2.) To create an effective partnership, a company and a vendor must begin by evaluating distributed agile models. We’ve defined three. (See Exhibit 2.)

nos primeiros modelos, os membros da equipe de dependência da empresa em que os planos da empresa 19h. semelhante, pois os proprietários de produtos (POS), mestres scrum e analistas de negócios estão no local em um dos locais principais da empresa; No entanto, todos os desenvolvedores e especialistas em garantia de qualidade neste modelo estão situados em um dos locais do fornecedor.

The second model is similar in that the product owners (POs), scrum masters, and business analysts are onsite at one of the company’s primary locations; however, all developers and quality assurance specialists in this model are situated at one of the vendor’s locations.

The third model specifies that only the POs are situated at one of the company’s primary locations, while all other members are situated at one of the vendor’s locations.

Observe que os POS são tipicamente funcionários da empresa, porque precisam estar próximos da empresa para entender seus requisitos e prioridades. O Scrum Masters e os analistas de negócios podem ser funcionários da empresa ou do fornecedor. E desenvolvedores e testadores são normalmente empregados pelo fornecedor.  

Determine a importância da colocação. Uma empresa que desenvolve um aplicativo móvel de compras domésticas sabia que era fundamental entender seus clientes em potencial, a fim de criar uma experiência de compra que atendesse às suas expectativas, de modo que a empresa exigia que o proprietário do produto e os principais membros da equipe coloquem no mercado-alvo. Outra empresa insistiu que seu aplicativo de pagamento ponto a ponto fosse desenvolvido por uma equipe onshore colocada, uma vez que os requisitos-e a concorrência-evoluíram rapidamente. Por outro lado, uma empresa que estava migrando sua plataforma de call center não viu a necessidade de colocação, porque a funcionalidade desejada, os requisitos e os pontos de integração foram bem compreendidos por todos. Colaboração. Some companies think that agile development mandates collocation, but the need for collocation depends on the project. A company developing a mobile home-shopping app knew that it was critical to understand its potential customers in order to create a buying experience that met their expectations, so the company required that the product owner and key team members collocate in the target market. Another company insisted that its peer-to-peer payment app be developed by a collocated onshore team, given that the requirements—and the competition—were evolving quickly. In contrast, a company that was migrating its call center platform saw no need for collocation, because the desired functionality, requirements, and integration points were well understood by all.

Choose the distributed agile model. Deciding on the most appropriate distributed agile model for each project or stage of development will mean understanding and accepting the relevant tradeoffs, particularly in terms of available expertise, costs, and collaboration.

A maioria das empresas prefere o primeiro ou o segundo modelo. Embora esses modelos sejam mais caros, as empresas podem aproveitar mais facilmente suas habilidades internas, experiência e conhecimento de negócios. Além disso, a maioria das empresas acha relativamente fácil configurar uma equipe em um de seus locais e não em um fornecedor, principalmente se o fornecedor estiver situado no exterior. No matter which model is chosen, companies and vendors will want to collocate the majority of their team members for two or three sprint cycles before moving core team members to their ultimate location full-time, given that teams need time to adapt to new collaborative practices.

Many companies and vendors choose a distributed agile model and stay with it, while others try the different models over time or make a selection on a project-by-project basis. Se os sistemas de uma empresa forem estáveis ​​e os processos em desenvolvimento não forem críticos para os negócios, por exemplo, a empresa poderá estar aberta a usar o terceiro modelo desde o início. Se os processos em desenvolvimento forem críticos, a empresa pode se sentir mais fortemente em começar com o primeiro modelo e apenas mudar para o segundo ou terceiro modelo à medida que a parceria se desenvolve. Tecnologias para aprimorar a comunicação e a produtividade da equipe. Como resultado, o gerenciamento do relacionamento da empresa-fornecedor é mais crítico do que nunca. Isso requer um contrato bem escrito e legalmente vinculativo-que estabelece claramente mecanismos de cobrança e métodos de governança, incluindo KPIs. Por exemplo, enquanto o relacionamento tradicional do fornecedor pode exigir um contrato de preço fixo para o desenvolvimento de um produto ou serviço predefinido, uma parceria exige um contrato que permita à empresa contratar efetivamente recursos do fornecedor por um período pré-ordenado.

The Partnership Approach

After the company and the vendor have agreed on a distributed agile model, they can set up their new partnership, which must have three interdependent parts: a new contract, new team practices, and tools and technologies to enhance team communication and productivity.

A New Contract

When companies and vendors partner with each other, they risk being locked into the relationship. As a result, managing the company-vendor relationship is as critical as ever. This requires a well-written, legally binding contract—one that clearly establishes charging mechanisms and governance methods, including KPIs.

The new contract must reflect the change in the company-vendor outsourcing relationship from a traditional one to a partnership model. For example, whereas the traditional vendor relationship may require a fixed-price contract for developing a predefined product or service, a partnership requires a contract that allows the company to effectively hire resources from the vendor for a preordained period.

Os KPIs também devem mudar. Os contratos tradicionais de fornecedores normalmente pedem medir KPIs, como o tempo necessário para corrigir um problema. O novo contrato deve permitir medir diferentes KPIs. Por exemplo: o fornecedor atribuiu as pessoas certas com as habilidades e a experiência certas à equipe? O fornecedor alocou o número apropriado de recursos dedicados e qual foi a taxa de atrito? Quão bem os membros da equipe colaboraram? E quanto trabalho a equipe abordou durante um único sprint? 

Práticas de novas equipes

A dinâmica de relatório em um modelo ágil distribuído é diferente daquele em um modelo de terceirização mais tradicional: embora ainda existam vários níveis de especialização e antiguidade, todos trabalham e contribuem para o mesmo produto. Várias práticas recomendadas ajudarão a suavizar o caminho.

Construa uma cultura compartilhada. A empresa deve treinar e incentivar seus funcionários - bem como os funcionários e liderança do fornecedor - para tornar essa mudança cultural um sucesso. Por exemplo, a equipe da empresa deve se referir a um esquadrão ágil como One of the most important practices in distributed agile is building a culture in which people share an understanding of agile principles and the role that each individual will play. The company should coach and encourage its employees—as well as the vendor’s employees and leadership—to make this cultural change a success.

The company’s employees, in particular, may have to learn how to change their behavior toward the vendor’s employees. For example, the company’s staff should refer to an agile squad as  A equipe; Usando termos como A equipe do fornecedor e A equipe da empresa reforça as diferenças e não a unidade. Além disso, os membros da equipe devem ser atenciosos um do outro. Por exemplo, se os funcionários do fornecedor estiverem no exterior, eles não devem ser os que sempre trabalham tarde; Em vez disso, os membros da equipe devem alternar ficar até tarde ou chegar cedo. Mesmo pequenos ajustes culturais podem fazer uma diferença estranha.

Facilitar a colocação. Pode ser particularmente importante durante os dois ou três primeiros sprints e pouco antes de qualquer entrega quantificável e quantificável. Alguns membros da equipe devem colocar durante todo o estágio inicial, e as equipes podem enviar embaixadores para visitar sites de empresas e fornecedores de forma recorrente. No entanto, depois que uma equipe está bem integrada, pode reduzir a frequência com que os embaixadores visitam. Quando não coloques, os membros do esquadrão localizados em diferentes fusos horários precisarão ajustar seus horários de trabalho para criar slots de tempo dedicados com uma sobreposição de três a quatro horas para que possam se comunicar com outros membros usando as ferramentas de videoconferência. desenvolvimento e divida o trabalho entre os membros da equipe. Essas cerimônias devem ser realizadas no momento em que todos os membros da equipe, mesmo aqueles em diferentes fusos horários, podem comparecer. Além disso, os membros da equipe devem ser treinados para entender que todas as reuniões são importantes. Em vez disso, a empresa deve garantir que os recursos do fornecedor tenham o poder de tomar decisões e avançar entre as reuniões, em vez de aguardar a permissão do PO. Se eles cometerem um erro, ele pode ser corrigido - principalmente, dada a natureza altamente iterativa do desenvolvimento ágil. Em nossa experiência, as empresas que capacitam os desenvolvedores a começar a escrever código com base em sua própria compreensão de um aplicativo, podem voltar ao PO com um protótipo, em vez de esperar por confirmação ou esclarecimento antes de prosseguir. Ferramentas básicas de colaboração para compartilhamento e mensagens de tela são os facilitadores mínimos para uma interação eficaz. As equipes também precisam de ferramentas de comunicação que possam reunir todos para discussões ao vivo. A empresa e o fornecedor devem, portanto, garantir que todos os membros de uma equipe estejam na mesma plataforma corporativa e que todos tenham acesso a equipamentos de áudio e vídeo de alta qualidade para conferências, bem como para ferramentas que suportam a escrita colaborativa e as sessões de comprovantes e os membros da equipe. Eles também devem ter acesso ao mesmo ambiente de desenvolvimento para construir, testar e implantar novos produtos e serviços. E as empresas devem estabelecer um pipeline de trabalho integrado que permita que os membros da equipe em diferentes fusos horários continuem trabalhando em produtos depois que os membros de outros fusos horários terminarem o trabalho do dia. Another important practice, no matter which model is chosen, is collocation. It can be particularly important during the first two or three sprints and just before any essential, quantifiable deliverables are due. Some team members should collocate throughout that initial stage, and teams can send ambassadors to visit company and vendor sites on a recurring basis. However, after a team is well integrated, it can reduce how frequently ambassadors visit. When not collocated, squad members who are located in different time zones will need to adjust their work schedules to create dedicated time slots with a three- to four-hour overlap so that they can communicate with other members using videoconferencing tools.

Make a full commitment. A team must be fully committed to all agile ceremonies, which take place biweekly to discuss progress, demonstrate projects under development, and divide the work among team members. These ceremonies should be held at a time when all team members, even those in different time zones, can attend. In addition, team members should be coached to understand that every meeting is important.

Empower vendor resources. If a vendor’s employees are unable to make their own judgment calls, progress will be slowed. Instead, the company should ensure that vendor resources are empowered to make decisions and move forward between meetings, rather than waiting for permission from the PO. If they make a mistake, it can be fixed—particularly given the highly iterative nature of agile development. In our experience, companies that empower developers to begin writing code on the basis of their own understanding of an application can circle back to the PO with a prototype, instead of waiting for confirmation or clarification before they proceed.

Tools and Technologies

Companies that implement distributed agile should use tools and technologies to enhance communication and productivity. Basic collaboration tools for screen sharing and messaging are the minimum enablers for effective interaction. Teams also need communication tools that can bring everyone together for live discussions. The company and vendor should therefore ensure that all members of a team are on the same enterprise platform and that everyone has access to high-quality audio and video equipment for conferencing, as well as to tools that support collaborative writing and whiteboard sessions.

In addition, all team members should have access to agile life cycle management tools, such as Jira Software, which will improve transparency and help track KPIs. They should also have access to the same development environment for building, testing, and deploying new products and services. And companies should establish an integrated pipeline of work that allows team members in different time zones to continue to work on products after members in other time zones have finished their day’s work.

A colaboração nem sempre é direta. Em um exemplo, uma empresa descobriu que os membros da equipe offshore estavam continuamente perdendo videoconferências com membros dos EUA-mas ​​não pelos motivos que esperava. Os membros offshore tiveram várias restrições práticas. Por exemplo, os membros offshore não podiam ficar até tarde para as videoconferências, porque a área ao redor do escritório não era segura à noite, e os membros da equipe não podiam se juntar a videoconferências em casa porque não possuíam a largura de banda da Internet necessária. A empresa e o fornecedor resolveram rapidamente esse problema pagando por conexões de alta velocidade na Internet nas casas daqueles que precisavam dele.

---

Implementando maneiras ágeis de trabalhar em toda a organização de TI é uma jornada - uma longa. O recrutamento de um fornecedor como parceiro para a jornada permite que as empresas transformem o desenvolvimento de TI, continuando a colher os benefícios da terceirização. Essa parceria ágil distribuída exige que uma empresa e um fornecedor cooperem em muitos níveis, aprendam com os resultados e se adaptem. Para aqueles que acertam, as recompensas são grandes, incluindo custos significativamente mais baixos, acesso a um grande conjunto de talentos com experiência em tecnologia e capacidade de trabalhar de forma contínua e rápida, mesmo em vários fusos horários. Heiner Himmelreich