Agile – O Resgate da Energia no Trabalho

Temos uma variedade enorme de empresas e ambientes de trabalho,  com seus conceitos, verdades e estruturas. Porém muitos destes apresentam velhos problemas:

– Comunicação ineficaz

– Distância do cliente

– Ausência de colaboração

– Grupo desmotivado

Não existe fórmula mágica, mas o primeiro passo é ter consciência do problema. E depois? Tentar um caminho diferente.

Qual caminho ? Um deles é o Agile.

A filosofia Agile reúne conceitos e práticas no dia a dia de trabalho, durante a execução do projeto, marcado por reuniões e outros eventos recorrentes, que dão a sensação de continuidade, onde ao realizá-las você traz uma comunicação mais efetiva, um envolvimento maior por parte do cliente, um envolvimento na definição, refinamento e estimativa por parte de todos os envolvidos do Dev Team provocando assim um maior comprometimento e consequentemente uma maior colaboração entre os membros do time e uma atuação forte da liderança facilitadora com responsabilidade do Scrum Master para criar um ambiente produtivo e funcional com foco em gerar um ambiente com indivíduos motivados.

A questão da comunicação é melhorada, através do diálogo rápido e cotidiano com objetivo de sintonizar todos os envolvidos.

Quanto à distância do cliente, simples, nós incorporamos ele no processo, ou seja, passa a fazer parte, priorizar, acompanhar, sugerir e fornecer feedback. Feedback é vida.

A ausência de colaboração, nós deixamos claro que é essencial, primordial e que promove resultados. Colaboração é a nova queridinha das empresas inteligentes.

E o grupo desmotivado? Primeiro, tentamos convertê-lo em time (com um objetivo comum), dizemos a meta (plantamos o desafio) e apoiamos para que alcancem os resultados. Neste contexto, o desafio pode ajudar a motivar pessoas, desde que a liderança contribua.

A motivação  é responsabilidade direta da liderança, vem em conhecer bem e cada vez melhor cada integrante do seu time, saber o que motiva cada membro do seu time, avaliar possibilidades para implementar algumas dessas melhoras para o time, mantendo o time blindado quando interferências e riscos de projeto!

Fornecer estas condições promove uma injeção de ânimo no time. Também nos preocupamos em disseminar a colaboração, cordialidade e respeito para todos.

A filosofia Agile tem sim esta característica de RESGATE. Ela lhe estende as mãos. Apenas faça o mesmo.

Agile é vida nova!

Artigo de Fernandes (Facilitador Agile da SPH) e Fabiano Milani (Agile Coach da Massimus C&T)

Requisitos de Software, perfeitos!

João Bom de Requisitos de Souza é diretor comercial de uma empresa de medicamentos, e contratou uma fábrica de software, para fazer um aplicativo para os vendedores externos.

Segue abaixo a descrição do aplicativo, encaminhada à fábrica de software:

“Precisamos de um aplicativo para que os vendedores possam efetuar pedidos no smartphone, consultar a ficha cadastral do cliente e verificar pedidos a serem entregues.

Seria bom também, se pudéssemos fazer os pedidos off-line e depois integrar com o SAP”.

A fábrica contratada tomou as seguintes providências, após receber a solicitação:

– Agendou uma reunião com o diretor João, tirou as dúvidas

– Discutiu com o seu departamento de requisitos e os Devs

– Validaram as ideias com o João

– Elaboraram o orçamento

– João aprovou os custos/prazos

– A fábrica criou o aplicativo

– Agendou uma reunião com João para demonstrar e entregar o aplicativo.

Durante a reunião, João ficou muito surpreso, pois o aplicativo tinha diversas coisas que ele não havia pedido inicialmente:

Alguns comentários de João:

“Nossa! Vocês fizeram a opção de desconto para os clientes com milhagem”

“Que tela bacana este dashboard, não tinha pensado nisso, mas ficou ótimo”

“Ah, esta opção de pagar o pedido na hora via maquininha de cartão também ficou excelente”

