Thiago Torricelly, (blog) que se considera o maior especialista ágil da sua rua😎 , trabalha na Dasa, maior grupo de laboratórios de exames diagnósticos da América Latina, 3º maior do mundo, tem vivenciado algumas boas experiências com agilidade e estrutura de times. Fiz algumas perguntas para ele e as respostas você confere agora! Desde já, agradeço ao Thiago pelas boas respostas! 

buzON: Thiago, na lata: Scrum ou Kanban?

Torricelly: Penso que uma discussão de Scrum vs Kanban, ou Java vs Python sem ter as variáveis do problema que se está resolvendo, se torna um debate de idealismo religioso e não algo racional sobre o que realmente é melhor para certa organização ou certo time no momento.

O mesmo tipo de discussão ocorre no campo de linguagens Java vs Python em que geralmente quem coloca em seu linkedin “Programador Java” está em desafios onde Java é muito bom e a sua resposta acaba defendendo o Java, e com toda razão. O mesmo pode ocorrer com um desenvolvedor Python atuando em um produto de Data Analytics. Quem está certo? Os dois!!

A resposta para perguntas dessa natureza depende de quais problemas se está resolvendo, tamanho da organização, cultura de confiança na organização, grau de pressão para entregas, nível de patrocínio para uma nova abordagem, se é mais bottom-up ou top-down, nível de complexidade de negócios da área, nível de regulação de órgãos externos, nível de tolerância a erros, nível de dependências entre sistemas, contratos existentes com fornecedores, conhecimento de pessoas disponíveis na organização e no mercado, etc.

Além da resposta política, no estilo consultor que diz “depende…” também tenho um ponto de vista de ideal, uma abordagem que poderia ser aplicada onde fosse possível.

Sabe quando termina a copa do mundo e eles montam uma seleção com os melhores jogadores? A abordagem ideal que penso pega elementos do Scrum, XP, Lean, Kanban, Lean Startup, Product Development, FDD, PQP, FDP, etc… O fato de eu não estar vinculado a nenhuma instituição que vende uma abordagem específica como Scrum.org, LKU ou ter adoração fanática por um determinado autor, me permite essa flexibilidade.

Estou escrevendo um post sobre isso.

buzON: Qual é um dos maiores desafios da indústria de saúde na qual você trabalha?

Torricelly: Grande parte das tecnologias na área de saúde envolvem hardware que são produzidos por grupos de empresas estrangeiras da Alemanha, EUA, Israel. Falando especificamente sobre a indústria de saúde brasileira, existe um gap de expertise em gerar inovação nesses campos, restando inovar apenas nas áreas de atendimento ou através de modelos de negócios. Um dos maiores desafios é não termos tecnologia nacional que possa inovar no core do negócio, onde fica o hardware.

Isso gera um risco grande para uma empresa estrangeira desenvolver uma nova tecnologia que irá causar disrupção em todo mercado, e nós não podemos fazer nada a respeito, por exemplo, como foi a tentativa (que deu ruim) da Theranos em oferecer 300 tipos de exames nas farmácias, que poderia pegar uma fatia grande do setor de laboratórios.

O setor de saúde possui uma ligação muito forte com tecnologia, desenvolver novas tecnologias e saber explorar o potencial das novas tecnologias para melhorar a indústria de saúde é um grande desafio.

buzON: Como vocês têm se estruturado, enquanto times de desenvolvimento, para atender as demandas das áreas clientes?

Torricelly: Em vez de criar um modelo homogêneo para todos os times de desenvolvimento, as áreas de negócios tem contextos diferentes que exigem estratégias adequadas às suas necessidades.

Estrutura de Células:

Temos criado estruturas de células, que são times multidisciplinares com um propósito bem definido, cada célula possui KPIs de resultados de negócios ou progresso de escopo.

Chamamos de Células de Resultados as que operam orientados a KPIs de resultados de negócios, Células Enablers as que operam orientados a criar soluções para células de resultados onde suas métricas são o quanto seus serviços estão sendo utilizados pelos outros sistemas, e ainda temos o modelo de Projetos que possuem foco em resolver um problema específico com escopo mais definido e data para encerramento, mas a tendência é que estes se tornem exceção e não mais o padrão.

