Sem confiança não existe agilidade!

É preciso que cada stakeholder e cada integrantes do time estejam realmente comprometidos com suas decisões e com os princípios que sustentam o método, tudo parte de estabelecer um ambiente de confiança, com realismo e muita transparência, práticas essenciais para o sucesso de um projeto ágil.

Errar é possível, não necessário, mas passível de acontecer em todas as esferas de atuação, quer pelos usuários, PO, scrum master, desenvolvedores, garantia da qualidade. Faz parte do processo de desenvolvimento de software, porque são projetos complexos, que lidam com hipóteses, percepções e mudanças.

Desenvolvimento de software envolve não só uma linguagem de programação, mas intensas relações humanas, arquitetura de dados, várias frameworks e camadas, consumindo serviços, envolvendo questões de segurança, de persistência, negócio, patterns, apresentação … nada é trivial.

Antes de acusar, voltando a zona de conforto na busca por um culpado, lembre-se que você é parte do projeto e que há responsabilidades e alçadas. Mais importante que não errar é aproveitar os ciclos curtos das iterações para aprender o mais rápido possível, errar não é de todo ruim, aprenderemos com cada um deles, não podemos é ficar cometendo sempre os mesmos erros.

1525363_10151811511520667_306767309_n

Cada projeto conta com dezenas de profissionais que devem se comprometer de uma forma ou outra para que as informações fluam, as definições aconteçam, o desenvolvimento seja feito com qualidade e a operação seja inteligente. Cada projeto é resultado de uma delicada engenharia social, onde pessoas diferentes entre si estabelecem um ecossistema de confiança em um bom trabalho.

Isto não quer dizer que pessoas não possam ser trocadas, substituídas, mas é preciso que se tenha conhecimento do perfil de cada um, conhecimento, experiência, cognitivo, habilidades, atitude e crenças em um trabalho coletivo. Acima de tudo, agilidade é suporte, aprendizado, é gestão do conhecimento e gestão por competências, se não for assim, não é ágil, é engôdo!

Há uma grande diferença entre um profissional sênior, pleno, júnior, com ou sem experiência na tecnologia e ferramental do projeto, pode ser que tenha ou não experiência em metodologias ágeis ou seja adepto de comando-controle. Cada equipe tem algo que eu chamo de grade, onde temos nas linhas as pessoas e nas colunas o CHA, crenças e cognitivo, isto PRECISA ser levado em consideração.

Lembremos que o método preza por um fluxo iterativo-incremental, onde os ciclos curtos de iteração nos ajudam a antecipar riscos e oportunidades, corrigir erros assim que eles aconteçam, antes que se avolumem, mas uma cultura de aprendizado para entrega de valor e qualidade exige confiança. Isto nos leva a múltiplos relacionamentos que sustentam ou não o método:

Gestores e Equipes de Desenvolvimento

O principal responsável pelo perfil adequado ou não da equipe são de seus gestores, é inconcebível que frente ao primeiro erro o gestor se isente de sua responsabilidade na composição e condições do time fazer bem o seu trabalho. Um time mal escolhido ou mal entendido gerará surpresas, se temos um time muito júnior ou imaturo é preciso que fique claro que teremos uma curva maior para aprendizado e resultados, havendo maiores riscos para erros. Muitos gestores veem a equipe como algo que não lhes cabe compartilhar acertos e erros, assumindo um papel de feitor para ameaça-los e puni-los quando erram. O bom gestor conhece suas equipes, os monitora e dá o suporte necessário.

Gestores e Scrum Master

Escolher alguém para SM contra a sua vontade ou sem que ele tenha tempo para este papel é o mesmo que não ter ninguém, é um papel de bastidores, no início ser facilitador e organizar as timeboxes exige dedicação e planejamento, até virarem um hábito. Espera-se de um Scrum Master que ele dedique tempo ao coaching, orientando o time enquanto grupo e cada indivíduo, procurando ajudá-los a que consigam fazer o seu melhor. Parte do tempo lhe cabe dedicar ao estudo e disseminação do conhecimento junto aos stakeholders e partes interessadas, pois é difícil adotar o método sem todos saberem onde se encaixam.