“Olha que coisa! Funciona também sem bateria e debaixo d’água”

“Puxa, realmente vocês me surpreenderam, criaram muito mais do que esperávamos. Parabéns! Ficou perfeito o aplicativo”

Ah, nós da fábrica de software (REQUISITOS DO FUTURO), ficamos felizes que o senhor tenha gostado do produto, mas sempre fazemos isso: impactamos o cliente, entregamos no prazo e fornecemos mais itens do que o inicialmente previsto, afinal, temos um método de análise de requisitos excepcional: chama-se PREMONIÇÃO.

Este método, nos permite adivinhar com precisão milimétrica o que o cliente realmente quer. É imbatível!

Se você trabalha na fábrica de software REQUISITOS DO FUTURO, sorte sua, pois consegue adivinhar. Agora, se você é um mero mortal, terá que usar outras ferramentas para identificação e detalhamento de requisitos. E estas ferramentas podem ser a aplicação do mindset Agile.

Fernandes – Facilitador Agile e Colunista Massimus
Certified Scrum Master – Scrum Alliance
Certfield Scrum Product Owner – Scrum Alliance
Agile Certified Professional – IC Agile
Scrum Master Accredited Certification – Scrum Institute
Kanban Management Professional – Lean Kanban University
Blog: canaldevbr.wordpress.com
Twitter: @canaldevbrAgile

Projetos Ágeis – Proclamação do novo regime

Entre a ruptura do regime vigente e a chegada do novo regime, um histórico de fatos de ambos os lados se sucedem de maneira intensa.

Esta batalha tem extremistas de ambos os lados, cada qual com suas razões e verdades.

Seria o modelo vigente tão ruim assim? Apenas defeitos? Problemas? Estaria de fato desgastado?

E o modelo novo? O senhor certinho? Infalível? Regado a entusiasmo? Salvaria tudo e todos?

As dúvidas são muitas… Mas diante da iminência de um novo regime, por que não pensar diferente?

Por que não mudar o Mindset em pleno 15 de Novembro de 1889… ops, Fevereiro de 2001?

Assim como a nossa proclamação da República, o Manifesto Ágil foi um divisor de águas. Um novo olhar é necessário de agora em diante.

E a monarquia? Ops, Gestão Clássica? Diferentemente da história do Brasil, continua sendo uma opção válida.

O que diriam os mais visionários? Por que não juntar monarquia + república? Heresia? Claro que não!

Enquanto isso, nesta 3a feira, feriado da Proclamação da República, 15/11, vale lembrar do Manifesto Ágil como uma tentativa de adotar medidas diferentes, para resolver velhos problemas.

Esta tentativa tem produzido bons resultados e boas discussões,  jogam luz no verdadeiro problema: como entregar projetos para impactar nosso cliente.

Não percamos tempo com Reis ou Presidentes, vamos trabalhar de maneira colaborativa e produzir resultados.

Conheça a consultoria Agile Coaching da Massimus.

Fernandes – Facilitador Agile e Colunista Massimus

Os limites da Vida e os eventos Scrum.

Por que temos limites na vida? Por uma questão de segurança.

Temos limites para:
– Maioridade
– Velocidades nas rodovias/avenidas/ruas
– Carga na bagagem de mão
– de endividamento para compra de imóveis
– horas por dia para trabalhar

Nossa vida é repleta de limites.
Nosso foco aqui é jogar luz no limite, na verdade do limite de tempo dos eventos ( ou cerimônias).
O framework Scrum, possui, além dos papéis de Scrum Master, Product Owner e Dev Team, artefatos, regras e os eventos (cerimônias).

Estes eventos (cerimônias) ocorrem dentro da Sprint

São elas:
– Planning
– Daily
– Review
– Retrospective

São reuniões que possuem um OBJETIVO, a ser cumprido dentro do LIMITE de tempo estabelecido. E evitam outras reuniões.
Aqui são feitos paralelos com os limites da vida, são para não fugirmos do controle.

