Publicado em

SAFe – Agile Release Train (ART)

O ART ou Agile Release Train é um time de times, ou seja, é um conjunto de squads e stakeholders que em conjunto irão dentro de um determinado período planejar, desenhar, executar e entregar soluções em fluxo de desenvolvimento de produto contínuo. Ele é multifuncional todas as disciplinas necessárias para a entrega devem estar contidas no ART (software e hardware).

Além de alinhar todos os times em uma única missão colabora para mitigação de riscos e da variabilidade inerentes a esse tipo de situação no caso de não haver uma organização deste tipo.

Um dos principais objetivos de um Agile Release Train (ART) é entregar features e/ou componentes buscando sempre a minimização de dependências para que o trabalho flua mais rapidamente e com a menor sobrecarga possível.

O ideal é que os times sejam organizados de forma a entregar um novo incremento a cada 2 semanas, deve haver sincronização entre os times para que o ART seja capaz de liberar um incremento com valor para o negócio, é claro que é mais fácil falar do que fazer, é uma operação complexa e que exige um nível de organização razoável dos times e gestores envolvidos, o framework SAFe colabora fornecendo práticas para aplicar cadência e sincronização necessárias.

O Program Increment ou PI é a janela de tempo da qual o ART de forma incremental deve entregar valor conforme o que foi feito pelos times o que pode conter entregáveis não apenas de software, esse timebox tem tipicamente de 8 a 12 semanas divididas pelas “Systems Demos” que ocorrem ao final de cada sprint de forma a permitir a inspeção e adaptação (I&A) .

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Formação, Conflito, Normatização e Performance

Um time que acaba de ser formado evolui passando por alguns estágios de maturidade antes de chegar em sua capacidade ideal, para entender a evolução do time as fases devem ser observadas em suas principais características.

Formação: O time se reúne e toma conhecimento das primeiras informações do projeto como principais features, roadmap em busca de um entendimento inicial com as informações disponíveis, assim como conhecer os pares que serão seus companheiros nesta nova jornada, tipicamente as pessoas neste primeiro momento são mais cuidadosas em relação as suas opiniões e nas interações.

Conflito: As opiniões começam emergir o que pode por vezes causar certo desconforto e alguma tensão devido ao fato de que as decisões precisam ser tomadas muitas vezes baseando-se em informações incompletas devido ao momento do projeto e o nível de incerteza, o time precisa ser orientado a entender o valor da diferença de opiniões e as vantagens adivindas deste fato.

Para que um time evolua as ações necessárias devem ser direcionadas conforme o estágio (fase) atual em que o time se encontra, durante a jornada haverão momentos ideais para focar em cada fase de forma diferente ajudando as pessoas e o time a se tornarem mais eficientes

Normatização: O consenso é alcançado na maioria dos aspectos do projeto e o time ganha coesão, fica mais eficiente, todos tem o entendimento do escopo do trabalho e seu papel dentro do time e os objetivos que precisam ser perseguidos.

Performance: O time está atuando de forma auto-organizada tendo os objetivos compartilhados totalmente claros e performa de forma altamente colaborativa criando suas próprias soluções com o mínimo de dependências externas, movendo-se de forma dinâmica.

Alguns eventos podem afetar a dinâmica da evolução do time como a adição de novos membros ou mudanças significativas no escopo do projeto ou no ambiente do projeto ou organização e isso deve ser considerado pois pode causar alguma regressão no status atual do projeto, fique atento.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Team Building

Para que um time se torne forte é importante que se forme uma identidade compartilhada da equipe, para tal precisamos propiciar um ambiente que possibilite as pessoas descubrirem coisas novas sobre as outras, tanto do lado profissional quanto do pessoal, isso facilita o andamentos das coisas.

O team building é sobre utilizar atividades colaborativas para que as pessoas se conheçam melhor durante uma jornada pela busca de objetivos compartilhados, existem algumas dinâmicas que podem ajudar de forma eficiente com esses objetivos.