Cliente e PO

O cliente deve escolher seu Product Owner tendo a confiança que ele terá apoio e espaço para fazer o seu melhor, este é o papel mais importante no método, é quem toma as decisões pertinentes ao que é valor, ROI e aceitação. Se o PO não tem livre trânsito e confiança dos stakeholders, inclusive usuários, quer por ser novo na organização ou pelo seu perfil ser difícil, haverá riscos e dificuldades adicionais à sua atuação, principalmente quanto a tomadas de decisão. Outro ponto importante é que o PO tenha suporte e possa dedicar tempo suficiente para elicitar, definir, dirimir dúvidas e validar o que está sendo feito, este tempo é diretamente proporcional ao valor e complexidade da solução desejada.

Time = PO, SM e Equipe de Desenvolvimento

Todos os integrantes de um time SCRUM são colegas de jornada, isto quer dizer que o suporte horizontal deveria ser igual para o aprendizado e crescimento de todos, entre desenvolvedores com pair programmimg, code review, dojos, etc, mas também com o analista de testes ou testador e também com o PO, propondo se preciso apoio no ciclo de Discovery, grooming ou técnicas de elicitação ágil como Business Model Cnavas, Story Mapping, Managing Dojo, brainstorming, etc. Muitos desenvolvedores tendem a serem classistas e acham normal ajudarem a outro desenvolvedor ou mesmo testador, mas não tendo a mesma flexibilidade frente ao Product Owner, Scrum Master, extensível aos gestores e stakeholders.

Cliente e Terceiros

Digo a cada treinamento que é preciso construir um trabalho com terceiros de forma a estabelecer duas esferas de relação, uma contratual com o gerente de contas e outra onde estes prestadores de serviço se integrem de forma plena ao time de projeto onde estarão inseridos. Se funcionários e terceiros alimentarem desconfianças e desacordos essenciais e diferenciados é preciso que a gestão interfira e resolva, se necessário pela troca do profissional que precise ser trocado, pois enquanto equipe é preciso que todos tenham a mesma alçada e protagonismo relativo ao seu papel, senão haverá desperdício e maiores riscos.

Cliente e Time

É preciso treinar os stakeholders, quer sejam clientes, usuários, interessados de áreas como financeiro, contralodoria, etc, de forma que eles saibam como o método funciona, qual a alçada de cada um e quais assuntos são de competência do time ou da gestão dos mesmos. A pena pelo não entendimento e eventual mistura de questões estratégicas e contratuais em meio ao cotidiano e questões técnico-funcionais é uma das principais geradoras de tensão e falhas, stress e frustração. Os stakeholders devem saber qual o perfil do time e dúvidas a cerca deste perfil devem ser alinhados junto a gestão e não com o time. Na dúvida, lembrem que há um PO definindo e avaliando o que está sendo feito.

Equipe e DevOps

Está na hora de pararmos de tratar reciprocamente as áreas de desenvolvimento e infraestrutura como prestadores de serviços ou mesmo adversários, temos conceitos de DevOps e Service Thinking que pretendem integrar todas as áreas necessárias para que um projeto de desenvolvimento de software seja o resultado da integração e colaboração ativa de todas as partes necessárias, lembrando que sem banco de dados, redes, servidores e segurança não entregamos nada de qualidade aos clientes.

Conclusão

Inexiste agilidade sem um clima de confiança entre as partes, se uma parte não retribui ou não possui os atributos desejados, nada pode ser uma surpresa para ninguém, é preciso que haja continuo feedback, alertas, transparência, somente assim e com o suporte preciso é que surge cultura de aprendizado com foco em amplificação do valor e eliminação de desperdícios.

Lembre que trabalhamos anos em um regime de comando-controle, de ordens e restrições, a maioria das pessoas precisam de tempo hábil para mudar seu modelo mental, um curso SCRUM não muda pessoas, apenas as instrumentaliza para que empreendam a mudança um passo de cada vez. Agilidade é um processo de mudança intrínseca que com boa vontade demandará semanas ou meses.

10632588_10152294919575667_1678782345732435327_n

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s