Olhando o Manifesto Ágil pela visão do Product Owner

O que sustenta a ponta de um iceberg dentro de um cenário ágil, seja em uma organização, time ou até mesmo um papel, é o Agile Mindset. Essa nova mentalidade que o ágil nos leva a entender, está estabelecida por meio de 4 valores, fundamentados em 12 princípios, ou seja, Manifesto Ágil, e manifestada através de diversas práticas, técnicas e métodos diferentes.

agile-mindset

Há uma grande distância entre ser ágil e estar fazendo ágil. Como Product Owner temos um radar de práticas, técnicas e métodos para ajudar de acordo com o contexto que estamos trabalhando, com isso, precisamos internalizar esse Mindset que está fundamentado e estabelecido no Manifesto Ágil e em momento algum podemos feri-lo.

Os valores do Manifesto Ágil:

INDIVÍDUOS E INTERAÇÃO mais que Ferramentas e Processos

SOFTWARE FUNCIONANDO mais que Documentação Abrangente

COLABORAÇÃO COM CLIENTE mais que Negociação de Contratos

RESPONDER A MUDANÇAS mais que Seguir um Plano

O Manifesto é composto de valores e princípios, assim como cada um de nós, para preservar um valor na sua vida é preciso definir alguns princípios, por exemplo: você pode torcer para seu time do coração e, para preservar esse valor na sua vida, é necessário estabelecer alguns princípios, como: ser um sócio torcedor, assistir todos os jogos, assistir pelo menos um treino apronto no mês, comprar camisa oficial. Certamente seguindo esses princípios esse valor de torcer para um time favorito estará vivo em seu dia a dia.

Abaixo temos 12 princípios que preservam os 4 valores do Manifesto Ágil.

Vamos destacar os princípios de bolso de um Product Owner:

  1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor – O Product Owner é responsável em criar, priorizar, fatiar e manter o product backlog, ou seja, é o dono do backlog (única fonte de requisitos do produto). A forma que o Scrum manifesta esse primeiro princípio é através de ciclos curtos que se chamam SPRINTS, com isso, o Product Owner determina o que é prioridade para o cliente no primeiro momento, buscando sempre a satisfação do cliente, e antecipa o poder de entregas (lembrando que não é somente entregar, também gerar percepção de valor em cada entrega).

visao-do-po_3

  1. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas – O Product Owner precisa entender que o cliente não está comprando o produto, mas sim investindo no produto, certo que em um curto espaço de tempo terá esse retorno. Com o foco em fazer o cliente tirar vantagens competitivas de mercado, o PO precisa estar aberto a aceitar mudanças. Quem nos disse que um plano não pode mudar? a única certeza que temos em desenvolvimento de produto é que ele vai mudar, mas com métodos ágeis isso vai acontecer o mais cedo possível, com isso, existe a necessidade de adaptação para responder à mudança sem traumas, lembrando que mudanças sempre são bem vindas. Os requisitos podem mudar a qualquer momento, o que é normal e aceitável, é necessário gerenciá-los conforme suas prioridades. Se os seus requisitos não mudam, tem alguma coisa de errado.
  1. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos – O Product Owner precisa decidir quais funcionalidades são prioridade no primeiro momento, fatiar pequenos incrementos com valor para o cliente. A entrega constante gera a percepção de rápido, pois o objetivo é entregar o mínimo o mais cedo possível para o cliente e gerar o feedback antecipado, gerando assertividade, ou seja, maior frequência de planejamento e maior qualidade das entregas. Com o conceito MVP, tudo isso fica mais claro, pois o objetivo é escolher o mínimo do produto necessário, colocar na mão do cliente e o cliente determina se é viável para evidenciar o aprendizado emergente do produto. O Product Owner pode trabalhar a concepção do produto para entender o todo e priorizar o que precisa entregar. Nesse momento os detalhes não são importantes (detalhes são refinados durante o tempo) e o esforço inicial não deve chegar a duas semanas, apenas dias.