Exatamente isso, o Scrum define estes tempos máximos para cada evento(cerimônia), pois como os ciclos (sprints) são curtos, observar este limite, nos ajuda a manter a agilidade e focados

E se não tivesse os limites, os timeboxs seriam “ad eternum”, ou seja, as pessoas ficariam discutindo sem chegar num consenso. E o objetivo da sprint dificilmente seria alcançado.

Por isso, impor o limite de tempo, nos ajuda a manter o foco no objetivo.

Não é somente o limite de tempo, cada evento(cerimônia) tem um objetivo claro. E reforçam os pilares do Scrum: Transparência, Inspeção e Adaptação.

Pois sem limites, estaríamos desgovernados!

Entregar resultados em ciclos curtos e de maneira frequente é um grande desafio, requer disciplina, limites, colaboração, comunicação e foco

Ainda bem que no Scrum, os limites “timebox” estão lá, devidamente registrados no Scrum Guide.

Reflexão de Fernandes – Facilitador Agile e Colunista Massimus

Certified Scrum Master – Scrum Alliance

Certfield Scrum Product Owner – Scrum Alliance

Agile Certified Professional – IC Agile

Scrum Master Accredited Certification – Scrum Institute

Kanban Management Professional – Lean Kanban University

Blog: canaldevbr.wordpress.com

Twitter: @canaldevbrAgile

Em um dos treinamento CSPO (Certified Scrum Product Owner) que dei numas das 3 maiores empresas de software do mundo, cujo nome e local do curso preciso omitir, algumas pessoas fizeram perguntas TOTALMENTE destoantes não apenas de Agile mas até mesmo destoantes do Guia do Scrum, cuja última edição foi traduzida pelo meu amigo Fábio Cruz. “É verdade que podemos ter mais de uma equipe por PO?”, ou “Product Backlog é um documento de especificação de requisitos, certo?”, mas a mais matadora foi “acho que o CSPO não apresenta conteúdo utilizado no mercado”. Imaginem só quão míope a visão do aluno foi, pensando que mercado se resume à empresa dele, dado o tamanho da empresa. Isso que implica que não apenas eu, mas Mike Cohn, Jeff Sutherland, Martine Devos, Mike Beedle, entre outros de quem aprendi e troquei experiência sobre Scrum Mastering e Product Ownership não estão alinhados com o que o mercado utiliza. Não seria o mercado que deveria se alinhar com as práticas e cultura Scrum/Agile? Nessa empresa eles estavam “usando” Scrum e SAFe há 4 anos. E isso ocorreu 2 anos atrás. Tomara que as coisas tenham melhorado por lá.

SAFe tem foco em projetos, programas, portfolio. O Scrum não.

Um dos grandes problemas que vejo hoje no mercado são pessoas querendo usar Scrum para executar seus projetos, apenas. O Scrum não se importa em como você gerencia seus projetos, porque Scrum não nasceu para ser um framework de gerenciamento de projetos. Se você ler o post do Ron você verá que ele acha um boa ideia separar nesses três níveis e estabelecer formas de conexão entre eles. Eu acho uma má ideia porque isso tira autonomia das equipes e principalmente porque não fomenta ADAPTABILIDADE.

O Scrum nasceu para reestruturar como você trabalha usando o conceito de timebox de maneira bem enxuta e com ele trazer à tona disfunções que as equipes devem então resolver. Scrum é Lean puro e aplicado. Isso não constrói produtos, mas sim ajuda a construir produtos. Em modelos de governança como Holacracia, Teal e os utilizados em empresas pioneiras pelo mundo (por exemplo, Spotify) vemos a tendência em dar mais autonomia a equipes, assim como uma forte horizontalização ou ainda total quebra da hierarquia. Por que insistir em criar ou manter hierarquias?

Quais os riscos de se implantar SAFe?

