Agile Projeto

Sua empresa não vai se tornar ágil implementando o Scrum

Muitas empresas acreditam que vão se tornar ágil implementando o scrum. Tornou-se o padrão da indústria para desenvolvimento de software. No entanto, muitas empresas lutam para alcançar os benefícios esperados. Eles nunca se tornarão verdadeiramente ágeis. Por quê?

Primeiro o ponto cego

Ágil e scrum são frequentemente mencionados juntos. Ao fazer o scrum, você pode fazer o dobro do trabalho na metade do tempo. Isso permite uma inovação mais rápida e a capacidade de responder rapidamente às mudanças do mercado, permitindo agilidade.

Para a equipe executiva, esse é um sonho que se torna realidade.

A gerência ordena um piloto de scrum. As equipes scrum recém-formadas começam com entusiasmo e dedicação. Infelizmente, eles não cumprem as altas expectativas e muitas vezes a situação resultante é ainda pior do que antes.

O piloto falha e a equipe agile é culpada. O que é esquecido é que, ao implementar o scrum, você não se tornará automaticamente ágil.

Scrum, mas não ágil

Apenas implementar o scrum em seu departamento de desenvolvimento de software não é suficiente para se tornar realmente ágil. Muitas empresas ignoram as mudanças necessárias na cultura da empresa, estilo de gestão, processos e forma de executar projetos.

Scrum é um método, agilidade é uma mentalidade.

Gestão mata inovação

Mudar a cultura de uma empresa começa alterando a maneira como o gerenciamento funciona. Muitas vezes, o estilo de gerenciamento de cima para baixo e de comando e controle persevera ao lado do scrum.

Quando algo falha, a gerência exige uma explicação e procura a pessoa que pode ser responsabilizada.

Os processos são, portanto, projetados para evitar falhas implementando muitos pontos de verificação formais. Antes de poder fazer algo, você precisa entregar documentos detalhados aos departamentos certos para obter um selo de aprovação. Como os funcionários não são incentivados a ultrapassar esses limites, a inovação e a agilidade são eliminadas.

Gestão de Projetos tradicional em cima do scrum

Juntamente com a antiga cultura da empresa, a gestão de projetos orientada por planos também persevera. Um projeto só é aprovado quando a administração pode ser convencida de que obterá valor pelo dinheiro.

Entregar no prazo e dentro do orçamento e escopo predefinido ainda é esperado. Em uma organização scrum, isso resultará em um gerente de projeto tendo que negociar com os proprietários do produto e os Scrum Masters.

O escopo é geralmente definido como um produto esperado, em vez de atingir uma meta de negócios. O poder do Product Owner de decidir como uma meta de negócios pode ser alcançada é muito limitado. A pressão aumentará rapidamente quando o prazo não for mais viável, por exemplo, devido a novas percepções.

A equipe é solicitada a trabalhar durante as noites e fins de semana para cumprir o prazo final, resultando em atalhos na qualidade.

Combinando cascata com scrum, cria-se uma situação que é ainda menos eficiente e eficaz do que a situação antiga. Conhecido como Water-scrum-fall

Apenas deixando de lado velhos hábitos e métodos de trabalho, a agilidade pode ser alcançada.

Cultura ágil

Como é uma cultura de empresa ágil? Começa com uma base de confiança. A administração acredita que as melhores soluções surgem quando as pessoas certas colaboram umas com as outras.

As pessoas recebem a confiança e liberdade para explorar de forma autônoma idéias e soluções, sem precisar pedir permissão. Não há problema se algo falhar. O fracasso e a aprendizagem do fracasso são encorajados, porque a experimentação e o fracasso são os pré-requisitos para a inovação.

Para permitir a agilidade, o poder de decisão e a responsabilidade devem ser implementados no nível mais baixo possível em uma organização, ou seja. Em um time scrum. Se as pessoas puderem fazer o que acham que é melhor para a empresa, elas se apropriarão, participarão e vão manter estes conceitos em todos os produtos.

A administração orienta-se apenas através da comunicação de prioridades estratégicas e metas de negócios (mensuráveis). As equipes de scrum são confiáveis ​​para descobrir por si mesmas como alcançar esses objetivos.

Os gerentes se tornam líderes servidores e só trabalham em tarefas que as equipes não conseguem resolver.

Transformando sua empresa para o ágil

Uma empresa não pode se tornar ágil implementando o scrum no departamento de TI.

Se a administração espera que o scrum resolva todos os seus problemas, isso se tornará uma grande decepção, a menos que eles estejam preparados para tratar das condições prévias. Transformar sua empresa numa empresa ágil é muitas vezes uma grande mudança que requer muitas mudanças.

Empresas tradicionais versus Empresas ágeis: as maiores diferenças

Ágil

Tradicional

Regras e Políticas Devido ao alto nível de confiança nas pessoas, a quantidade de regras e políticas é limitada e desnecessária. Somente quando se trata de negócios críticos (como segurança e conformidade), regras são criadas. Existem muitas regras e políticas. Departamentos centralizados (como arquitetura e segurança) devem dar permissão para sua alteração. Uma iniciativa só pode começar quando a arquitetura de início do projeto for aprovada, mesmo que não seja uma grande reformulação.