visao-do-po_2

  1. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente durante todo o curso do projeto – O Product Owner está sempre engajado e disponível para o time de desenvolvimento, respondendo a quaisquer dúvidas relacionadas ao negócio. Durante sessões facilitadas, é importante o envolvimento dos desenvolvedores com as partes interessadas, facilitando o entendimento do negócio.
  1. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho – O Product Owner está muito próximo do time de desenvolvimento e é importante que todos saibam que ele faz parte do time (Scrum). O PO deve ter o conhecimento necessário sobre o negócio assim como ter toda confiança para que possa fazer seu trabalho, precisa priorizar o que deve ser feito, tem que ter poder de decisão e, principalmente, saber dizer “NÃO” para necessidade do cliente quando não está alinham com a visão do produto.
  1. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara – O Product Owner é responsável em manter o Product Backlog priorizado e com valor, o time de desenvolvimento em entregar o que está se comprometendo em cada Sprint. Com isso, há uma aproximação forte através de conversas ativas e sessões facilitadas, colaborando constantemente para entender os itens do backlog que podem ser apresentados por User Stories. Valoriza os momentos de conversas cara a cara para dar o entendo de negócio do que está representado através das User Stories, lembrando que ela é apenas um “lembrete” da necessidade do cliente, ou seja, fornece um flash da comunicação, representa os requisitos (necessidades) mais do que documentá-los. Os melhores documentos nos ajudam a recordar nossas conversas, eles não a substituem. Para provocar a colaboração de todas as partes interessadas, pode-se adotar ferramenta simples, como cartões, post-it, papéis, flip-chart, paredes ou quadro em branco, certamente incentivará a comunicação ativa de todos interessados no produto.
  1. Software funcional é a medida primária de progresso – Todo incremento do produto representa uma entrega funcional de valor do produto para o cliente. O Product Owner é o responsável por demonstrar esse progresso de valor para todos interessados.
  1. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes – O Product Owner entrega o que precisa ser desenvolvido para o time, ajudá-lo no entendimento do negócio para que o time possa fatiar e estimar. O trabalho do Product Owner de refinamento dos requisitos é um esforço contínuo durante todo o projeto.
  1. Contínua atenção à excelência técnica e bom design, aumenta a agilidade – O Product Owner contribui constantemente ajudando o time de desenvolvimento a entender a visão e roteiro do produto, seus objetivos de negócio e principais features, deixando claro todo contexto de negócio, com isso o time facilmente consegue identificar riscos técnicas, arquitetura, buscando sempre a excelência técnica.

  1. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito
    –  A principal ferramenta do Product Owner é dizer “NÃO” para um item entrar no backlog. Todo o esforço de refinamento do Product Owner está nos itens de maior prioridade para o cliente, ou seja, saber o que é importante para o produto e saber o momento certo de parar, neste cenário “menos é mais”.
  1. As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis – O Product Owner é o responsável pelo backlog e definir sua prioridade, mas em um projeto todos têm toda condição, habilidades e conhecimento necessário para auto organizar e se comprometer com o trabalho que precisa ser feito.
  1. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo –  O Product Owner reconhece que o seu papel precisa se adaptar e melhorar a medida que o produto evolui e está bem alinhado com todo o processo. Retrospectivas frequentes conduzem a melhoria contínua e a forma como o time trabalha para maximizar o valor para seus clientes.

visao-do-po

___________________________________________________________________________________________________________________

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Agile, Product Owner, Scrum

Quem é o Agile Tester?

A definição

agile-tester-artigo1Segunda Lisa Crispin e Janet Gregory em seu livro Agile Testing: A Pratical Guide for Testers and Agile Team [1] o que define o Agile Tester é:

Definimos o Testador Ágil neste sentido: um profissional que encara as mudanças, colabora bem com pessoas técnicas e de negócio e entende o conceito de usar os testes para documentar os requisitos e guiar o desenvolvimento.

Testadores Ágeis tendem a ter bons conhecimentos técnicos, e sabem como colaborar com outros membros do time para automatizar testes e também são experientes em executar testes exploratórios.

Eles estão dispostos a aprender o que os clientes fazem para que eles possam entender melhor os requisitos.

Eu, propositalmente, dividi em três partes para ficar mais visível tudo o que um Agile Tester é e o que ele pode fazer!

Mas a primeira resposta a pergunta “Quem é o Agile Tester?” é: qualquer pessoa do time!

Porque qualquer pessoa pode pegar uma tarefa de teste para executar. Qualquer pessoa pode pensar como um usuário no momento de um planejamento. Qualquer pessoa pode executar um teste exploratório.

Para alguém do time possuir estes skills, primeiramente, ele precisa ter o MindSet do Teste Ágil.

O MindSet do Teste Ágil

agile-tester-artigo2O time, ao invés de entregar o melhor produto, deve entregar o melhor valor de negócio para o cliente através de um produto, certo?

A grande maioria dos times focam em entregar o melhor produto, mas nem sempre o melhor produto traz o melhor resultado de negócio.

É aqui que o MindSet entra: trocar informações constantes e colaborar com o cliente* a fim de ajuda-lo a expressar de forma adequada os requisitos.

O restante dos pontos é a viabilização disso (tarefas). O MindSet é único: colaboração com o cliente para que ele mesmo entenda o que está pedindo.

Alguns itens que podem ser adicionados ao MindSet são:

  • Criatividade
  • Estar aberto a novas ideias
  • Disposição para assumir qualquer tarefa
  • Foco no cliente
  • Visão constante na Big Picture (no todo)

* a palavra “cliente” pode ser interpretada como o cliente real ou o product owner (dono do produto)

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Agile, Técnico, Testes, Time de desenvolvimento

Product Backlog Building

Scrum é um framework para gerenciamento de produtos, baseado em desenvolvimento iterativo e incremental. O seu ciclo inicia com uma lista de funcionalidades desejadas para o produto, priorizada pelo cliente, então o time escolhe as funcionalidades que se compromete em desenvolver, geralmente com iterações de 1 a 4 semanas.

Podemos notar que esse ciclo é bem definido, tendo como ponto de partida o Product Backlog, mas o Scrum não tem nenhuma definição de como construir um Backlog. Sempre nos deparamos com as perguntas:

Como chegar ao Backlog?

Como construir algo que tenha valor?

Como encontrar a real necessidade do cliente?

Como definir o que é prioridade para o cliente no primeiro momento?

