Por que eu resolvi escrever esse post ?

Bom, vejo muito as pessoas falando de coaching, porém, sinto que não há uma clara percepção no mundo ágil do que realmente é um trabalho de Coaching, qual a importância do papel do Coach em um processo, seja ele qual for.

Por isso resolvi escrever algo a respeito deixando claro que é uma opinião minha sobre o assunto, e que vou falar de forma bem abrangente.

O que é coaching?

Coaching é um processo que visa aumentar a performance de um indivíduo – seja ela pessoal ou profissional com um papel específico – um grupo de profissionais com um objetivo comum ou uma empresa, gerando resultados positivos com metodologias, ferramentas e técnicas, conduzidas por um profissional em uma parceria com o cliente.

Coaching é o processo de evocar a excelência em seus clientes, promover excelente performance a curto, médio e longo prazo e potencializar seu poder.

Coaching estimula uma forte comunicação, identificação e reformulação de valores, metas e busca de soluções.

Coaching é uma habilidade de gestão e gerenciamento de pessoas, indispensável para executivos e líderes.

O que não é coaching?

Coaching não é terapia, aconselhamento, psicologia, consultoria ou mentoring. O coaching é uma abordagem pragmática focada na realização de um ou mais objetivos específicos.

A principal diferença entre o Coach e uma Terapia é que uma terapia tenderá a focar nas experiências e nos sentimentos relacionados a eventos passados, tratando de distúrbios e desequilíbrios emocionais. Já o Coaching irá atuar fortemente com disciplina orientada ao ajuste dos objetivos e encoraja o cliente a seguir em frente na conquista dos mesmos e de novas realizações.

O aconselhamento, mentoring e consultoria não podem ser comparados com Coaching porque conselheiros e consultores fornecem conselhos indicando, falando o que deve ou não ser feito. Em contrapartida, o Coaching irá atuar com o cliente questionando, dando possibilidades e ferramentas para que ele conquiste suas próprias soluções, respeitando sua cultura, valores e princípios. Enfim o coaching não realiza mudanças no cliente, mas sim, o ajuda a descobrir se precisa ou não de uma mudança e contribui fortemente nesse processo que é a parte mais difícil para o cliente — a fase de transição de uma realidade para outra, muitas vezes quebrando paradigmas, idéias fixas, crenças e valores, o que torna dura e difícil a mudança. E se estamos sozinhos é uma tendência natural do ser humano manter-se na zona de conforto. É nesse momento que o papel do Coach é extremamente importante, pois ele será o agente de mudança que irá sempre conduzir o seu cliente com foco em sua meta e não permitindo que o mesmo permaneça acomodado.

O papel do Scrum Coach

O Coach é o agente de mudança responsável por promover a seu cliente a busca de novos entendimentos, alternativas e opções que façam com que ele amplie suas realizações e conquistas. Sempre focado no futuro com o intuito de aumentar a performance, mudança, transformação ou aprendizado; fazer com que o cliente entre em ação de forma mais efetiva e focada.

Definir de forma clara quais são seus principais objetivos com a implementação da framework em sua empresa, traçar um Road Map para atingir esses objetivos com metas e foco no processo. Isso é o mínimo que você pode esperar de um Scrum Coach para fazer com que a implementação do Scrum em sua empresa seja bem sucedida.

Além disso: garantir que os paradigmas da empresa sejam quebrados, desmistificando as “crenças limitantes” que impedem o processo de mudança sem afetar a cultura, diminuindo as dores da mudança, diminuir os riscos com ferramentas como gains and losses para minimizar perdas, dar manutenção de ganhos e produzir uma congruência sistêmica, trabalhar de forma efetiva na educação do time, fornecer ferramentas eficientes no estimulo da comunicação, descobrindo os pontos fracos e trabalhar na melhoria contínua, habilidades para superar barreiras e remover os impedimentos para alcançar seus objetivos. Enfim, garantir que a implementação seja bem sucedida e conduzi-la da melhor forma possível dentro da cultura da empresa.

No próximo post sobre o assunto irei focar mais no papel de um Agile Coaching atuando como um agente de mudança dentro de uma organização.

Até mais.