Transferências de Poder

As equipes podem, elas próprias, implantar código para produção e permanecer responsáveis ​​por incidentes e erros. Citando o CTO da Amazon: você o constrói e o executa. As transferências para outros departamentos são evitadas o máximo possível. O software será entregue aos departamentos de testes e operações. Após sua aprovação, ele será implantado na produção. Quando os incidentes acontecem, a equipe de operações tentará analisá-los e resolvê-los.

Gestão comportamental

“Os gerentes encorajam a colaboração para resolver problemas em vez de ditar uma solução. Os gerentes ajudam a lidar com os obstáculos que a equipe não consegue resolver por si mesmos” – o manifesto ágil do Spotify sobre líder-servidor. Os gerentes ditam soluções e dizem às pessoas o que fazer.

As pessoas muitas vezes escalam para a gerência, em vez de tentarem resolver o problema sozinhas.

Gestão do conhecimento

Gerentes de engenheiros sempre têm habilidades e conhecimentos técnicos, porque eles geralmente trabalham primeiro como engenheiros. Se você se inscrever para um cargo de gerência na Airbnb, primeiro você precisa ser um colaborador de código de sucesso por seis meses. Os gerentes muitas vezes não precisam ter conhecimento técnico. Talvez porque eles estão gerenciando um processo.

Isso resulta em ruído e confusão quando eles tomam uma decisão ou tentam resolver um problema para seus engenheiros.

Papéis

Em equipes multidisciplinares, os papéis se misturam. Por exemplo: o Spotify não emprega testadores, mas eles têm engenheiros que ensinam outras equipes a obter e medir a qualidade de seu produto de trabalho. O teste se torna uma competência em vez de um papel. De garantia de qualidade a assistência de qualidade. O RH determina papéis fixos com trajetórias e expectativas de carreira definidas.

Se você é um testador, arquiteto ou administrador do sistema, você se atém às tarefas associadas à sua função.

Mentalidade

As pessoas têm uma mentalidade de “poder fazer”. No escritório da InfoScout, uma startup de São Francisco, G.B. A famosa citação de Shaw é proeminentemente impressa: “pessoas que dizem que isso não pode ser feito não devem interromper aqueles que estão fazendo isso.” As pessoas costumam reclamar e enfatizar problemas em vez de pensar em soluções.

Quando se deparam com um desafio, procuram razões pelas quais algo é impossível.

Talento

Apenas os melhores talentos são contratados. Além de habilidades de engenharia, atitude, comunicação e habilidades sociais são importantes. Verificar a adequação cultural e ver se a nova contratação é capaz de assumir responsabilidade é uma parte importante do processo de entrevista. Isso garante e protege a cultura ágil da empresa, atraindo talentos ainda mais qualificados. Os altos potenciais não permanecerão se não forem continuamente desafiados e forem capazes de aprender com outros altos potenciais. O ambiente de muitas empresas tradicionais dificulta a sua manutenção. Isso resulta em uma espiral descendente. Citando Steve Jobs: “Jogadores classe A, contratam jogadores classe A. Mas os jogadores classe B contratam jogadores classe C. ”

Tomada de decisão

As decisões são geralmente feitas com base em dados.

Tudo é medido e experimentando diferentes variações, a melhor solução se torna evidente.

As decisões são frequentemente baseadas nas opiniões dos gerentes. No Google, é incentivado a ficar longe das perigosas Hi.P.P.Os: (Highest Paid Person Opinions) Opiniões de pessoas mais bem pagas.

Desenvolvimento de produtos

O trabalho é feito somente quando o objetivo de negócio percebido foi alcançado. No Google, eles chamam de “ship and iterate“. Obtenha seu produto nas mãos dos clientes o mais cedo possível. Reunir feedback e medir o efeito, iterar rapidamente para descobrir o melhor produto. Grandes projetos com prazos são evitados o máximo possível. O desenvolvimento de produtos é feito através da execução de grandes projetos com prazo e escopo fixos. Muitas vezes, é predefinido como o trabalho deve ser executado e o porquê (objetivo comercial) é esquecido e nem mesmo medido após o início do projeto. O projeto é desmontado quando a primeira versão do produto está em produção.
Coimbra, PMP on FacebookCoimbra, PMP on LinkedinCoimbra, PMP on TwitterCoimbra, PMP on Youtube
Coimbra, PMP
Como fundador da Projetos e TI, ajudo as organizações a se tornarem ecossistemas adaptativos, responsivos e auto-organizáveis, implementando novas práticas, estruturas, ritmos e tecnologias que permitam transparência, abertura, inovação e uma forma progressiva de liderar. Caso queira saber mais entre em contato comigo, inscreva-se na minha newsletter, ou me convide para uma palestra.

Graduado em Gestão de Tecnologia pelo Centro Universitário Barão de Mauá.
Pós-Graduado em Gerenciamento de Projetos, com as práticas do PMI® pelo SENAC.

Certificado como PMP® pelo PMI®. Six Sigma White Belt pela Voitto.
Especializado em BPMN2 pela Anelox, PMCanvas pela PM2.0 e Análise de requisitos

Mentor e influenciador de gestão de projetos, agilidade e transformação digital.

Comentários

Deixe uma resposta

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.