Tentando responder essas perguntas, depois de diversas experiências em vários clientes, nasceu o “PBB – Product Backlog Building”. O PBB tem como principal objetivo ajudar na construção de um Backlog de uma forma compartilhada, construindo um entendimento compartilhado, levando todos os envolvidos ao entendimento colaborativo do domínio do negócio, ou seja, todos compreenderem o contexto do negócio.

A dinâmica do PBB consiste em vivenciar na prática a construção do Product Backlog utilizando o Backlog Canvas como ferramenta. Essa dinâmica leva todos os envolvidos do negócio a uma experiência prática de elaboração e definição de um Product Backlog efetivo totalmente consistente e alinhado com os valores de negócio do cliente.

Principais benefícios:

  1. Ajudar na construção de um BACKLOG de um forma efetiva e colaborativa.
  2. Construir um entendimento compartilhado do negócio do cliente, facilitando a descoberta e compreensão do produto.
  3. Buscar uma maneira de descrever a experiência do usuário com o produto.
  4. Facilitar a descoberta e escrita de User Stories.

 

 

PBB é representado por um canvas chamado de Backlog Canvas que tem um fluxo bem simples e de fácil compreensão, principalmente para facilitar o entendimento do cliente, pois sua participação é de suma importância nesse processo de construção.

Veja abaixo o fluxo de construção do Backlog:

IDENTIFICAÇÃO: A primeira etapa é identificar o produto que será construído.

PROBLEMAS: Nesta etapa o ponto de partida é identificar e compreender o Estado Atual pontuando um conjunto de problemas, neste momento as partes interessadas buscam de forma colaborativa a mesma compreensão do estado atual, pontuando os problemas que desejam que sejam resolvidos. É importante conhecer o problema antes de criar a solução.

EXPECTATIVAS: Nesta etapa é importante identificar o Estado Desejado, alinhando suas expectativas aos problemas do estado atual, para que, de uma forma compartilhada, todos os envolvidos possam alinhar suas expectativas.


PARTES INTERESSADAS: Nesta etapa saiba quem são os usuários, papéis e responsáveis envolvidos no negócio. Alinhando seu contexto de negócio, suas atividades de negócio, seus problemas e dores, necessidades e objetivos.

 


ÁREAS DE NEGÓCIO:
A partir desse momento, identificado as PARTES INTERESSADAS, identifique as suas ÁREAS DE NEGÓCIOS e os principais objetivos de negócio das partes interessadas de cada área.

 

 

 

 

 

 

 

 

ATIVIDADES DE NEGÓCIO: Em seguida, identifique as ATIVIDADES DE NEGÓCIO de acordo com suas respectivas ÁREAS DE NEGÓCIO já identificadas, as atividades que cada PARTE INTERESSADA realiza dentro do negócio, mapeando na sequência de uso da esquerda para a direita. Descreva a ATIVIDADE DE NEGÓCIO com uma breve descrição da atividade, sempre pontuando o “Problema” e a “Expectativa” da parte interessada relacionada a essa atividade de negócio.

overview-product-backlog-building-atividade-de-negocio

FUNCIONALIDADES: Finalizando as etapas, para cada passo da ATIVIDADE DE NEGÓCIO, escreva as funcionalidades que satisfaça, podendo representá-las por User Stories ou modelo ARO (<AÇÃO><RESULTADO><OBJETO>). Construindo a lista de funcionalidades, podendo organizar(priorizar) verticalmente o que é mais importante.

 

Essas são as etapas de forma resumida do “PRODUCT BACKLOG BUILDING”. Etapas que compõem o Canvas:

[Identificação > Problemas > Expectativas > Partes Interessadas > Áreas de Negócio > Atividades de Negócio > Funcionalidades]

*As três últimas etapas são baseadas no conceito do FBS (Feature Breakdown Structure) do FDD.

O fluxo de uma forma linear ajuda a organizar a visão geral do negócio e alinhar o valor de negócio, a compreensão e o que o projeto irá agregar ao final, junto com a ferramenta “Backlog Canvas” que ainda deixa todo o levantamento de requisitos organizado de forma visual.

 

Como resultado teremos um Product Backlog totalmente alinhado com o valor de negócio do cliente.

O Scrum não fala como podemos representar cada item no Backlog, podemos escrever de várias forma, inclusive de forma textual. A User Story é a forma mais usadas hoje pelos times ágeis para representar um item no Backlog. História de Usuário é uma breve descrição do que é necessário para o cliente ter no produto, que pode representar uma necessidade do usuário ou uma descrição de uma funcionalidade.

A estrutura de uma História de Usuário basicamente responde 3 perguntas: QUEM? O QUE? POR QUÊ?

 

O PBB nos ajuda na escrita das User Stories. Como podemos notar no PBB temos o “QUEM?” que é a Parte Interessada, o “O QUE?” que nesse caso são as funcionalidades já representadas em modelo ARO e por último, o “POR QUÊ?” que está no objetivo e benefício que a parte interessada destacou na atividade de negócio.  A figura abaixo exemplifica de uma forma bem simples como fica fácil escrever as User Story com ajuda do Product Backlog Building.

 

