Blog: Metodologia

Ciclo OODA na arte da guerra dos negócios rápidos

Estratégia é uma das disciplinas que deveria ter grande importância para nossa vida, ouso dizer que deveria ser ensinada nas escolas. Uma boa estratégia tem grande valor, basta observar sua ampla discussão no livro a Arte da Guerra, de Sun Tzu.

Pensando nisso, John Boyd, Coronel da Força Aérea Norte Americana nascido em 1927 desenvolveu um modelo para a tomada de decisão no combate aéreo, e sua potencial utilização ao mundo dos negócios tornou-se evidente. Sua história é um fato a parte e pode ser pesquisada para entender melhor seu objetivo, mas podemos resumir no que chamamos de ciclo OODA.

O Ciclo OODA é um modelo baseado em um ciclo de quatro pontos que apoia uma tomada de decisão rápida e eficaz.

Observar, Orientar, Decidir e Agir

Qual a diferença entre o OODA e o PDCA?

O Ciclo do PDCA(ou ciclo de Deming) é uma abordagem analítica que pode ser usada de maneira interna. Dependendo do processo que estamos tentando melhorar, não é necessário consultar o ambiente externo ou realizar qualquer ajuste para que o ciclo do PDCA funcione.

O PDCA tem grande sucesso em chão de fábrica. Envolve o uso de um conjunto de dados para chegar a uma conclusão. Utilizamos os dados para tomar uma decisão sobre como proceder, nós verificamos e agimos para confirmar ou rejeitar a possibilidade analisada.

O Ciclo OODA tem maior foco em sintetizar uma ação em um conjunto de dados, mesmo que incompletos, para tomar uma decisão rápida e efetiva.

Mas o ciclo OODA peca no aspecto da Qualidade e dos testes que não são as prioridades no topo das suas entregas, já que a visão é rapidez. Porque para acelerar o seu ciclo OODA, é preciso terminar os projetos mais rapidamente. O que leva o tempo de ciclo para o topo da lista de prioridades do gerenciamento de projetos.

Assim como a capacidade de "agir" nem sempre é simples o suficiente para ser um requisito atendido por um único projeto. Mesmo falando de ágil.

Mas poderia ser bem empregada com o uso de metodologias como a 6sigma, onde o PDCA também é usado.

Matriz swot o que e e como usar

SWOT a sigla dos termos ingleses Strengths (Forças), Weaknesses (Fraquezas), Opportunities (Oportunidades) e Threats (Ameaças) que consiste em uma  ferramenta de análise  bastante popular no âmbito empresarial.

Análise SWOT é uma ferramenta utilizada para fazer análise ambiental, sendo a base da gestão e do planejamento estratégico numa empresa ou instituição, recolhendo dados importantes que caracterizam o ambiente interno(forças e fraquezas) e externo (oportunidades e ameaças) da empresa.

Graças à sua simplicidade pode ser utilizada para qualquer tipo de análise de cenário, desde a criação de um blog à gestão de uma multinacional.

A técnica de análise SWOT foi elaborada pelo norte-americano Albert Humphrey, durante o desenvolvimento de um projeto de pesquisa na Universidade de Stanford entre  1960 e 1970, usando dados da Fortune 500, uma revista que compõe um ranking das maiores empresas americanas.

As informações referidas abaixo devem ser enquadradas nas categorias SWOT para análise do cenário da empresa:

Ler mais…

Scrum of Scrums

Você já deve ter ouvido falar em Scrum of Scrums (SoS) , que nada mais é que uma importante técnica para escalar Scrum em grande times e projetos.  Trabalhada em reuniões que permitem agrupar os times para discutir seus trabalhos, focando especialmente em área de sobreposição e integração.

Definição Uma técnica para escalar Scrum em grupos grandes (mais de 6 pessoas), consistindo em dividir os grupos em equipes Agile de 5-10. Cada Daily dentro de uma sub-equipe termina designando um membro como embaixador para participar de uma reunião diária com embaixadores de outras equipes, chamado Scrum of Scrums. Dependendo do contexto, os embaixadores podem ser contribuidores técnicos, ou Scrum Master de cada equipe, ou gerentes de cada equipe.

O Scrum of Scrums transcorre como uma reunião diária normal, com os embaixadores que informam as conclusões, as próximas etapas e impedimentos em nome das equipes que representam. Espera-se que a resolução de impedimentos se centre nos desafios da coordenação entre as equipes; As soluções podem implicar concordar com interfaces entre equipes, negociar limites de responsabilidade, ...

O Scrum of Scrum realiza seu acompanhamento dos itens através de um backlog próprio, onde cada item contribui para melhorar a coordenação entre equipes.