Com a utilização das atividades de Team Building podemos viabilizar uma consciência coletiva dando início ao aprendizado da equipe sobre ela mesma conforme o conjunto de habilidades e crenças reveladas.

A atividade de valores (Kouzes e Posner, 2007) dá a oportunidade para que o time explore suas características internas.

  1. Cada pessoa recebe um baralho de cartas;
  2. Nas cartas temos palavras que representam valores (Ex: Resiliência, Produtividade, Protagonismo, Felicidade etc ;
  3. Cada pessoa divide as cartas em duas partes, valores importantes e não importantes;
  4. Na sequência cada um pega a pilha de valores importantes e repete a operação até que fiquem apenas 5 cartas;
  5. Cada pessoa escreve seus valores no quadro ou flip chart;
  6. Pergunte ao time o que a visão montada naquele momento representa para o time, aonde estamos de acordo ou não, medie as conversas do time;

Lembre-se de direcionar o time para que mantenham a mente aberta, não julgar mas sim entender, como resultado essa atividade deve servir de insumo para que o próprio time comece a se conhecer de forma mais intimista e consequentemente possa se desenvolver mais rapidamente conforme as pessoas interagem no caminho.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Conversas informais do time.

É vital para evolução do time que a observação seja exercitada de forma competente, para tanto é necessário estar atento não apenas as conversas formais que acontecem nas cerimônias como a planning ou a review, mas também nas conversas que acontecem em outros momentos.

Muitas coisas úteis pode ser encontradas nesses momentos além das oportunidades de treinamento do time, as ferramentas que podem ser utilizadas estão nas observações e perguntas que podem clarificar ou inspirar as pessoas a evoluirem.

Boa parte do tempo o time mantém conversas informais que podem servir para geração de ativos importantes que ajudarão o time a evoluir, essas oportunidades devem ser utilizadas também para treinar o time, portanto esteja atento a essas situações para colaborar.

Deixe claro ao time que você acredita que eles podem fazer mais e melhor, ajude-os a descobrir novas habilidades conforme as necessidades atuais sem se esquecer que o time deve saber o que deve ser priorizado, muitas vezes a forma de se fazer uma pergunta pode fazer a diferença.

Esteja preparado para o silêncio nas primeiras “incursões”, isso é muito muito normal, por vários motivos, é importante fazer as colocações de forma isenta, as perguntas ou observações devem ser neutras de forma que as pessoas se sintam a vontade para contribuir, preste atenção no que está acontecendo com o time para que sua colaboração seja mais efetiva.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Facilitando a Retrospectiva.

A retrospectiva é um momento em que o time faz uma pausa para uma auto análise, verificando o que houve durante a sprint, é importante que o time seja orientado a não só analisar o que foi feito, mas principalmente o como.

Durante a sprint, observe como as coisas acontecem, vá registrando as situações que funcionam bem ou que precisam melhorar, permita que o time rode a sprint sem interferir, no caso de times com menos experiência é possível que sejam necessárias intervenções pontuais, porém sem atrapalhar o andamento da sprint.

Observe também como o trabalho flui, quais os problemas de comunicação e coordenação aparecem, os momentos em que eles fazem a coisa certa, como estão emocionalmente, quais tipos de situações causam variação na moral do time.

Perseguir a realização de retrospectivas que viabilizam a melhoria do time é algo indispensável, a facilitação para torná-la efetiva é fator crítico para o avanço, ajude-os.

Colete essas informações para preparar um tipo de pauta para a restrospectiva, tente direcionar para o tema mais relevante e que tem potencial de trazer maiores ganhos, no início da reunião pergunte a opinião do time sobre a relevância dos assuntos, dê sua sugestão mas permita que escolham o que é mais prioritário para discutir.

O time deve inspecionar e adaptar, ações de melhoria devem ser determinadas com responsável e devem ser verificadas na reuniões de retrospectivas subsequentes, para ajudar que se cumpram os compromissos assumidos lembre-os, deixe a lista em um lugar visível aonde todo o time possa ver.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Você sabe a diferença entre Wireframe, Mockup e Protótipo ?!

Um recurso muito utilizado nos dias de hoje e que pode evitar muita dor de cabeça e desperdício de dinheiro é a utilização de Wireframe, Mockup e Protótipos, antes de começar a codificar, isso alinha o entendimento das partes envolvidas, evita retrabalho e dependendo da necessidade do projeto você pode usar um deles ou os três em conjunto, cada um com características específicas, veja a seguir.

É muito comum antes de começarmos um desenvolvimento que exista a necessidade de confirmação de como serão as telas que serão criadas, desenha-las logo de cara exatamente como serão pode ser um desperdício de tempo, neste caso o rápido é mais devagar e o devagar é mais rápido.

Wireframes mostram apenas um ideia geral de como deverá ser o que está sendo projetado, são muito simples e tem um custo baixo, tem baixa fidelidade e neste ponto ainda não estamos pensando como será viabilizado tecnicamente, neste ponto queremos fechar a estrutura e layout básicos.

Mockups são imagens estáticas de como a versão final do produto irá se parecer, é importante no apoio da definição de coisas como tipografia, estilo, representação visual, cores e etc. É um design representando o que foi desenhado na forma de wireframe (que é o passo anterior) porém com uma fidelidade maior especificando mais detalhes, esse tipo de artefato tipicamente é produzido por designers.

Protótipos nos permitem explorar a interface do usuário procurando possíveis problemas no fluxo além de deixar mais clarificado (já que é possível interagir) o que deve ser feito facilitando também melhorias no que foi planejado até então. Esse artefato é fundamental para realização de pesquisa de usabilidade, também fica mais fácil pra vender caso precise convencer alguém que o que está fazendo é uma boa ideia.

Cada artefato tem o seu papel e valor no passo em que o design da aplicação está, são interrelacionados e vão aumentando a fidelidade conforme o avanço no processo, para resumir:

  • Wireframe trata a estrutura; (Baixa fidelidade)
  • Mockup a parte visual; (Média fidelidade)
  • Protótipos são para interação e usabilidade; (Alta fidelidade)

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Facilite a Revisão da Sprint

O time deve organizar a reunião que tem o objetivo principal demonstrar o que foi produzido na última sprint executada, não é preciso nada muito elaborado, porém deve ser o suficiente para que as partes interessadas na reunião possam entender o que foi entregue.

Podem começar dizendo o que foi feito em relação ao que foi planejando anuciando quais funcionalidades serão demonstradas pelo time, instrua-os a mostrar utilizando as funcionalidades contando as necessidades que serão atendidas conforme o andamento.

Instrua os stakeholders a fornecer o feedback dando entendimento ao time se os objetivos foram alcançados e se não, quais são os motivos que os levaram a essa conclusão.

A Review é a hora da verdade, o Product Owner deve verificar se o que foi feito pelo time endereça ao que foi planejado, porém além disso há outros objetivos que precisam ser levados em conta, oriente e deixe o time tocar, exerça a observação para posteriormente conversar com o time e fazer os devidos ajustes.

Aproveite para falar de alguma situação/impedimento que está alheia ao time e que as partes interessadas podem ajudar a solucionar, se não puderam ajudar, ao menos ficaram a par das pendências de forma atualizada.

Observe as interações entre o time de desenvolvimento, product owner e partes interessadas, fique em silêncio mas tome nota do que será necessário conversar com time em formato de sugestões para o próximo ciclo.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Facilite a Planning !!!

A planning é a primeira cerimônia de uma sprint, para que ela alcance seus objetivos com sucesso algumas ações precisam ocorrer antes desta reunião, são atividades que envolvem todo o time.

É necessário garantir que o Product Owner esteja com itens do backlog preparados de forma que todo o time possa entender o valor de negócio e o porque foram priorizados, para tanto o time precisa ter conhecimento desses itens do backlog em um momento anterior a planning, pode ser feito na reunião de refinamento.

Na reunião de refinamento, o Product Owner explica os itens que estão sendo preparados em busca da colaboração do próprio time para essa tarefa, o time de desenvolvimento deve contribuir durante o entendimento dos itens que estão sendo explicados pelo Product Owner.

A Planning é um dos eventos mais importantes do Scrum, antes desta reunião deve haver uma preparação que compreende algumas atividades que devem ser executadas pelo próprio time e que impactam diretamente a consistência e a dinâmica da reunião.

O time deve estimar o esforço determinando quais seriam as principais tarefas a serem executadas em cada item. Aproveite para observar as oportunidades de aprendizado que irão surgir, faça perguntas para ajudar a clarificar o entendimento do está sendo tratado, questione sobre o entendimento do valor agregado de cada história e qual o benefício para o usuário final.

Lembre-se dos limites entre os papéis, o Product Owner determina o que deve ser feito e o time de desenvolvimento define o como será feito, apesar da colaboração entre todo o time que deve ser incentivada, não podemos esquecer quem é responsável pelo quê, ajude-os a se organizar.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Facilitando a daily !!!

O time tem a oportunidade de realizar a coordenação dos trabalhos de forma a entender em conjunto qual é a melhor ordem para a execução das tarefas do momento conforme possíveis dependências por exemplo.

Oriente o time a focar principalmente no que está em andamento, assim fica mais fácil para que todos saibam o que está acontecendo no momento, para isso peça que foquem nas tarefas em andamento, controle o WIP.

Continue tentando a ajudar o time, porém não os poupe das consequências de suas decisões caso a daily não esteja sendo feita a contento, a evolução irá acontecer no devido tempo do time, ajude-os a reconhecer o que pode melhorar, continue em movimento.

É fundamental que todos estejam prestando atenção na pessoa que está falando fazendo contato visual, caso isso não seja feito a reunião perde sua efetividade, oriente-os sem animosidade.

Ensine o objetivo da reunião e se afaste, observe como eles irão rodar a daily, caso o time seja novo talvez seja necessário intervir no momento, porém se possível deixe para fazer as observações em momento posterior e deixe rolar, se estiver remoto entre na call mudo e saia calado.

Na restrospectiva ofereça suas observações, porém sem julgamentos, fale de forma neutra e deixe que eles cheguem as próprias conclusões, é a oportunidade para inspecionar a adaptar, seja gentil.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Treine o Product Owner.

Quando precisamos começar a trabalhar com ágil com equipes que não tem experiência com o assunto temos várias iniciativas que precisam ser colocadas em andamento para suportar esse objetivo, um deles é treinar as pessoas que foram indicadas para se tornarem Product Owners.

É necessário levar em consideração o background da pessoa pois isso influência diretamente como o treinamento será estruturado ao longo do caminho, o treinamento deve ajudar essas pessoas a fazer a transição para o novo papel.

Devemos orientá-los para que possam começar a direcionar o valor de negócio sendo responsável pela visão do produto tomando decisões diárias protegendo o produto de investidas externas que não estão de acordo com os objetivos estabelecidos.

Ser um bom Product Owner vai além de preparar o backlog, trabalhar em equipe e suportar a visão do produto de forma convincente, outras habilidades são necessárias e precisam ser desenvolvidas por quem desempenha o papel durante a jornada.

Devemos abordar os aspectos mais importantes que possam colaborar com a capacidade do time de entregar e melhorar assim como os aspectos que podem afetar essas questões de forma negativa e como mitigar os impactos, isso varia de um lugar para o outro.

O treinamento a ser ministrado deve levar em consideração a maturidade não só da pessoa em questão mas do ambiente em que está inserido assim como experiência e expertise nos negócios e na metodologia ágil, considere que o treinamento acontece durante a jornada e não apenas dentro de uma sala.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!!