Como podemos perceber o grande poder do PBB é a facilitação e a colaboração que provoca com todos os envolvidos na construção de um Backlog, sempre levando todos a  um entendimento compartilhado do contexto de negócio e a descoberta de itens do Backlog totalmente alinhado com o valor de negócio do cliente.

Pronto! todas as funcionalidades descobertas representarão os itens do Backlog. Agora é só priorizar o Backlog usando quaisquer técnica de priorização e começar entrar…

Baixe aqui o seu Backlog Canvas e comece a construir seu Product Backlog:

Vídeo: Product Backlog Building com Fábio Aguiar | Test-Drive

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

3 Comentários »

Categorias deste post

Agile, Scrum

Você deve ler o Scrum Guide com frequência!

O Scrum é um framework de desenvolvimento descrito em um guia de dezesseis páginas e como praticante você deveria lê-lo com frequência.

Isso mesmo, o Scrum é um framework com um texto curto, direto e simples. Um bom significado para Simples é “o que é elementar, não apresentando qualquer embaraço para sua compreensão.” Ou seja, no Scrum Guide temos apenas o que é elementar para o desenvolvimento de produtos com o objetivo principal de ser um guia de fácil compreensão.

ScrumButAo mesmo tempo, colocar em prática como descrito no guia não é uma tarefa fácil. Qualquer praticante sabe que praticar Scrum é fácil na teoria todavia a prática do dia a dia é muito mais dolorosa. É muito fácil e cômodo cometer desvios e começar a executar o famoso ScrumBut.

Você executa ScrumBut quando você diz coisas como: “eu prático Scrum mas não faço reunião diária”, “eu uso Scrum mas minha área de negócio não sabe e eu não tenho PO”, “eu pratico Scrum mas tenho sprint só de documentação”.

Aparentemente, não parece haver problema ao se executar um Scrum pela metade, ou faltando uma perna, porém o Scrum é baseado em teorias complexas, como executar ciclos diários de PDCA (Planejar, Desenvolver, Checar e Agir).

A reunião diária é o momento do Scrum que obriga o time a executar um ciclo de planejamento, execução, checagem e ação todos os dias. Ou seja, não fazer a reunião diária implica em não fazer o ciclo diário de PDCA e no longo prazo alguém vai pagar essa conta.

Em cada um dos ScrumButs exemplificados passa-se por cima de alguma teoria que embasa o Scrum.

O Scrum é um framework simples mas emergiu a partir de um time de desenvolvimento que estava cansado da forma antiga de trabalhar e que estudou muito para elaborar o framework. Os criadores do Scrum estudaram teorias de relacionamento interpessoal, teorias de produtividade de times e indivíduos, teorias de linhas de produção enxuta.

Ou seja, criaram um framework simples e que é embasado por teorias complexas.

leitura-scrum-guideAo ler o framework com frequência você tem menos chance de corroer um pedaço dele por desconhecimento e terá, assim, um conhecimento do que é Scrum de forma mais concreta.

Outra coisa importante é saber o que faz parte e o que não faz parte do Scrum.

O Scrum é um framework enxuto e no qual o praticante pode preenche-lo com os recheios que fazem sentido para um projeto específico. Muito do que se comenta sobre Scrum em blogs e livros dizem respeito aos recheios e não ao core do Scrum. Por exemplo:

  • User Story não faz parte do Framework do Scrum mas você pode usar;
  • O quadro de kanban não faz parte do Scrum mas quase todo mundo usa;
  • A reunião diária não precisa ser em pé em frente ao quadro mas é mais produtiva se realizada desta maneira.

Poderia ficar enumerando vários outros benefícios, o que ficaria cansativo…

Mas para finalizar:

O Scrum Guide é a base do framework mais utilizado em projetos ágeis hoje em dia e demora menos de 30 minutos, inicie a leitura agora! :)

Referências

ScrumGuide

Scrum, A arte de fazer o dobro do trabalho na metade do tempo. Jeff Sutherland

VersionOne. State of Agile Survey 2011.

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Agile, Scrum

Agile Fundamentals: the basics, the simple

There are many flavors of Agile: XP, Scrum, FDD, Kanban, SAFe, LeSS and so on. These are called “agile frameworks”, and each has its own goal: XP is focused on developing a software, Scrum is focused on organizing a team process and SAFe is focused on projects at scale. Although the many and obvious differences between the frameworks (goals AND practices), they all talk the same language: Agile.

 

The Scrum effect
Scrum is the most didatic and popular framework. It’s easy to use, and yet brings lots of challenges on its use. The Scrum Alliance offers well-marketed and well-accepted certifications to differentiate professionals that are trained in using Scrum to deliver software. So, although I think XP still is the most complete agile framework for a team, many companies are beginning their agile journey through Scrum. Many people think Scrum is synonym of Agile.

 

Rude awakening
There are many software professionals around the world. Sooner or later, a Scrum-only professional will stumble upon someone that delivers software very well using Kanban, or using only XP. This is really common. And, usually, this is not a kind moment: at this moment, the Scrum professional realizes that there is something much greater than Scrum. This is Agile. And than a new (and huge) journey begins: understanding the hole Agile universe through the study and experimentation of its great variety of frameworks, the discovery of new roles and disciplines and the abstraction of a method.

 