SAFe oferece um arcabouço completo demais (talvez com exceção da mais recente versão light chamada Essential SAFe) para implantar Agile em toda a empresa. O problema aqui está no fato de que geralmente acontecem duas coisas perigosas:

  1. Todos podem começar a usar Agile rapidamente com algum (ou nenhum) treinamento.
  2. Todos os envolvidos DEVEM funcionar da forma descrita na governança do framework.

Isso apresenta um cenário muito cômodo para executivos que DEVEM implantar Agile ou Scrum. Com uma “receita de bolo” tudo fica mais fácil. É muita inocência pensar que uma empresa inteira pode funcionar à la Scrum. E mais inocente ainda é assumir o risco de uma mudança processual e de governança sem mudança CULTURAL. Agile é MINDSET, não um conjunto de processos.

Se o SAFe tem esses problemas todos, por que se tornou tão popular no Brasil?

Duas principais razões: ausência de Agile Coaches com experiência e histórias pra contarpara guiar ou refutar uma implantação, mas principalmente falta de desejo, tempo, ou competência, dos executivos responsáveis em se aprofundar sobre os impactos que a adoção de Agile acarreta na empresa.

Encerro aqui minha opinião. Passo agora a visão de Ron Jeffries, um signatário do Manifesto Ágil. Ele gosta MUITO de escrever, ao contrário de mim. Ron fez o curso de SAFe em 2014 e escreveu um post bem interessante, o qual traduzo rapidamente abaixo. Vou encurtar a sua opinião por ser longa demais. Se você quiser ler o artigo em inglês na íntegra, o link se encontra no final deste texto.

SAFe – bom, mas não é bom o suficiente

Recentemente, fiz o treinamento SAFe SPC, com as instrutoras Jennifer Fawcett e Alan Shalloway. Minha avaliação final é que será um sucesso de marketing, dentre as organizações que tentarem obter melhorias, algumas terão uma grande melhora.

E eu não gosto disso. SAFe não é realmente ágil em seu coração. Ele tem muitos bons elementos, que eu vou falar aqui. E eu ainda não gosto disso. Eu vou falar sobre isso também.

Parte do que me impediu de ser totalmente negativo em relação ao SAFe foi a contribuição de Alan Shalloway. Seus valores e abordagens ágeis são muito bons. Isso significava que suas partes no treinamento, e suas respostas sobre o que ele faria em casos reais, mudaram o equilíbrio do que eu acredito que nós teríamos obtido do outro instrutor sozinho.

(…) 

Acho que uma organização que adota o SAFe receberá alguns conselhos muito valiosos e provavelmente irá melhorar. Eles estão, no entanto, em grave perigo de nunca chegarem a Agile como eu o entendo.

(…)

O Bom: coisas para gostar de SAFe

Eu vou falar aqui sobre o que eu gosto sobre o SAFe, com comentários sobre o que “Scrum diz” sobre esses mesmos tópicos. Mesmo que eu goste do que está aqui, não estou dizendo que “o Scrum deveria dizer” coisas assim. Eu acho que os professores e proponentes do Scrum devem dizê-los, e que as organizações que usam o Scrum devem saber sobre essas coisas e aplicá-las.

(…)

Concentre-se no Lean

O SAFe incorpora explicitamente ideias do Lean. Inclui um excelente material sobre Lean Leadership, que fornece pessoas em desenvolvimento, capacitando-as e tirando coisas do caminho.

SAFe também USA diretamente a Análise do Fluxo de Valor, que é quase sempre uma maneira muito poderosa de remover o desperdício da organização.

(…)

Desenvolva com Cadência, e Deliver on Demand

Esse conceito bastante interessante captura a ideia de criar software em iterações e enviá-lo quando as condições de negócios o exigem. Do ponto de vista da venda do SAFe, ele sutilmente sugere que você, o grande executivo poderoso de negócios, pode fazer um release quando quiser, enquanto os pequenos programadores codificam suas felizes iterações de duas semanas.

(…)

Release Train

SAFe desenvolve “Incrementos Potencialmente Entregáveis (PSIs)” usando um “trem de lançamento ou release train” de cinco iterações. (Infelizmente, eles usam o termo PSI diferentemente do Scrum, onde a idéia é produzir um PSI a cada Sprint.)