Lendo diversos artigos para buscar entender limitações e pontos onde a aplicação venha a aparesentar baixa performance ou qualquer entrave, cheguei a Allan Shalloway, que preve alguns problemas em praticar Scrum com grupos grandes (350 pessoas ou mais). Neste caso há vários diferentes produtos sendo construídos com componentes compartilhados.

Ele cita 3 exemplos de problemas que ocorreram:

  • Nível Técnico. Dado que estávamos fazendo desenvolvimento iterativo, os times esperam seguir princípios de design emergente. Isso significa que estamos escrevendo código de qualidade, mas não adicionamos funcionalidade ou design até que eles sejam necessários.
  • Nível Inter Times. A forma como os times trabalham juntos quando há diferentes Product Owners e Scrum Masters para cada time, nem sempre é tão óbvia. Mais uma vez, uma visão mais abrangente ajuda. Isso é especialmente verdade quando há um time de componentes fazendo trabalho de suporte para vários outros times. Orientar-se através de business value requer olhar através dos product owners. Eles podem cooperar, porém, mais uma vez, eles podem não cooperar.
  • Nível de Estrutura do Time. Muitos times scrum trabalhando juntos tem problemas sérios para entregar uma funcionalidade final quando muitos times estão envolvidos.

Já Mike Dwyer diz preferir o SoS e Meta Scrums: para coordenar a decomposição de estórias, de forma que assim você não termina com a mesma coisa construída por vários times. Aquelas coisas devem ser trabalhadas através de conversas diárias e frequentes que ocorrem em todos os níveis.

Em sua experiência, times bem conduzidos focam na infraestrutura, dados e arquitetura para fazer um bom trabalho de reunir código compartilhado. O que mais acabaremos encontrando como receita para o sucesso da reunião Scrum of Scrums será o que todos já devemos ter em mente: **Manter a reunião curta. 15 minutos no máximo. Mantenha-a focada. O que os outros querem/precisam ouvir? Discussões devem ser reservadas para uma reunião separada para manter a reunião curta e focada. Traga os problemas que bloqueiam para cada reunião SoS até que sejam resolvidos.

Squad, Times Cross-funcionais

A evolução da aplicação de Metodologias Ágeis muda não somente como as empresas pensam seu trabalho, mas também como elas moldam seus times. Nesta ideia de equipes cross-funcional e que surgiu o Squad, que ganhou maior visibilidade após ser divulgada de como a Spotify, empresa sueca de streaming de música, organiza e estrutura seus times.

Squads Squads são a unidade básica de organização dos times, geralmente em torno de uma feature, ou subsecção de uma funcionalidade. Podem ter até 10 membros, cross-funcional a ponto de conterem expertise dentro do grupo para desenvolver todos os aspectos do produto e definir suas prioridades alinhadas com o objetivo da empresa.

No modelo de Squad, não há uma figura de liderança formal. As lideranças são mais orgânicas, já que os times são auto-geridos. Eles se baseiam em aspectos técnicos e funcionais do trabalho e de seus projetos.

Não há também uma divisão funcional constituída de papéis tradicionais. Todos os envolvidos em determinado projeto trabalham conjuntamente e complementarmente, cocriando soluções.

Esses times são organizadas multidisciplinarmente, de acordo com as necessidades dos projetos da empresa.

Times Cross-funcionais Porque voltar a este ponto? Porque os times cross-funcionais estão mais presentes nas organizações que desejam contar com equipes de alta performance. Elas diferenciam-se da concorrência por meio de serviços, produtos e atendimento inovadores.

Esses times tornam as organizações menos hierárquica e vertical do que as estruturas mais tradicionais e precisam ser compostos por colaboração profissionais com diferentes competências e perfis que atuem em diferentes atividades, onde não há espaço para a mentalidade do “a minha parte eu entreguei” e/ou “eu fiz o meu trabalho” . Todos trabalham para atingir um objetivo comum.

O impacto na comunicação é grande, pois ela exige mais dedicação, já que a interação é continua com pessoas de diferentes funções e expertises.

Quanto mais unido e sensibilizado em relação aos objetivos o squad for, maior será o benefício para a empresa e para a agilidade de seus processos.

Desvantagens dos times cross-funcionais Nem tudo é somente vantagens, encontrei descrito em diversas postagens, questões relacionadas a autonomia, já que esse tipo de estrutura permite que os membros definam as prioridades. O alinhamento com os demais membros e a empresa deve ser muito afinada.

Acho que muito também deve se pensar em harmonia e formas de incentivar este afinamento. Isso passa muito pelo desenvolvimento das lideranças. Mesmo que não se pense neste papel, alguém tem que comunicar para fora, representar o Squad em algum momento e ele deve realizar uma gestão bem diferenciada para dentro do sistema burocrático da empresa.

Enfim… Squad é uma nova forma de se trabalhar, que pode e deva ser usado nas empresas, mas as empresas precisam ter uma nova visão, pensa no futuro e querer.