Increments, short cycles and feedback
This is the essence of Agile. If you or your team deliver software through small increments demonstrated in short periods of time to collect feedback that will influence the software you’re developing (and the process you’re using for it) you’re doing Agile. You don’t even need to name the process you’re using. You’re just delivering software.
Depending on the context you and your team are developing software (a 5 people startup or a 6.000 people huge company) you’ll need totally different sets of tools and processes to deliver small increments of software in short cycles and collect feedback. Here comes the variety of Agile frameworks available for us to use.

 

Focusing on the Agile fundamentals
The International Consortium of Agile (ICAgile) is offering a set of training and certifications focused on working with Agile, no matter the framework you’re using. The main concern of ICAgile is to teach people the essence of Agile and how to work with it, from gathering requirements to testing a software. It doesn’t offer any kind of framework or process, helping people to understand the mindset behind every existing Agile framework, and making it easier and safer to use/merge the frameworks depending on the problem you’re trying to solve.
Because the ICAgile certification process focuses on teaching people how to deliver software with an Agile mindset, and not on specific mechanics and processes, I truly believe these training tracks, much more than their certifications, can help us guide software professionals through real Agile software development/delivery.

Nenhum comentário »

Categorias deste post

Agile, Certified Agile Professional

5 lessons learned Coaching big companies

kratos-cover

Over the last year, Rafael Nascimento and I have been helping a big company through its global transformation towards the Agile state. This initiative has been a great experience for the whole Adaptworks team. We spent a lot of energy and we’ve got a lot of insights into how agile could be adopted by big companies. So, we would love to share with you our 5 key lessons from this case.

We won’t talk about the process or any internal decision made at this company but we’ll discuss in the next few paragraphs about our perspective as Agile Coaches. For this reason, the aim of these tips is to help other Agile Coaches to improve the action through some changing processes.

Let’s go to the tips:

  1. Combine the two hats – Agile Coaching is actually a combination of two approaches – Coaching and Mentoring. Remember that there’s a huge difference between both. When you’re acting as a Mentor, you provide the correct answers to solve some kind of problem. When you’re acting as Coach, you provide a set of questions to help people to find out the answers by themselves. So, it’s important to make this difference pretty clear to the audience. In addition, it’s vital that the Agile Coach recognises in which kind of situation Coaching and Mentoring could be applied.
  2. Pull coaching instead push coaching – After the startup phase, let people pull the Coaching or the Mentoring on demand. I mean, avoid pushing your service to people. Most of the time, only when people become aware of their problems, do they get the sufficient awareness and the motivation to accept Coaching. This is also a basic principle in Coaching. Many coaches get anxious to make the process work and don’t apply the right amount of patience that is needed to help a solution fit for that company and even for a specific team to flourish. So, keep your days busy talking to people about their environment, their problems and even about possible solutions to their problems. Keep yourself busy holding relevant talks and even internal webinars. Let people know that you’re capable of helping them, and they’ll talk to you when the time is right for them. And then you get (for free) a great opportunity to focus your energy, instead of wasting it chasing people that don’t want to listen to you.
  3. When you act as mentor, don’t start with magic solutions – Many coaches start their mentoring process by offering specific frameworks or specific tools to people. Agile, project management, business management and product development are really huge and have an amazing variety of tools that can be used in specific situations, using different mindsets. So, as a coach, really use the tools and frameworks that you have mastered from the toolbox. Again, invest most of your time listening to people’s problems, and offer them the tool or framework that may better fit their specific need and watch them walk away smiling.
  4. When you argue about the “why”, you’ll fail  –  When we’re in a change process we can organise the challenges into two big questions – why change?  and how to change? The “why”, most of the time, is compounded by values, beliefs and assumptions etc. The “how” is more related to operational stuff.  Due to these aspects, in our experience, if you as an Agile Coach are trying to argue about why the Coachee must change, you’ll fail. When you argue about the “why” you are trying to prove to someone about “my point of view is better than your point of view, so just accept what I’m saying!”  It’s quite dangerous because most of the time, it sounds like “my why is better than yours” or in other words, “my values are better than yours”. For sure, this kind of approach causes resistance and difficulty in the change process. For this reason, as an Agile Coach, help the people with questions. Especially open questions to help them explore their mental model and to find their own why.
  5. Don’t forget the software  –  Although Agile transformations have a great focus on management processes and leadership/operations roles, it’s highly important that you, as a coach/mentor, don’t forget you’re aiming to optimise processes for software development. What’s more, delivery/quality processes’ automation play a greatly important role here. It doesn’t matter how wonderfully the teams are following the agile processes or how we’ve been able to teach great Product Owners or Scrum Masters, or even if we’ve been able to create a set of metrics that make total sense with the new value delivery mindset. If the teams (and their processes) are really fast in executing, but are getting stuck when they try to deliver or assess an increment quality, you’ll gain a beautiful bottleneck and effective management processes just won’t make it. So, be obsessed with teaching and even provoking people about delivery/quality automation showing them tools you’ve used and cases you know about, always keeping the subject  alive and bothering them.

I hope you have enjoyed these lessons. We will share more tips soon. See you :-)