A ideia no SAFe é que várias equipes estão no mesmo trem e desenvolvem Histórias (no Nível de Equipe) que são acumuladas em Recursos (no Nível do Programa) em cinco iterações. O último desses cinco é um Sprint de “Hardening, Inovação e Planejamento”.

SAFe diz explicitamente “hardening se necessário”. Realisticamente, muitas vezes isso é necessário. Idealmente, gostaria de insistir contra isso. E SAFe faz pressão contra os hardening Sprints: a literatura SAFe é bastante explícita ao considerar três tipos de atividades no hardening:

  • Coisas que você deve fazer e provavelmente só pode fazer no hardening Sprint
  • Coisas que você deveria estar fazendo mais cedo, mas tem que fazer no hardening Sprint por enquanto
  • Coisas que você absolutamente deveria ter feito antes e para as quais você está usando o hardening Sprint como uma “muleta de cascata”.

Este é um conselho bastante sólido. Geralmente, se você ler as palavras no SAFe, há muitos conselhos sólidos. Estou preocupado se o conselho será encontrado, lido e seguido. Muitos dos bons pedaços estão escondidos dentro, como lascas de chocolate muito raras em um cookie.

*Nota do Heitor: esses conceitos não foram ouvidos por NENHUMA empresa que visitei e que usa SAFe.

Nível da equipe

SAFe usa uma versão do Scrum no nível de equipe, que eles chamam de ScrumXP porque inclui “Práticas de Qualidade de Código” específicas adotadas do XP. Nós vamos ver as práticas de qualidade abaixo.

O SAFe tem algumas diferenças importantes do Scrum puro em nível de equipe.

Primeiro, SAFe descreve a equipe de desenvolvimento como sendo composta por “desenvolvedores e testadores”, em vez de ser totalmente multifuncional. Não é que eles digam que não deveria ser multidisciplinar, eles simplesmente não resolvem isso! Observe, tentando ser justo, que suas suposições incluem muita análise de negócios no nível do programa. Se você fizer isso, pode haver menos necessidade desse tipo de habilidade no nível da equipe. Note também, no entanto, que isso reduz a oportunidade de criatividade nesse nível. Isso não é bom.

Para ser justo, o planejamento do SAFe não é de cima para baixo. O nível de programa envia grandes features para as equipes, e as equipes quebram essas informações em pequenas histórias, estimam-nas e relatam o quanto podem realizar. Ou seja, planejamento realizado pelas equipes onde eles decidem quanto pode ser realizado existe apenas da boca pra fora. Planejamento no SAFe ainda é de cima para baixo e fácil de ser mal utilizado.

(…)

Também foi levantado, em nosso treinamento, que o trabalho transmitido do nível de programa e enviado abaixo foi incrivelmente mal alocado entre as equipes, quase garantindo dependências sérias e uma arquitetura inferior. Isso apesar da existência de um arquiteto que estava fazendo o melhor para chegar a algo sensato. Na minha experiência, analisar o trabalho no topo de uma organização quase inevitavelmente leva à má alocação entre as equipes e sempre reduz a chance de soluções criativas.

(…)

No entanto, quando você se comprometeu a usar um grande grupo de desenvolvedores, você precisa resolver esses problemas de alguma forma. O caos e o comportamento de cima para baixo que encontramos devem ser comparados a outra abordagem real, não a uma noção idealista de que você realmente deveria trabalhar com uma equipe menor ou permitir a auto-organização. 

(…)

Práticas de Qualidade de Código

O SAFe tem Qualidade de Código como um dos apenas quatro valores principais. Ele recomenda explicitamente essas práticas, creditando XP para a maioria delas:

  • Arquitetura Ágil
  • Integração contínua
  • Test-first
  • Refatoração
  • Trabalho em pares
  • Propriedade Coletiva de Código