Método de trabalho:

Como cada célula possui propósito e métricas definidas, a organização tática fica a critério dos integrantes para adaptarem a forma de trabalho que funcione melhor para eles seja com Scrum, Kanban ou algo mais simples como a execução de um backlog de hipóteses com ciclos de Build, Measure, Learn do Lean Startup.

Independente do método, uma mudança significativa está na relação do time de TI com área de negócios, em vez do time de desenvolvimento atuar de forma reativa, executando apenas as demandas solicitadas em ciclos anuais ou trimestrais de planejamento e priorização, passam atuar de forma proativa, descobrindo oportunidades nas áreas de negócios em pequenos ciclos de experimentação, dados e métricas. Característica semelhante a de empresas que já nascem digitais, onde a tecnologia é um fator crucial para os negócios. Ainda não são todos os times que estão atuando com esta abordagem, mas essa é a tendência.

Normalmente em organizações com abordagem mais projetizada, os times apresentam reports apenas sobre como está a execução do projeto, se está atrasado, no prazo ou sobre a produtividade do time. Poucos mostram a visão sobre como está a qualidade, do que adianta as entregas estarem no prazo e a qualidade ruim com um grande débito técnico? Ou do que adianta estar no prazo e ter gerado pouco resultado para a organização?

Temos buscado ter visibilidade de outras dimensões, realizando gestão do produto que vão além apenas da execução de projetos.

Alinhamento com estratégia:

Os Product Owners das células de resultados respondem para os executivos responsáveis de sua respectiva área de negócios, com isto ele consegue priorizar o backlog de um ou mais sistemas de sua área, alinhando o que é desenvolvido pelos times de desenvolvimento com a estratégia da empresa. Quinzenalmente os POs apresentam aos seu boards executivos os resultados alcançados e visão de próximas entregas de resultados, e mensalmente um board de todas as células apresentam seus resultados ao CEO e demais executivos de cada área.

buzON: Vocês tiveram experiências com o Design Sprint, certo? Pode contar um pouco como funciona para quem não conhece?

Torricelly: É bem comum em organizações de médio e grande porte ter muitas pessoas trabalhando internamente que tem pouco ou nenhum contato com os clientes externos, é mais comum ainda a área de TI trabalhar com pouquíssimo ou nenhum contato com clientes externos. Essa característica costuma gerar pouca visibilidade de impacto das atividades feitas internamente aos clientes externos, quando uma área de negócios solicita algo para a TI, existe a impressão que o principal foco está na eficiência interna da organização, e pouca visão se está melhorando algo para os clientes.

Os Designs Sprints que rodaram na empresa foram muito interessantes para as áreas de negócios e TI terem um entendimento melhor do perfil dos clientes. O primeiro passo do DS foi realizar uma pesquisa antropológica que estuda como o cliente pensa, o que o motiva, o que o deixa irritado, dados demográficos, como está a percepção do cliente em relação aos serviços da empresa, etc. Design Thinking não é sobre mapear coisas com post-it, é sobre ter empatia enxergando o mundo e sua empresa do ponto de vista do cliente, por isso os pesquisadores também fizeram a mesma jornada de um cliente, passando pela mesma experiência que os clientes tiveram na empresa.

Essa primeira etapa gera vários insumos e idéias de oportunidades e melhorias que podem ser realizadas. As próximas etapas do Design Sprint é criar soluções para resolver algum problema detectado ou capturar alguma oportunidade. No quinto e último dia, um protótipo funcional é testado para validar se a hipótese da solução pensada irá mudar algo na experiência do cliente. Em nosso caso foram detectadas várias oportunidades em toda cadeia de valor. Um ganho interessante é que passamos a ter mais consciência sobre o quanto mudanças na cadeia de valor interna da empresa geram impacto na ponta da cadeia para os clientes.

Muito obrigado Torricelly pelas respostas e sucesso nos seus projetos!