Nenhum comentário »

Categorias deste post

Agile, Coaching, Extreme Programming, SAFe, Scrum

É necessário alterar a forma de contratação para trabalhar com Scrum?

O Scrum provoca um rebuliço organizacional tão grande que muitas vezes a cultura organizacional é posta em cheque. Em outras palavras muitas vezes se percebe que é necessário mover o elefante da cultura organizacional para outro lugar.

Obviamente isso toma tempo e para muitos a adoção orgânica, lenta e gradual do Scrum faz mais sentido. Em boa parte dos casos as tentativas de adoção abruptas e superficiais (ou os famosos, faça-se a luz e vou instalar e pronto) dificilmente se sustentam no longo prazo.

O motivo é simples, os novos valores são tão diferentes que não fazem sentido algum para os acostumados a forma corrente. E uma das consequências invariáveis dos novos valores é em relação a forma de contratação. Isso invariavelmente surge na mente dos novos praticantes no início.

Isso ocorre por que de acordo com os valores antigos é feita a contratação com um escopo de projeto fechado, e a partir do escopo é estimado um valor total do projeto e o tempo para a entrega. Dessa forma tem se a falsa ilusão de se fechar o escopo, valor e o tempo.

Essa ilusão perde sentido ao se fazer as seguintes reflexões:

->Com que frequência uma estimativa feita está correta?

->Com que frequência o seu cliente possui necessidade de mudar o escopo?

->Com que frequência o cliente consegue mudar o escopo sem entrar novamente em negociação?

->O cliente está contente com a entrega de TI?

A resposta para essas perguntas geralmente está relacionada a:

->As estimativas são superestimadas em 50% das vezes. Para evitar problemas adiciona-se gordura para as estimativas;

->O cliente não sabe o que quer e sempre deseja mudar o que foi combinado inicialmente;

->O cliente não consegue mudar o escopo sem antes ficar exaurido em uma negociação. Ou o cliente tem a opção de iniciar um novo projeto com um novo escopo, prazo de entrega e valor.

->Ouve-se nos corredores das corporações que o cliente de IT não está contente por causa dos atrasos na entrega, alterações no custo, e finalmente porque não ocorre a real materialização do sonho.

Esses problemas estão fortemente relacionados ao raciocínio de que contrato de IT é similar a contratos da engenharia civil. Em outras palavras, é utilizado modelo de contrato para uma reforma ou para a compra de um imóvel na planta em projetos de IT.

Felizmente em projetos de IT existe a necessidade de se utilizar mão de obra de profissionais criativos para concepção do produto final. Ao se utilizar esse tipo de mão de obra em sistemas complexos a margem de erro de estimativas é um fato.

“O cliente não sabe o que quer” é um fato, e é um fato a muito tempo.

Dessa forma deveríamos parar de fazer uma estimativa sobre um escopo cheio de incertezas e ajudá-lo a descobrir o que ele realmente precisa. Para isso precisaremos focar mais na solução de problemas do que propriamente na negociação de um escopo.

Todavia pode-se cair na armadilha de se mostrar a materialização da solução do problema apenas uma vez e assim jogar no lixo tempo e dinheiro. Não faria sentido seguir na direção errada por muito tempo.

Em outras palavras faz se necessário materializar e testar partes da ideia original com frequência e coletar feedbacks do cliente. E somente dessa formar descobrir junto com o cliente para qual direção seguir.

E o mais importante se o mercado mudar, é necessário fazer as adaptações necessárias para obter um produto que faça sentido para o novo mercado.

Dessa forma não é simplesmente alterar a forma de contratação de Fixed Price para Time Material. O foco do contrato deve ser solução de problemas dos clientes ao invés de uma solução especifica.

Afinal o foco agora está em colaborar com o sucesso do negócio do cliente mais do que ficar a apenas negociar e se proteger de contratos.

Se você estiver sentido essa dor, infelizmente não existe receita pronta, mas os links abaixo podem te ajudar:

http://www.agilecontracts.org/

http://www.adaptworks.com.br/TurmaDetalhes/epc-estimating-planning-contracting/1099/Produtos

http://www.infoq.com/articles/agile-contracts

http://www.stridenyc.com/blog/2014/10/3/im-agile-but-my-contract-isnt-how-to-align-contracts-with-agile-software-development-teams

http://www.twobirds.com/~/media/PDFs/Brochures/Contracting%20for%20Agile%20software%20development%20projects.pdf

 

Nenhum comentário »

Categorias deste post

Agile, Product Owner, Scrum

Elaboração de um Product Backlog Efetivo

Scrum é um framework para gerenciamento de produtos, baseado em desenvolvimento iterativo e incremental. O seu ciclo inicia com uma lista de funcionalidades desejadas para o produto, priorizada pelo cliente, então o time escolhe as funcionalidades que se compromete em desenvolver, geralmente  com iterações de 1 a 4 semanas.

Podemos notar que esse ciclo é bem definido, tendo como ponto de partida o Product Backlog, mas o Scrum não tem nenhuma definição de como construir um Backlog. Sempre nos deparamos com as perguntas:

  1. Como chegar ao Backlog?
  2. Como construir algo que tenha valor?
  3. Como encontrar a real necessidade do cliente?
  4. Como definir o que é prioridade para o cliente no primeiro momento?