Papéis no Scrum: Product Owner, o Dono da Bola, Scrum Master, o Coach Proativo e Scrum Team

Scrum assim como muitas metodologias são formadas por papeis que fundamentam sua aplicação. Os papéis dentro do Scrum são compostos por: O Product Owner, Scrum Master e Team Scrum, que são suficientes para entregar software de alto valor agregado, de acordo com a metodologia Scrum.

Unindo e agregando conhecimento a meus posts anteriormente, temos uma descrição segundo o SBOK.

Product Owner, o Dono da Bola O Product Owner é o dono do produto, é quem define os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings, pois fornece o conhecimento do negócio em forma de requisitos para a equipe assim como sua ordem de aplicação. Na prática, o Product Owner é a interface entre a empresa e os clientes.

O Product Owner Trabalha em conjunto com a equipe definindo as necessidades dos usuários, os requisitos técnicos, documentando-os conforme a necessidade, e determinando a ordem de sua execução. Ele gerencia o Product Backlog (que é o repositório de todas essas informações), mantendo-o ao nível de detalhe e qualidade que a equipe necessita.

O Product Owner também define o cronograma para liberação das releases, e faz a validação final para saber se as implementações têm as características e qualidade necessárias para a liberação.

O Scrum Team olha para o Product Backlog priorizado, seleciona os itens mais prioritários e se compromete a entregá-los ao final de um Sprint. Estes itens transformam-se no Sprint Backlog.

A equipe se compromete a executar um conjunto de atividades no Sprint e o Product Owner se compromete a não trazer novos requisitos para a equipe durante o Sprint. Requisitos podem mudar (e mudanças são encorajadas), mas apenas fora do Sprint. Uma vez que a equipe comece a trabalhar em um Sprint, ela permanece concentrada no objetivo traçado para o Sprint e novos requisitos não são aceitos.

Scrum Master, o Coach Proativo O Scrum Master tem a responsabilidade de assegurar que a equipe respeite e siga os valores e as práticas do Scrum. Ele também protege a equipe assegurando que ela não se comprometa excessivamente com relação àquilo que é capaz de realizar durante um Sprint.

As responsabilidades do Scrum Master incluem:

Remover as barreiras entre a equipe e o Product Owner. O Scrum Master atua como facilitador do Daily Scrum e torna-se responsável por remover quaisquer obstáculos que sejam levantados pela equipe durante essas reuniões. Melhorar a produtividade da equipe da forma que for possível. Melhorar as práticas de engenharia e ferramentas para que cada incremento de funcionalidades seja potencialmente entregável. Manter as informações sobre o progresso da equipe visível a todos de uma forma clara e organizada. Em termos práticos, o Scrum Master precisa ter em mente a vivência do Scrum para treinar e orientar os outros papéis, e educar e ajudar as outras partes interessadas que estão envolvidas no processo.

Ele deve manter atenção constante ao status do projeto em relação ao progresso esperado. Investigar e facilitar a resolução de quaisquer obstáculos que imobilizam o progresso e, geralmente, ser flexível o suficiente para identificar e lidar com quaisquer problemas que surjam. Ele deve proteger a equipe de perturbações externas.

O Scrum Master não atribui tarefas aos membros da equipe, isso é uma responsabilidade da equipe. Sua abordagem geral para a equipe é incentivá-la e facilitá-la na capacidade de tomada de decisões e resolução de problemas relacionados ao desenvolvimento, de modo que eles possam trabalhar com maior eficiência sem a necessidade de supervisão. Seu objetivo é ter uma equipe auto-organizável.

E finalmente, Scrum Team O Scrum Team é a equipe de desenvolvimento sem a necessidade de uma divisão funcional através de papéis tradicionais, tais como programador, designer, analista de testes ou arquiteto. Todos no projeto trabalham juntos para completar o conjunto de trabalho com o qual se comprometeram conjuntamente para um Sprint.

O Scrum Team é auto organizável, ou seja, quem decide quem faz o que, quais as funções de cada membro e o que cabe ou não na Sprint é o time.

Um Scrum Team típico tem de 6 a 10 pessoas, embora haja relatos de projetos Scrum com equipes maiores. A principal abordagem para trabalhar com equipes grandes no Scrum é usando o conceito de “Scrum of Scrums“.

Cada Scrum Team trabalha normalmente, mas cada equipe também contribui com uma pessoa que deverá frequentar o Scrum of Scrums Meeting para coordenar o trabalho de múltiplas equipes Scrum. Esses encontros são análogos aos Daily Scrums, mas não acontecem necessariamente todos os dias. Fazer essa reunião duas ou três vezes por semana tende a ser suficiente na maioria das organizações.

Veja a importância efetiva de cada grupo definido no SBOK. Oportunizando a todos o mesmo grau de importância e compreensão do todo.