Essa é uma situação que todos nós sabemos que acontece, porém, sempre fazemos vista grossa, e nisso eu incluo todos os envolvidos no projeto: diretoria, gerência, analistas, desenvolvedores, testers, DBA`s e demais pessoas que participam do projeto. Os desenvolvedores acham que “iludem” o gerente dizendo que os percentuais de desenvolvimento estão dentro do prazo, que não estão tendo problemas e que tudo está andando como esperado. Os gerentes “iludem” seus diretores dizendo que as coisas estão caminhando bem, que seu Gantt Chart está perfeito, que o plano está sendo seguido como esperado, mas que não vai dar moleza para o time, pois se eles não estiverem com um chicote nas costas as coisas não andam…afinal, ele precisa mostrar que tem autoridade sobre o time.

Em geral, isso acontece muito em um cenário tradicional de gerenciamento de projeto, pois a cultura atual leva este profissional (ou recurso, como preferir) a ter essa postura. O que é muito comum em ambientes de projetos é a aparição da famosa síndrome do estudante (quando é que você estuda para a prova mesmo?): quando o desenvolvedor recebe suas tarefas e olha para o tempo que tem para codificá-las, qual é o primeiro pensamento que vêm a sua mente (pelo menos eu também pensava assim) ? “Ah, tem tempo ainda, posso continuar a resolver essa pendência, a ler o livro, a navegar na internet, a ler e responder e-mails diversos, … “, e com isso se passam minutos, horas e muitas vezes dias.

Na minha opinião, os principais pontos que acarretam essas situações são :

- Prazos longos nos dão uma sensação de conforto
- O fato do programador não ter dado a palavra dele do que é ou não possível de ser feito
- Falta de comunicação e excesso de papéis dizendo, ou melhor, tentando dizer o que o time precisa fazer
- Cultura da empresa, acostumada a atrasos e fins de projetos “cheios de emoção”;
- Desenvolvedores ignoram a comunicação e se escondem em seu mundo (com seus fones de ouvido cada vez maiores)
- A falta de uma definição de pronto, o que reflete diretamente na qualidade (Vou fazer o que está escrito aqui e se compilar: “pronto!”)

O comprometimento do time é um dos principais fatores que levam ao sucesso do projeto, afinal um time comprometido com o trabalho e focado em uma meta vai fazer o possível para atingí-la, simples assim! Em times Scrum esse comprometimento é alcançado naturalmente pela forma de trabalho que o Scrum propõe. O fator “síndrome de estudante” fica difícil de ser aplicado já que trabalhamos com iterações curtas e isso teoricamente leva o time a trabalhar firme desde o primeiro dia de trabalho, além disso as reuniões diárias são fortes agentes de combate a este vício.
Falando em comprometimento e estimativa, em times Scrum é o próprio time quem planeja as suas Sprints dizendo quais são os itens que irão entrar naquele período de 2 a 4 semanas, ou seja, a palavra do time tem valor e isso faz com que eles sintam essa confiança que neles é depositada. Quando o time planeja e estima os requisitos que serão desenvolvidos naquela Sprint, eles estão focando em uma meta definida pelo Product Owner, ou seja, para a Sprint ser bem sucedida, a “meta” tem que ser alcançada. Indo mais a fundo, para desenvolver um item do Product Backlog, o time quebra ele em pequenas tarefas que serão desenvolvidas por todos os membros do time, isso mesmo, todos do time irão trabalhar em um mesmo item: o item de maior prioridade para Product Owner, o que tem mais retorno sobre o investimento do projeto. Sei que a primeira impressão é, “isso é impossível” mas acreditem, não é! Essa definição de tarefas que precisam ser executadas para que um item seja considerado pronto são discutidas e criadas pelo time, seguindo a ordem de prioridade definida pelo cliente, e isso também contamina o time para que todos se comprometam e colaborem entre si para que as tarefas de um requisito sejam finalizadas, garantindo que aquele item fique realmente “pronto”. Uma pessoa do time não irá pegar uma tarefa de um outro item se houverem tarefas de um requisito de maior prioridade para serem desenvolvidas, ou seja, ele tem o comprometimento com a “meta” que foi acordada entre eles e o Product Owner.
Esse espírito de união que é gerado dentro do time é um fator que estimula o comprometimento, pois quando vemos que todos os membros do time estão empenhados e trabalhando firme, isto acaba contaminando a todos, e se alguém não estiver comprometido, acredite, ele irá se sentir mal, pois este é um processo natural que ocorre em times ágeis. Esse comprometimento ajuda muito quando temos um dos membros do time que está passando por dificuldades com alguma tarefa que faz parte de um item que compõe a meta, é fato que a ajuda por outros membros do time irá aparecer espontaneamente, pois times ágeis são auto-gerenciáveis.

Outro fator que estimula o comprometimento é que em uma gestão ágil não vemos um Gerente de Projeto “no pé” do desenvolvedor perguntando qual é o percentual que falta para executar a tarefa, porque acreditamos que ele é capaz de fazer o seu trabalho, ou seja, nós confiamos no time e sabemos que eles irão fazer o possível para atingir a meta. Times ágeis possuem um contato muito próximo ao cliente, e isso elimina o “telefone sem fio” quando o gerente escuta a necessidade do cliente, passa para o analista que gera a documentação para o desenvolvedor e este tem que fazer milagres pra entender aquela “maravilhosa” especificação. Isto elimina também a mania que temos de usar os documentos para substituir uma comunicação, a regra de negócio é passada diretamente do cliente para o time em reuniões periódicas de planejamento o que dá mais segurança e confiança para o time desenvolver aqueles requisitos, estimulando mais uma vez o comprometimento do time. Lembrando, documentos são importantes, mas não substituem a comunicação.
Bom, não quero dizer que isso é uma verdade absoluta, apenas estou compartilhando com vocês a minha experiência sobre o que vejo no comprometimento de times que trabalham com uma gestão ágil e naqueles que trabalham com uma gestão mais tradicional. Existem vários outros fatores sobre o comprometimento de times que poderiam ser citados aqui, mas creio que com essas informações já consegui passar o meu recado. Formar um time comprometido e auto-gerenciado é uma das responsabilidades do ScrumMaster, afinal isto não acontecerá como num passe de mágica, mas sim com muito trabalho, dedicação é tendo educação como palavra-chave.

Comentários são bem vindos para nosso crescimento e melhoria: inspect and adapt.