Tentando responder essas perguntas, depois de diversas experiências em vários clientes, nasceu o “PBB – Product Backlog Building”. O PBB tem como principal objetivo ajudar na construção de um Backlog de uma forma compartilhada, construindo um entendimento compartilhado, levando todos os envolvidos ao entendimento colaborativo do domínio do negócio, ou seja, todos compreenderem o contexto do negócio.

Tem como objetivo vivenciar na prática a construção de um Backlog através do Product Backlog Building (PBB) um processo de construção do Product Backlog que utiliza o Backlog Canvas como ferramenta. Essa dinâmica leva todos envolvidos do negócio a uma experiência prática de elaboração e definição de um Product Backlog Efetivo totalmente consistente e alinhado com os valores de negócio do cliente.

Principais objetivos:

  1. Ajudar na construção de um BACKLOG de um forma efetiva e colaborativa.
  2. Construir um entendimento compartilhado do negócio do cliente, facilitando a descoberta e compreensão do produto.
  3. Buscar uma maneira de descrever a experiência do usuário com o produto.
  4. Facilitar a descoberta e escrita de User Stories.
  5. Priorizar por alinhamento de expectativas e metas.
  6. Ter como resultado um Product Backlog totalmente alinhado com o valor de negócio do cliente.

PBB é representado por um canvas (Backlog Canvas) que tem um fluxo bem simples e de fácil compreensão, principalmente para facilitar o entendimento do cliente, pois sua participação é de suma importância nesse processo de construção.

O fluxo de uma forma linear ajuda a organizar a visão geral do negócio e alinhar o valor de negócio, a compreenção e o que o projeto irá agregar ao final, junto com a ferramenta “Backlog Canvas” que ainda deixa todo o levantamento de requisitos organizado de forma visual.

Nenhum comentário »

Categorias deste post

Agile, Gestão de Produtos, Portfólio, Requisitos, Scrum

Por que questionar a técnica dos 5 porquês?

Eu acredito que você já tenha ouvido falar algumas vezes da técnica dos 3 porquês, ou 5 porquês. Trata-se de uma técnica para descoberta de causa-raiz dos problemas.

A técnica consiste de questionarmos “por que” algumas vezes (alguns dizem 3, como Ricardo Semler, já a Toyota fala de 5), a alguma questão: um problema, o modo de fazer alguma coisa, enfim; até chegar a uma última resposta que supostamente seria a causa-raiz da questão e todos seus problemas decorrentes.

A ideia é excelente porque é sistêmica! Normalmente ficamos refletindo ou resolvendo problemas no nível de “sintomas”, ao invés de realmente refletirmos sobre o que os geram na raiz (desculpem a repetição), para definitivamente resolver o problema e ele não mais se repetir.

O primeiro exemplo bobo:

1 – Por que estou espirrando? (sintoma)

“Porque estou gripado.”

  • Normalmente é aqui que costumamos tomar alguma ação: no caso, tomamos algum remédio pra gripe.

2 – Por que estou gripado?

“Porque dormi no frio.”

3 – Por que dormi no frio?

“Porque o vidro da janela estava quebrado e deixou o vento frio entrar no quarto.”

Assim, pra eu nunca mais voltar a ficar gripado por essa razão, além de tomar o remédio, tenho que reparar o vidro da janela.

O segundo exemplo mais dentro da realidade (mas fugindo do clássico exemplo em que partimos de “Por que temos tantos bugs?” e chegamos a realização de testes automatizados):

1 – Por que a performance do sistema está ruim?

“Porque não havia especificação pra tempo de resposta.”

2 – Por que não havia especificação de tempo de resposta?

“Porque o cliente não tinha parâmetros pra definir isso.”

3 – Por que?

“Porque não havia um sistema similar antes para servir de base comparativa ou parâmetro justificável.”

 Qual seria sua sugestão de ação nesse ponto?

Que tal ir adiante com mais 2 porquês?

4 – Por que?

“Porque a organização nunca teve verba pra investir numa solução desse porte antes.”

5 – Por que?

“Porque não tinha resultados suficientes nas suas operações que permitissem tal investimento.” 

E agora? Ficou mais complicado, não? Será que ações visando aumento de resultados nas operações resolveriam o problema original de performance?

Você não ficou com vontade de perguntar outra coisa no meio do raciocínio, como por exemplo “Por que alguém do próprio time não teve o bom senso de definir um tempo de resposta razoável pra todo sistema e conseguir aprovação do cliente?”

E mais: será que se essas perguntas fossem feitas a outras pessoas ou grupos, as respostas (e consequentes linhas de raciocínio e de ação), seriam as mesmas?

E se a pessoa ou grupo respondente não tivesse conhecimento suficiente pra responder às perguntas?

E se uma resposta no meio do caminho não fosse tão acertada? E se houvesse mais de uma resposta possível? E se houvesse mais de uma causa-raiz?

Trabalhando num projeto para a aeronáutica, aprendi que os acidentes aéreos nunca acontecem por uma só razão. É sempre por um conjunto de fatores alinhados numa combinação particular num determinado momento que causam um acidente.