Há pouca dúvida de que essas práticas contribuem fortemente para a capacidade de construir software sólido em mais do que a curto prazo. Tenho o prazer de ver um método e recomendá-los. É um pouco lamentável que tenha que ser seguro para fazer isso. Eu estou olhando para você, Scrum.

O ruim: coisas que não gosto sobre SAFe

Suposição Fundamental do SAFe

A suposição fundamental de SAFe é “você é grande, portanto, você precisa ‘escalar’, portanto, organize-se dessa maneira e imponha essa abordagem”. Isso acaba sendo errado.

Primeiro de tudo, você provavelmente não é grande, você provavelmente é um pouco grande, meio grandinho. Se você é uma empresa listada na Fortune 1000 cheia de programadores, talvez. Se você tiver apenas alguns milhares de programadores, provavelmente não.

Em segundo lugar, a maioria dos seus projetos não é muito grande. A maioria deles pode ser gerenciada por uma única equipe Agile ou por algumas equipes de features Agile. Tudo isso pode ser feito na forma Scrum ou Agile padrão, com um Product Owner capacitado para orientá-los e algumas reuniões conjuntas para manter a coordenação.

Terceiro, a maioria de suas equipes pode não ser realmente Agile. Até que todas as suas equipes individuais possam realmente fazer o que as equipes ágeis fazem, usando todas as práticas de XP recomendadas no SAFe, não é hora de começar a direcioná-las com um processo grande. É hora de treiná-los e adquirir experiência em fazer software corretamente. Depois que eles conseguirem fazer isso, você descobrirá que a maioria deles não precisa de todo esse processo de cima para baixo. O grande processo descrito no SAFe está tentando compensar o problema em vez de consertá-lo.

Em quarto lugar, a maioria dos planejamentos de semana para semana e de mês a mês não requerem um esforço de coordenação de cima para baixo em grande escala. Sim, os seus Product Owners precisam trabalhar ativamente com seus colegas e com seus gerentes de produto ou outros visionários. Mas eles são perfeitamente competentes para trabalhar essas coisas sem impor um grande processo a elas.

Por fim, muitos de seus projetos de várias equipes podem se transformar em projetos de equipe única quando você conseguir que suas equipes sejam competentes para realmente desenvolver o Agile Software Development. Você não precisa construir um grande processo porque você não tem mais um grande problema.

SAFe assume que você precisa de uma grande “solução” e depois a fornece. Mais do que provavelmente você não precisa de uma solução grande. Você pode precisar de coordenação e direção extras em algumas áreas. Torne as equipes todas multifuncionais e Ágeis, divida o trabalho de acordo e veja o que vem a seguir.

O SAFe não é realmente seguro

SAFe fala apenas da boca pra fora ser o que deve se boa prática ágil e enxuta. Essas são as coisas que sua organização deve conhecer, entender e fazer. Não há dúvida acerca disso.

No entanto, o SAFe envolve essas ideias em um pacote projetado – intencionalmente, na minha opinião – para atrair os gerentes e executivos de hoje que não entendem Agile, mas que sabem que têm um problema para o qual o Agile pode ser a solução.

Se todos na organização lessem as letras miúdas no SAFe, a organização poderá evoluir muito lentamente para o nível de eficácia que o Agile real oferece. Isso não vai acontecer. Gerentes e executivos estão ocupados demais para ler as letras miúdas. Eles estão muito ocupados fazendo seu trabalho para estudar como fazer seu trabalho. Eles irão facilmente cair em velhos padrões de comportamento de gestão, e quando o fizerem, o SAFe será instalado de uma forma que não irá falhar em suportar o Agile, mas isso irá suprimi-lo.

(…)

SAFe é bom. Não é bom o suficiente. Isso oferece algum benefício, mas coloca em risco o progresso de uma organização em direção a um funcionamento realmente adaptativo e rápido. Como alguém que esteve no movimento Ágil desde antes de começar, eu não gosto disso. É fast food. Você pode fazer melhor.

Heitor Roriz Filho

Norma Agilis Oraculi

Massimus C&T