Os militares trabalham justamente para identificá-los e tomar alguma atitude para que os fatores nunca mais se repitam naquela combinação, por exemplo: acrescentar uma checagem em algum procedimento de vôo, como você já deve ter visto alguma vez (“Flap direito”, “check!”, “flap esquerdo”, “check!”…), ou algum mecanismo automático que evite que aquele alinhamento de fatores se repita.

Pois é, quando começamos usar essa técnica para questões mais complexas, encaramos esses tipos de efeitos.

Não que a técnica seja falha, ela é excelente e já chegou a resultados excepcionais! Mas acredito que tenhamos que acrescentar fatores de complexidade a ela. Trago aqui algumas ideias para você avaliar seu processo de análise de causas-raiz então, a partir da mesma técnica:

 1 – A primeira mudança é tentar encontrar mais de uma resposta para cada porquê.

Você pode levantar diversas respostas, mas será muito difícil trabalhar com todas, então sugiro priorizar de alguma forma (votação?) até o máximo de 3.

Este número tem uma razão: esses fatores se multiplicarão com o processo. Respostas de menos podem não explorar suficientemente a questão. Respostas demais serão inviáveis de se trabalhar. E pelo princípio de Paretto, você deve priorizar as respostas (e ações) que farão a maior parte da diferença.

2 – Encare cada resposta como uma hipótese, não como uma resposta definitiva, e tente validar cada hipótese até conseguir uma confirmação.

3 – A partir das confirmações das hipóteses, aí sim continue o processo de perguntar porquês.

Você não vai conseguir ir muito longe nesse processo, pois como disse anteriormente, cada linha de raciocínio vai se multiplicar em várias respostas, e consequentemente várias ações.

Se você partir de 1 questão com 3 respostas validadas, e cada uma delas tiver mais 2 respostas validadas, já seriam 6 respostas. Se cada uma tiver mais 2 respostas validadas, passamos para 12 ações a serem tomadas para resolverem a causa-raiz.

Você consegue tempo e dinheiro para as 12 ações? Você conseguiria recursos pra validar todas as hipóteses?

Normalmente não. Então, priorize! Combine!

Tente pensar em ações ou soluções que enderecem várias das questões de uma só vez. Isso será possível.

Não se preocupe com o que ficar de fora, pois provavelmente será impactado pelas outras ações. Tudo curiosamente estará relacionado e obedecerá à regra 80/20.

O mais importante é você agir.
O próprio modelo dos 5 porquês já propunha uma maneira de você visualizar e gerir suas respostas, com o diagrama de Ishikawa.

 

Você pode usar a mesma ideia ou qualquer ferramenta de mapas mentais para não perder as contas de suas perguntas, hipóteses e respostas.

 

Infelizmente essas ideias trazem um pouco mais de complexidade e trabalho à brilhante e simples ideia original da técnica.

Mas o pior ainda está por vir!

Sim… Estamos falando de sistemas complexos adaptáveis (CAS) – lembra do Management 3.0? Talvez aquela sua solução matadora brilhante para o problema num primeiro momento, deixe de fazer efeito em algum tempo. As pessoas podem abandonar ou se desmotivarem com uma prática. O problema pode ressurgir de outra maneira.

É como lidar com um vírus (E vírus são CAS!). É difícil achar cura definitiva para vírus porque a cada novo remédio, o vírus muda, se adapta e torna a se espalhar.

Talvez você chegue em questões cujas pessoas envolvidas não queiram lidar. Normalmente ocorre em questões mais profundas, por exemplo: imagine que a causa de um problema sejam os salários dos colaboradores? Será que iriam à frente com isso?

Às vezes só crises têm força suficiente para que esse tipo de mudanças ocorra num projeto, organização ou na própria pessoa. Por isso crises são grandes oportunidades (às vezes desperdiçadas justamente por isso!). Mas isso é assunto pra outra conversa.

Talvez só de encontrar um problema, a situação toda já mude! (Tem um nome bonito pra isso, pra você explicar pro chefe – “a discussão gerou awareness!).

E provavelmente essa técnica toda fique defasada assim que publicada. (Ansiamos por isso!)

O importante mesmo é manter o “movimento”, exatamente como num ciclo PDCA.

 

Nenhum comentário »

Categorias deste post

Agile, Coaching, Management 3.0

The Backlog Grooming Flow

Para as pessoas interessadas em entender melhor a prática de Backlog Grooming, segue uma espécie de BigPicture (estilo Visual Thinking)  sintetizando o funcionamento do conceito Grooming. Essa Big Picture sintetiza a aplicação da técnica para fazer o refinamento de Product Backlogs em times Scrum.

O post com o texto original (em inglês) está publicado aqui. Nesse texto você poderá entender melhor o funcionamento e os benefícios  da prática de Backlog Grooming para tornar os Backlogs mais Detalhados, Estimados, Emergentes e Priorizados. Em outras palavras, basicamente a intenção do Backlog Grooming é tornar os backlogs mais organizados e palatáveis para todo o ciclo de geração de valor do Scrum.

 

The Backlog Grooming Flow

Nenhum comentário »

Categorias deste post

Agile, Scrum