Upload 9 files

docs/As três ondas da Agilidade _ Treinamento grátis de Scrum - Módulo 01 Aula 04.txt

@@ -0,0 +1,18 @@
+as três ondas da agilidade, que é um conceito super importante, não só para você entender um pouquinho sobre a história da agilidade, mas também, e muito mais elevante, para que vocês consigam entender quais são os tipos de práticas ágeis que existem e onde o Scrum se encaixa nesse modelo de práticas
+
+ Geralmente a gente que está estudando, ou que estuda agilidade, trabalha com agilidade. A gente divide a história do ágil em três grandes etapas. Com a primeira, que a gente chama de ágil para times, ou ágil padrão, começando em 2001 com o manifesto ágil, que inclusive é o tema da nossa aula da semana que vem. Então não percam, ficam ligados na nossa próxima aula, eu vou falar mais sobre o Manifesto Ágil.
+
+Mas, o que é importante vocês saberem sobre ele aqui? Em 2001, todos os grandes influenciadores que eram agilistas, que estavam trabalhando com esse conceito que estava começando de agilidade, eles se reuniram para poder justamente falar um pouco mais e tentar achar quais coisas todos aqueles métodos ágeis que eles estavam criando tinham em comum. Tinha o Mike Conn, tinha o Ken Schwaber, o Jeff Sutherland, que eram os criadores do Scrum. Tinha, cara, uma série de mentes fenomenais, os criadores do Extreme Programming. Então, tinha um time muito bacana, tinha os pais da juridade lá que se reuniram e eles escreveram um manifesto, é um documento, tem os valores e os princípios da agilidade, 4 valores, 12 princípios, e esse documento é considerado até hoje o marco fundador do que a gente chama de agilidade, por isso que ele é tão importante e é por isso que a gente considera que a agilidade começou formalmente, oficialmente em 2001. Nessa etapa da agilidade, o grande foco era fazer com que times de 5, 10 pessoas saíssem daquele modelo preditivo que a gente vem discutindo nas últimas aulas, de ter um planejamento para um projeto super bom, para passarem para esses times que são mais adaptativos, que conseguem trabalhar com entregas pequenas. É daí que vem, por exemplo, a visão de que os times ágeis têm de 7 a 11 pessoas, é um negócio que é super comum de ser falado. Hoje os times Scrum tem 10 pessoas, mais do Scrum Master, dono de produto. Então, essa visão de um time ágil trabalhando para entregar produto veio dessa primeira etapa em 2001. É aqui que a gente desenvolve uma série de práticas como gráficos de burn-down para acompanhar as entregas, é aqui que a gente começa a falar e formar ilhas de agilidade num oceano tradicional dentro das empresas.
+
+É aqui que tudo começou, é aqui que o Scrum se encaixa, essa é a base verdadeiramente da agilidade até hoje. Mas, todavia, contudo, conforme o tempo foi as pessoas começaram a perceber que coordenar só um time ágil, coordenar lá as 10 pessoas que estão formando um time ágil, não era o suficiente para todos os desafios que as empresas enfrentam. Tanto que em 2007 foi lançado um livro pelo Ken Schwaber, A Empresa e o Scrum, The Enterprise and Scrum, em inglês, foi o primeiro livro que falou Gente, beleza que vocês estão usando times ágeis, mas a gente às vezes precisa coordenar, precisa fazer vários times trabalharem juntos em escala, para a gente poder entregar coisas maiores, mais complexas, e que só um time de Scrum consegue entregar. Então, em 2007, com o lançamento desse livro, a gente considera que surgiu-se, ou que se grande onda da agilidade, que é o ágil escalado ou ágil em escala. Na prática, se a gente fosse entrar na semântica do negócio, ágil em escala e ágil em escalado tem até umas diferenças em semânticas, mas na prática ninguém vê essa diferença, entendam como sinônimos quando a gente falar de ágil em escala e ágil escalado.
+
+Nessa etapa, que começaram a surgir, por exemplo, o SAFE, que é o Scale and Agile Framework, o Nexus, da Scrum.org, o LESS, que são frameworks que falam assim, legal, você já sabe como fazer um time de 10 pessoas trabalhar bem usando Scrum, usando agilidade, como agora você faz para 10, 20, 30 desses times, 300 pessoas, trabalhando juntas para você poder também entregar valor. Tem uma frase legal, inclusive, que fala assim eu sei como fazer três cavalos puxarem uma carroça, eu não sei como fazer 500 galinhas puxarem a mesma carroça. Porque a coordenação é difícil, né? O que essa frase quer dizer?
+
+Se você tem menos pessoas, menos canais de comunicação, menos interações, a sua complexidade é menor. Na hora que você tem 300 pessoas que tem que trabalhar juntas para atingir um objetivo, você não consegue fazer isso com as mesmas práticas, com as mesmas ferramentas de quando você tinha 10 pessoas. Você vai precisar de mais coordenação, você precisa de mais processos, mais práticas, mais ferramentas que te ajudem a coordenar tudo isso. E é por isso que surgiram essas ferramentas, esses frameworks para Agile em escala, que é a segunda onda da agilidade. E aí, desde 2009, a gente começou a perceber que, cara, legal, eu tenho times aqui que estão desenvolvendo produtos, eles fazem entregas pequenas, planejamentos pequenos, eles se adequam muito bem, eles fazem isso em escala, isso está me ajudando muito a entregar produtos. Mas tem uma série de coisas aqui ao redor disso, na minha empresa, como o time de marketing, time de compras, time de vendas, o RH, enfim, toda a estrutura da empresa que ainda não é ágil.
+
+Como eu pego esses princípios? Como que a gente pode pegar esses conceitos de gerar mais valor, ser mais adaptável, reduzir o risco, melhorar a visibilidade e aplicar não só para os times de projeto, times de produto, mas sim aplicar isso de fato para a empresa como um todo, para a empresa toda ser ágil. E aí foi nesse momento, em 2009, que as empresas começaram a se questionar isso, que surgiu o que a gente chama hoje de Business Agility. O que é Business Agility? Ou, como eu gosto de traduzir para o português, a agilidade organizacional. É justamente essa visão, esses frameworks, que tentam nos ajudar a trazer todos os benefícios da agilidade para todas as esferas da empresa. Tem muitos lugares, tem muitas pessoas que estão tentando fazer isso funcionar. Kamban tem uma vertente nisso, o SAFE, que é o esquema de agile framework desde a sua versão 5, também quer ser uma opção de business agility. A gente tem o Business Agility Institute, que nasceu lá na Austrália, mas é que hoje é mundial e está presente no Brasil, nos Estados Unidos, na Europa, que tem uma série de frameworks legais.
+
+Enfim, desde 2009, muitas coisas estão rolando, muita coisa está acontecendo para a gente conseguir utilizar a Agilidade na empresa toda. Por que eu falei que isso explica não só a história do Agile, mas essas três ondas também explicam onde os métodos estão. Se a gente olha para a Agilidade em times, já é um negócio super maduro, a gente consegue fazer isso bem com Scrum, com Kanban, até com a versão mais simples do Safe. É perigoso o que eu vou falar aqui, mas não tem muito mais o que ser evoluído quando a gente pensa na gestão de Teams. Óbvio, sempre tem, não quero ser simplista, amanhã com certeza vão surgir coisas novas que vão melhorar a eficiência e eficácia da gestão de Times.
+
+Mas quando a gente olha para este modelo, para essa onda da agilidade, ela é muito mais madura do que quando a gente fala da segunda onda, por exemplo, que é o ágil em escala. Apesar, eu mesmo, como eu comentei nas primeiras aulas, eu já gerenciei, liderei times ágeis com mais de 100 pessoas, 150 pessoas. Mas, ainda tem desafios, tem coisas que a gente está aprendendo a fazer para melhorar mais a eficácia e eficiência do uso do ágil em escala. Quando a gente vai para a terceira onda, que é a agilidade organizacional, o Business Agility, ela é bem mais incipiente, ou seja, ela é bem mais verde, bem mais crua do que as duas anteriores. Então as coisas estão evoluindo, tem práticas para cada uma delas, mas ainda tem bastante terreno a ser explorado, principalmente na agilidade organizacional. 
+

docs/Como usar Scrum no Home Office_ Aprenda a trabalhar com seu time Ágil distribuído.txt

@@ -0,0 +1,22 @@
+ O Scrum pode ser adaptado de maneira distribuída, ou seja, sem que todos os membros do Scrum Team estejam fisicamente presentes no mesmo local. Para a gente poder fazer isso, inclusive, existem várias configurações possíveis de times. Cada uma delas tem as suas próprias vantagens e desvantagens. Você como Scrum Master precisa estar preparado para suportar cada uma dessas configurações e atuar para poder trazer práticas complementares e fazer com que o seu time seja o mais produtivo possível, estando ele fisicamente colocado ou fisicamente distribuído. As configurações do time Scrum podem variar desde todos estarem na mesma localidade simultaneamente até o outro extremo, onde nós não temos ninguém fisicamente no mesmo local.
+
+Mas independentemente dessa configuração, os principais desafios estão sempre na comunicação e no trabalho em equipe. No slide que está aparecendo na tela agora, eu tenho três exemplos de situações intermediárias. Na primeira, o dono do produto, o time de desenvolvimento e o Sphere Master estão em uma localidade, uma localidade que a gente está chamando aqui de offshore, enquanto os demais stakeholders estão em outra localidade. Nesse cenário, o principal desafio de comunicação é entre o dono do produto e os stakeholders, porque geralmente é ele que faz essa ponte. Outra dificuldade que nós podemos ter é do time de desenvolvimento com o restante da organização, se tiver outros times que suportam o trabalho desse nosso time trabalhando de maneira remota. Esses outros times podem inclusive ser o time de RH, o time de finanças, o time que faz reembolso para o time de desenvolvimento, caso eles precisem de alguma coisa.
+
+Nesse cenário, o desafio é a comunicação e fazer com que o time de desenvolvimento se sinta integrado ao restante da empresa. Você como Scoremaster atua nesse sentido para fazer com que o time ainda se sinta parte da empresa, se sinta membro de algo maior do que eles mesmos. O segundo cenário que eu quero trazer aqui é o cenário em que os stakeholders e o dono do produto estão em uma localidade e o time de desenvolvimento e o Scrum Master estão em outra. Esse é um cenário que é relativamente comum, principalmente se o Scrum Master e o time de desenvolvimento forem pessoas de uma prestadora de serviços e o dono do produto for da empresa que está contratando.
+
+O desafio de comunicação aqui é entre o dono do produto e o time de desenvolvimento e entre o Scrum Master e o restante da organização. Notem que boa parte dos desafios do time de desenvolvimento no primeiro cenário também se aplicam a esse segundo e vão se aplicar ao terceiro cenário, onde nós temos o Scrum Master, dono do produto e stakeholders em uma localidade e o time de desenvolvimento em outra. Esse é um cenário bastante difícil de acontecer, mas não impossível, onde nós temos o time de desenvolvimento trabalhando de certa forma isolado dos demais. O desafio de comunicação aqui é do time de desenvolvimento com todo o restante da organização e do produto onde eles estão inseridos. Para poder facilitar esse dia a dia e lidar com esses desafios, as técnicas que você como Scrum Master tem que conhecer partem muito primeiro da comunicação diária. Então, independentemente de onde está o Dev Team, todos participam do Scrum diário.
+
+E para essa comunicação ser o mais efetiva possível, idealmente, a comunicação face a face deve ser utilizada. Então, se você estiver na mesma localidade, todo mundo na mesma sala. Se o seu time estiver fisicamente distribuído, você deveria utilizar a webcams, deveria utilizar videoconferência para que as pessoas do time possam interagir melhor. Outra forma de deixar a comunicação mais efetiva é ter sempre a agenda clara, ou seja, os assuntos que vão ser tratados em cada reunião, para que você não desperdice tempo e para que as pessoas possam focar na produção de valor, ao invés de focar nas reuniões. Além disso, existem ferramentas que podem apoiar a colaboração em equipe, mesmo em times que não estejam fisicamente no mesmo local.
+
+Ferramentas como o Microsoft Teams, o Slack, Gira ou o Azure DevOps podem ser utilizadas para que o time troque informações rapidamente, de uma maneira segura, confiável e mantendo o histórico das informações, assim sempre que eles precisarem, eles podem voltar, olhar as wikis, os documentos, tudo que foi trocado, mantendo uma memória viva de todas as conversas que foram feitas. Você como Scoremaster pode organizar atividades de team building, mesmo que virtuais, para que o time de desenvolvimento. Por fim, sempre que for possível, e aí aqui nós temos barreiras que podem ser geográficas, econômicas, de linguagem ou até mesmo de custo, mas sempre que for possível, o time deve tentar se reunir fisicamente. Isso ajuda a acelerar essa formação do time, a troca de informações e até a gerar sinergia. É claro que a gente tem situações em que isso não é possível, por exemplo, a pandemia causada pelo Covid está impedindo todo mundo de viajar, mas é uma ferramenta poderosa que aumenta a efetividade. A gente pode usar ela sim com certa cautela, olhando para todos esses elementos que eu falei, mas é algo que é válido de ser utilizado. Pensando no ambiente de trabalho, as pessoas têm que ter um espaço adequado para poder trabalhar.
+
+Então cadeiras e mesas que sejam adequadas para as necessidades das pessoas são super importantes, seja isso em casa, seja isso no escritório ou na própria casa das pessoas quando eles estão trabalhando remotamente. Para tornar as reuniões mais efetivas, os membros da equipe deveriam ter headsets com controle de volume apropriado, que sejam ergonômicos, que não cansem o ouvido, para que eles possam passar mais tempo conversando, mesmo em ambientes em que todo mundo está trabalhando de casa. Além disso, quadros, flipcharts, post-its, marcadores, precisam estar sempre disponíveis, seja na área do projeto, sejam em murais virtuais que os times podem utilizar para rapidamente rabiscar e trocar informações. Além disso, é bom que as pessoas consigam ter um espaço para trabalhar de maneira mais isolada.
+
+Então se elas estiverem no escritório, que seja um ambiente sem muito barulho, sem muita interrupção, para que os membros do time de desenvolvimento possam focar. É claro que a comunicação é importante, é claro que eles têm que conversar, mas muito barulho, muita algazarra, pode acabar atrapalhando a performance do time. Você como Scrum Master pode monitorar isso e ensinar o seu time como trabalhar de maneira sem atrapalhar as outras pessoas por conta do ruído ou de interrupções frequentes. Se as pessoas estiverem trabalhando na casa delas e o espaço permitir, é legal que elas também tenham um local, um espaço em que elas possam trabalhar sem ter muita televisão ligada perto, sem ter muitas pessoas conversando ou dando risada. É claro que em casa o desafio é maior, nem todo mundo tem espaço num apartamento ou numa casa para poder trabalhar desse jeito, mas se você tiver é melhor trabalhar dessa forma.
+
+Ainda falando de espaço, se estiverem todos no mesmo ambiente, é legal que as pessoas tenham uma sala de reunião dedicada para daily scrum, para reuniões frequentes, para que eles possam saber para onde ir quando eles tiverem uma necessidade. É claro que muitas reuniões são ruins e que geralmente elas acabam gerando desperdício de tempo. Mas, como a gente faz várias reuniões, é importante ter um espaço adequado para isso também. Inclusive, as salas de reunião nas empresas devem ser equipadas com dispositivos para videoconferência, televisão, mesa redonda, cadeiras apropriadas e alto-falantes para as comunicações remotas, que são cada vez mais comuns na nossa realidade de trabalho. Para suportar tudo isso, é necessária uma infraestrutura adequada, principalmente para fazer videoconferências, teleconferências, que são cada vez mais comuns, principalmente agora que existe uma tendência dos times estarem cada vez mais distribuídos.
+
+Então, tanto a empresa quanto as pessoas precisam se preocupar com a largura de banda necessária, não só para essas teleconferências, mas também para acessar todas as ferramentas como o Gira, Confluence, o Azure DevOps, que o time precisa para trabalhar remotamente e fazer as suas tarefas de maneira efetiva. Inclusive, falando de ferramentas mais um pouco, é importante existir um conjunto comum delas para que o time possa saber aonde que eles vão trabalhar, onde que eles vão trabalhar a gestão de tarefas, aonde eles vão trabalhar a gestão da informação, aonde eles vão trabalhar o controle de tudo aquilo que eles estão fazendo e daquilo que eles estão entregando. A preferência aqui é para ter uma quantidade menor de ferramentas que façam mais coisas do que ter muitas ferramentas que façam coisas picadas.
+
+Isso acaba tornando o ambiente mais complexo, fazendo com que as pessoas tenham que aprender a utilizar mais ferramentas e acaba gerando um custo adicional com infraestrutura, licenciamento e até com manutenção e servidores de todas essas ferramentas diferentes. Isso, Trovão, late mais! Nesse módulo nós aprendemos que os times que trabalham de maneira distribuída podem ser tão ou até mais produtivos que times que estão trabalhando fisicamente colocados. Além disso, nós vimos que existem vários cuidados que são necessários para garantir a produtividade do time, tanto quando eles estão no escritório, quanto quando eles estão em casa ou fisicamente separados, fisicamente distribuídos. 
+

docs/Diferenças das empresas Ágeis e Tradicionais _ Treinamento grátis de Scrum - Módulo 01 Aula 06.txt

@@ -0,0 +1,18 @@
+Vamos falar um pouco sobre as diferenças entre as empresas que são tradicionais e não usam agilidade e as empresas que já começaram a adotar essa prática no seu dia a dia.
+
+E eu quero começar mostrando para vocês esse desenho, que é o mais tradicional, o mais conhecido, quando a gente vai descrever uma empresa. E não é à toa que a empresa tradicional é descrita por um desenho tradicional. Ele é super famoso e ele vem sendo utilizado nas últimas décadas para poder demonstrar a forma como empresas funcionavam. Hoje elas já não deveriam mais funcionar assim, as empresas deveriam ser agiles. Mas indo direto ao assunto aqui, vocês vão notar que esse desenho tem a forma de uma pirâmide. Por quê? A empresa tradicional, ela funciona de modo altamente hierárquico. Outra forma de descrever isso é falar que ela funciona numa estrutura de comando e controle. Então nós temos menos pessoas comandando, que são as pessoas que estão no topo da empresa e muitas pessoas obedecendo, são as pessoas que estão aqui embaixo na hierarquia, na base da pirâmide.
+
+Qual é o problema ou quais são as fragilidades desse modelo de empresa tradicional? Bom, primeiro, ele assume que as pessoas que estão acima na hierarquia possuem todas as respostas ou possuem um conhecimento maior do que as pessoas que estão na base da pirâmide. Isso era verdade quando a gente falava de manufatura, quando nós falávamos de uma força de trabalho baixamente especializada. As pessoas que estavam acima na hierarquia, as pessoas que tinham cargos mais altos, elas estudavam a administração de empresas, elas estudavam técnicas para melhorar a performance da fábrica e, de fato, elas sim, continham muitas respostas. Isso fazia, inclusive, com que fosse necessário essa existência de muitas camadas, porque você precisava, olhando de baixo pra cima aqui, você precisava das pessoas da base da pirâmide para executar o trabalho, quando esse time ficava grande você precisava de um coordenador, quando você tinha muitos coordenadores você precisava de gerentes para poder gerenciar o que essas pessoas faziam, e aí quanto maior fosse a empresa, mais camadas de gestão ela precisava.
+
+Gerentes sêniors, diretores, superintendentes, vice-presidentes e o presidente. Isso acaba fazendo com que a empresa tradicional ela seja mais burocrática, ela seja lenta na tomada de decisão, porque a comunicação ela não flui muito bem, nem na vertical, ou seja, nem entre as pessoas que estão aqui na hierarquia, você tem uma demora para que a informação da base chegue no topo e para que a informação do topo chegue na base e ela também gera silos ela também gera o problema de comunicação entre diferentes departamentos e entre diferentes estruturas isso porque a empresa tradicional ela é organizada em departamentos por especialidade você vai ter lá um departamento de marketing um departamento de vendas, de compra, de finanças, de execução, RH, enfim, dependendo do tipo da empresa, você tem mais ou menos departamentos e departamentos podem ser maiores ou menores.
+
+Outra grande característica dessa estrutura que é comando e controle é que as instruções elas são muito detalhadas, ela não aproveita os conhecimentos das pessoas, não dá liberdade para que eles sejam criativos e resolvam problemas, muito pelo contrário. A estrutura hierárquica exige que as instruções, exige que a direção da empresa venha de cima para baixo, um top-down. E isso, novamente, faz com que a empresa não consiga aproveitar os seus talentos em sua totalidade e também diminui a velocidade, porque demora para que essa mensagem seja propagada. Agora, quando a gente pensa nas organizações ágeis ou nas empresas que estão adotando agilidade, vocês vão ver que o desenho é completamente diferente. A gente está falando não de uma pirâmide, mas desse círculo que você está vendo aqui na sua tela nesse momento. O que esse círculo quer dizer? Bom, primeiro, a gente não precisa mais de uma estrutura de comando e controle, porque a força de trabalho moderna, principalmente das empresas que são ágeis, ela é muito mais especializada.
+
+Tem inclusive um termo que eu gosto muito, que foi cunhado pelo Peter Drucker em 1954, que chama esse tipo de profissional de profissional do conhecimento. São aquelas pessoas que fazem curso profissionalizante, especializações, graduação, a famosa faculdade, pós-graduação, mestrado, doutorado, são pessoas que são criativas, têm muito conhecimento e elas sabem como resolver problemas. Esse profissional do conhecimento, na empresa Agile, ele é totalmente valorizado e empoderado para que ele possa, primeiro, fazer mudanças rápidas através de recursos flexíveis. Tem tudo a ver com o que a gente está falando aqui sobre agilidade desde o começo do treinamento. Por quê? Se no ágil a gente faz pequenas entregas em períodos curtos de tempo, mas são entregas completas, eu preciso de um time que me permita trabalhar desse jeito.
+
+E aí que vem essa estrutura circular que você está vendo aqui, em que os times são multidisciplinares, eles são multiculturales, eles são auto-organizados. Primeiro, multidisciplinar significa que a gente tem dentro de um time tudo que a gente precisa para gerar o sucesso ou para poder fazer com que a entrega do nosso produto, do nosso resultado aconteça. Então, ao invés de eu ter lá um departamento de marketing, um departamento de vendas, um departamento de design, um departamento de desenvolvimento, eu vou ter um time que junta todas essas especialidades e todo mundo vai trabalhar junto no seu dia a dia para poder fazer com que essa entrega vire realidade. Notem que só de fazer isso, eu já estou acelerando a comunicação, porque eu não preciso mais falar com o chefe do departamento ou eu não preciso mais ir no outro departamento para pedir alguma coisa ou planejar alguma coisa.
+
+A gente está aqui com todo mundo trabalhando juntos nas suas especialidades, mas trazendo essa visão holística, essa visão completa para tudo que a gente está tentando entregar. É por isso que a gente fala que no modelo ágil as caixas importam menos, não importa o seu departamento, não importa a sua especialidade, o que importa é o resultado que você vai gerar. E aí justamente por isso a liderança não precisa ser comando e controle, porque as respostas estão no time. Você não precisa de alguém de fora do time, uma liderança de fora do time, falando como as pessoas têm que atingir os resultados ou como as pessoas têm que trabalhar. Não! O papel da liderança é mostrar a direção, é falar olha o grande objetivo da nossa empresa é aumentar vendas ou o grande objetivo da nossa empresa é conquistar mais clientes, é aumentar a margem de lucro para cada cliente que a gente tem. Enfim, a liderança ela vai definir os objetivos estratégicos, mas o como isso vai ser feito é definido dentro desse time que é multidisciplinar e por isso o time é auto-organizado, auto-gerenciado.
+
+Significa que eles mesmos definem o ritmo da entrega, como eles querem trabalhar e como eles vão atingir os resultados. E essa diferença do modelo tradicional para o modelo ágil é brutal. É por isso que as empresas ágeis têm uma performance tão superior que a das empresas tradicionais, porque eles estão aproveitando ao máximo a capacitação das suas pessoas, a forma com que as pessoas resolvem problemas, eles estão reduzindo a comunicação e o desperdício, eles estão, de fato, trabalhando de uma maneira muito mais produtiva e muito mais coesa do que é possível numa empresa hierárquica, comando e controle e burocrática tradicional. 
+

docs/Fake Agile (e outras disfunções ágeis).txt

@@ -0,0 +1,24 @@
+Você sabia que existem coisas que parecem ágeis e que na verdade não são? E que existem outras coisas que não parecem ágeis e que na realidade são muito ágeis? Quer saber o que é fake agile e como isso pode atrapalhar você e o seu time a entregarem mais valor para o seu negócio? 
+
+Existem dois tipos de fake agile por aí. O primeiro deles é o que acontece de maneira não intencional, quando alguém utiliza uma prática ágil errada, mas por desconhecimento e por não saber como fazer isso direito. O segundo tipo de fake agile que é mais grave, acontece quando alguém usa práticas ágeis de maneira distorcida ou erradas e de propósito para poder atingir um objetivo pessoal ou para poder atrapalhar uma transformação ágil. O primeiro tipo que acontece sem querer dá até para a gente entender. Por quê? Nas últimas décadas o ágil vem ganhando cada vez mais adeptos e muitas coisas novas vem surgindo todos os dias, muitas novidades, muitas práticas vem sendo adotadas num ritmo acelerado, tanto por times quanto por organizações. Nesse ritmo acelerado que a gente está, é comum que as pessoas às vezes não tenham tempo suficiente de entender todos os conceitos que levaram à construção ou ao surgimento de um método, de um framework Agile, e muitas vezes eles começam a utilizar sem entender muito bem os principais objetivos daquilo que eles estão usando.
+
+E como tem muita gente falando de Agile, muita coisa sobre Agile sendo publicada, sendo estudada, às vezes é comum um conceito errado acabar sendo replicado em diferentes times, em diferentes localidades. Um dos exemplos mais clássicos de fake agile está relacionado a Daily Scrum, que muita gente chama de Stand-up Meeting ou reunião diária. Essa prática é muito utilizada, muitos times que dizem ser ágeis falam que fazem essa reunião diária, mas eles não entendem de onde ela surgiu ou porque ela tem que ter um formato específico. O Daily Scrum faz parte do Scrum Framework e no guia do Scrum existem todas as instruções sobre como esse evento deve ser utilizado. Ela é uma reunião com no máximo 15 minutos de duração, da qual deveriam participar somente os membros do Daily Team e cujo principal objetivo é definir um plano para as próximas 24 horas da sprint. Muita gente acaba distorcendo esse conceito e trazendo outras pessoas para participarem dessa reunião, que acaba virando muito mais uma reunião de status e porte do que uma reunião de planejamento. Dela não deveriam participar, por exemplo, gerentes de projeto, não deveriam participar o PO, pelo menos não de maneira ativa, interagindo com o time, nem nenhum outro stakeholder que faça parte da organização.
+
+Essa participação de papéis, de pessoas que não deveriam estar no Daily Scrum, faz com que essa reunião passe dos 15 minutos, levando muitas vezes 30, 60 minutos de duração, fazendo com que o time fique cansado e que ele entregue menos valor. Tem muitos times, inclusive, que começam a aplicar o ágio com as reuniões diárias. Por quê? É uma prática simples, ela consegue existir sozinha, stand alone, dentro da organização ou dentro de times. E aí muita gente fala, ah, estou fazendo reuniões diárias, portanto, eu estou fazendo ou eu estou praticando um método Agile aqui na minha empresa. E nem sempre isso é verdade.
+
+Então, se a gente usa uma reunião, se a gente usa um evento da maneira errada, esse evento passa a ser um fake agile. Outro exemplo de fake agile que acontece porque as pessoas não conhecem muito bem os princípios ou não conhecem muito bem os fundamentos de como as coisas funcionam, está muito relacionado à adoção do SAFE. O SAFE, que é o acrônimo para Scale Agile Framework, é um conjunto de práticas bastante prescritivo que tem uma documentação bastante extensa. Geralmente as pessoas não leem toda a documentação do SAFE, não tem tanta experiência na adoção do SAFE e elas começam a adotar pedaços do SAFE sem entender muito bem como esses pedaços interagem juntos.
+
+Então é comum a gente ver organizações adotando system teams, adotando release train, mas sem todos os papéis e sem tudo que existe no arcabouço que a gente chama de safe. Se a gente não usa tudo do Scrum ou tudo do Kanban ou tudo do safe, a gente às vezes não consegue atingir a agilidade, a gente não consegue ser ágil de verdade, porque faltam peças super importantes nesse motor que levaria a gente a ter uma organização mais ágil. Outra situação que pode criar o fake agile e prejudicar a ação do agile é justamente uma transformação de uma organização tradicional para uma organização agile sem o devido planejamento e sem o acompanhamento de alguém que seja experiente. Esse alguém experiente pode ser o nosso famoso agile coach. Então, às vezes a gente muda o nome dos papéis da organização, a gente transforma o gerente de projeto em agile coach ou em scrum master, a gente transforma um especialista em produto, ou um analista funcional em product owner, mas a gente não treina essas pessoas, a gente não capacita elas para atuarem de acordo com o que é exigido desse novo papel.
+
+Então elas passam a ter um novo nome, elas não sabem na prática o que muda com a adoção desse novo nome, e elas passam a executar as mesmas tarefas, da mesma forma como elas sempre foram executadas, e não existe uma mudança verdadeira. Os nomes mudam, mas a organização continua sendo uma organização que utiliza métodos tradicionais para poder fazer gestão de projetos, gestão de produtos e assim sucessivamente. Inclusive, é essa transformação que não é bem executada, não é bem planejada, que acaba criando o fake agile do tipo 2, o fake agile que é intencional. Esse fake agile intencional, muitas vezes, parte de pessoas que não entendem essa mudança de mindset ágil, não entendem toda essa transformação cultural, que tenta tornar a organização menos hierárquica, que tenta tirar essa estrutura de comando e controle tradicional para que todo mundo na organização consiga atuar melhor dentro das suas especialidades. E aí o que acontece é que algumas pessoas se apegam a esse papel que elas tinham antes, ao falso senso de poder que esse papel trazia, e elas fazem de tudo para manter o status quo, para manter a situação atual. E um exemplo de papel onde isso pode acabar acontecendo é no papel do gerente de projetos. O gerente de projetos tradicional, conforme descrito pelo PMI, é uma figura que tem bastante centralização de poder. Por quê? Ele é responsável pelo planejamento, pela gestão de escopo, por fazer o monitoramento e controle do time como um todo. Então ele é visto como alguém que tem a palavra final em muitos assuntos. Quando a gente faz uma transição para o Scrum, por exemplo, a gente divide esse papel e essas responsabilidades do gerente de projetos em todos os papéis do Scrum Team.
+
+Então a gente tem o time de desenvolvimento sendo responsável pelo planejamento, a gente tem o Product Owner sendo responsável pelo escopo e pela gestão do escopo, a gente tem o Scrum Master sendo responsável pelos processos e a gente não tem uma única figura que possa ser imediatamente traduzida como no tradicional a gente tem o gerente de projetos, no scrum a gente tem o... não tem, não tem esse papel que seria o gerente de projetos no Azure. E aí muitos gerentes de projeto temendo perder poder ou temendo perder influência, eles fazem de tudo para manter a situação atual.
+
+0:08:46
+Então eles não ensinam e não dão coach para o time se tornar mais autogerenciável. Eles não apoiam o time a aprender a se planejar e fazer estimativa sem o apoio de uma figura externa como gerente de projetos. Eles não estão trabalhando para que a organização seja mais ágil. Existem casos em que os gerentes de projetos não querem fazer a transição e eles começam a sabotar esse processo de transformação conscientemente.
+
+0:09:13
+É claro que isso não é uma regra geral, eu não tô aqui falando que todos os gerentes de projetos têm essa postura, eu conheço muitos gerentes de projetos que inclusive fizeram uma transição muito boa para papéis ágeis, estão atuando muito bem em organizações ágeis, mas existem sim casos em que o gerente de projeto não faz uma transição muito boa. Isso também vale para membros do time de desenvolvimento, tem algumas pessoas que não querem ser responsáveis por aquilo que elas estão fazendo. Tem algumas pessoas que estão acostumadas a pertencer a uma estrutura de comando e controle em que as coisas vêm de cima para baixo e elas só têm que executar. E isso muda muito no Área. Na Área a gente espera que as pessoas tenham esse senso de dono, esse sentimento de donas daquilo que elas estão fazendo e que elas sejam responsáveis por definir os prazos, a melhor forma com que elas vão trabalhar, que elas ajudem outros membros do time a desenvolver essas características.
+
+E aí quando alguém não quer fazer essa transição, eles podem também começar esse fake agile, então eles falam que estão num time ágil, eles assumem nomes de coisas ágeis que eles deveriam estar fazendo, mas eles mantêm essa cultura tradicional e acabam não mudando nada no dia a dia delas. E é claro que a gente tem muitos outros exemplos de fake agile, de práticas que a gente executa de maneira errada, que até parecem ágeis porque tem um nome ágil e que não são. O que eu vou pedir pra vocês é deixem aqui nos comentários a experiência de vocês com fake agile, quais as situações que vocês já enfrentaram.
+

docs/Medindo a Complexidade _ Treinamento grátis de Scrum - Módulo 01 Aula 03.txt

@@ -0,0 +1,25 @@
+Na aula de hoje nós vamos falar sobre como classificar a complexidade ou melhor ainda como entender qual é o tipo de complexidade que existe no seu negócio, para você escolher o melhor método ágil ou a melhor prática para você poder entregar resultados. Eu vou começar falando aqui mostrando um gráfico que está aqui na tela pra vocês que resume o Cinefyn Framework. O Cinefyn Framework, ele divide ou classifica a complexidade em quatro níveis, o nível simples, o complicado, o complexo e o caótico. Eu vou te explicar aqui cada um deles. Basicamente nesse gráfico, vocês tem aqui no eixo Y, no vertical, a quantidade de certeza ou incerteza que a gente tem sobre o que precisa ser feito, que a gente chama de requisitos, e aqui embaixo no eixo X, o eixo Y. Basicamente, se você sabe o que precisa ser feito e como precisa ser feito, você está dentro de um contexto simples. E é aqui que os métodos preditivos tradicionais brilham, tem muita utilidade e estão até hoje muito utilizados em empresas. Aqui por exemplo, nós temos atendentes de call center que vão fazer um desbloqueio de cartão. Vou dar esse exemplo aqui pra vocês.
+
+Por que? Todo desbloqueio de cartão é geralmente igual. Então o atendente lá do call center ele sabe o que fazer e ele vai seguir um roteirinho para como fazer. É um contexto simples. Não entendam simples aqui como fácil, tá pessoal? pessoal, o trabalho no call center ele é sim difícil, ele tem as suas nuances, ele tem as suas características que faz com que por exemplo atender clientes seja um negócio extremamente difícil, mas do ponto de vista de execução, do ponto de vista de processo é simples você fazer um desbloqueio de cartão. No próximo nível aqui do Cinefyn Framework, nós temos menos certeza do que precisa ser feito e menos certeza de como isso vai ser feito. Nós estamos em um ambiente complicado. Geralmente aqui a gente ainda está falando de domínios que têm algum escopo fechado, como por exemplo o direito ou os advogados.
+
+Por quê? A lei é fechada. Quando você está num processo, quando você está num julgamento, não vai ser criada lá durante a primeira, a segunda instância, uma lei nova, uma definição nova para aquilo que está sendo feito. Você vai apresentar os fatos, o que é complicado, existe incerteza de qual vai ser o resultado, você vai utilizar leis, você vai utilizar jurisprudências para poder tentar convencer o juiz, o júri, dependendo do caso, de qual deveria ser o resultado desejado, mas a gente não tem certeza de qual vai ser esse resultado, mesmo porque existe um conflito lá entre a defesa e a acusação nesses casos e os dois têm certo domínio da tecnologia que é bastante complicada, os dois vão utilizar táticas para poder tentar chegar no resultado.
+
+Neste domínio, mais é conhecido, porque nós conhecemos as leis, conhecemos o adversário, conhecemos o caso do que é desconhecido. Mesmo assim, ele é muito mais complicado, muito mais difícil do que um domínio simples. Ainda no Cinefin Framework, nós vamos para o terceiro nível de classificação da complexidade, que é o complexo, onde mais é desconhecido do que é conhecido. Aqui, neste exemplo, ou neste nível de complexidade, nós geralmente estamos falando do desenvolvimento de produtos ou do desenvolvimento de projetos. Por quê? Nós temos o escopo, nós temos uma visão do que nós precisamos fazer, só que geralmente nós não sabemos exatamente como vai ser feito. Utilizando um projeto de software aqui como exemplo, isso nos mostra que depende, por exemplo, das tecnologias do local onde o projeto vai ser feito, depende da arquitetura, depende das pessoas, depende da senioridade do time, depende de pressões do mercado, de decisões de desenho, do protótipo, do dono do produto.
+
+Então é um escopo muito mais amplo, muito mais aberto do que o que existe no cenário simples e complicado. Além disso, além da gente não saber muito bem como vamos fazer as coisas, porque isso é progressivamente elaborado, ou seja, ao longo do tempo que nós vamos descobrindo como nós vamos fazer as coisas, as coisas duram um tempo muito grande, meses, às vezes anos, e os requisitos podem ir mudando, o que precisa ser feito pode ir mudando. É nesse elemento, ou nessa visão de complexidade do Cinefyn Framework, da visão dos complexos, que o Scrum e os demais métodos Agile tem muito sucesso. Por quê? Justamente por adotarem essa prática adaptativa, justamente por permitirem, como nós vimos aqui nas aulas passadas, que nós façamos pequenas entregas, pequenos experimentos, que vamos construindo as coisas ao longo do tempo, que nós conseguimos ter resultados melhores no complicado.
+
+A gente não assume que a gente tem todas as respostas, porque de fato não as temos, e a gente consegue, com essas pequenas entregas, ir fazendo a construção, a gente consegue ir fazendo as grandes entregas que são necessárias pela soma desses pequenos pedaços. E aí você deve estar se perguntando,  mas você falou de quatro níveis, ainda tem o quarto nível que é o caótico, não tem? Tem! A regra do caótico é a seguinte, você não sabe quase nada, você não está entendendo quase nada, você tem que sair dele o mais rápido possível. Aqui nada vai te ajudar, por quê? É impossível a gente lidar com algo tão disruptivo, tão incerto, tão volátil, quanto algo que é caótico. E aqui o que existem são táticas para você sair desse elemento caótico e tentar chegar no complexo.
+
+Vou dar um exemplo. Você trabalha numa startup. As startups, elas têm que ser muito ágeis e têm que conseguir pivotar de direção com bastante velocidade também, porque elas dependem muitas vezes de aportes de investidores para existir. Elas coletam feedback muito rápido dos usuários e elas têm que responder muito rápido para conseguir coletar novos pagantes, novos clientes que queiram utilizar o seu produto. Então, no caótico, chegou um aporte de um milhão de um investidor que está querendo que o seu produto faça algo completamente diferente do que você fez. É o caos, você vai correr, o time vai varar a noite para poder tentar entregar esse negócio.
+
+Como que você sai dessa situação? Você vai aplicar os métodos ágeis, tentar definir pequenas entregas que agradem esse investidor e você vai tentar trazer um pouco mais de ordem, um pouco mais de clareza no que precisa ser feito até você poder crescer, ter um fluxo de caixa contínua, uma receita contínua que vai te ajudar a fazer essa entrega. Outro exemplo, projetos mal gerenciados, mal administrados, geralmente precisam de salas de guerra. Na sala de guerra é o caos na terra. Por que? Você junta todo mundo num lugar para poder tentar corrigir um problema que foi gerado por falta de controle, por falta de gestão clara e efetiva nos últimos meses ou nas últimas entregas do projeto.
+
+Como você sai desse cenário caótico? Você tem que reestruturar as suas entregas, resolver os grandes problemas para sair da sala de guerra, voltar para uma estrutura que você faz pequenas entregas planejadas dentro da agilidade. E aí muita gente geralmente pergunta, mas eu não consigo utilizar o método preditivo para gerenciar um método complexo? De fato não é impossível. Você consegue gerenciar, você consegue trazer um valor. Vamos usar um dado aqui que vai te ajudar a entender a superioridade dos métodos ágeis em cenários complexos. Tem um relatório muito legal do Standish Group, que é o Chaos Report, que olha para grandes empresas do mundo todo e tenta definir se os projetos que essas empresas estão entregando estão tendo sucesso quatro vezes maior do que a dos métodos preditivos tradicionais.
+
+Então 39% dos projetos que utilizam métodos ágeis têm sucesso contra somente 11% dos métodos tradicionais. O que é mais impressionante ainda é que somente 9% dos projetos ágeis ou dos métodos ágeis ou produtos que utilizam agilidade para serem entregues falham de verdade, contra 30% dos métodos tradicionais que sempre falham na entrega desse produto ou desse valor em ambientes complexos. É claro que você pode estar se perguntando Ah André, mas eu tô fazendo as contas aqui, você tá falando que ainda tem um pedaço dos projetos que nem falha e nem tem sucesso. O que é isso? Eu te explico. Muitos projetos ou muitas entregas, mesmo utilizando o ágil, tem desafios, tem dificuldades, seja porque os métodos ágeis não foram aplicados corretamente, seja porque aquele ambiente beira o caos ou por uma infinidade de outros fatores, mas quando a gente olha uma taxa de sucesso quatro vezes maior, uma taxa de falha três vezes menor para os métodos ágeis, é claro, é cristalino que eles deveriam ser utilizados em ambientes complexos porque eles estão trazendo mais valor e muito mais resultados do que os métodos preditivos tradicionais. Além disso, para trazer outro dado aqui para vocês, para a gente fechar essa aula, existe uma pesquisa muito legal, que é o relatório anual do estado da agilidade feito pela CollabNet.
+
+Eles entrevistam várias empresas, vários profissionais que trabalham com métodos ágeis para poder entender quais são os benefícios que eles enxergam na adoção do ágio. E aqui tem cinco estatísticas que eu quero compartilhar com vocês. 71% das empresas que usam o Agile entendem que isso ajuda eles a gerenciar mudança melhor do que os métodos tradicionais.
+
+66% dizem que os métodos Agile geram mais transparência e 65%, que é quase todo mundo, dizem que os métodos Agile geram um alinhamento melhor entre negócio e tecnologia. Além disso, 62% das empresas que utilizam métodos AGIES experimentam um time to market, ou seja, uma velocidade de entrega menor do que a dos métodos preditivos. E aqui é óbvio, porque no AGIES a gente faz várias entregas pequenininhas e começa a gerar valor mais cedo, como a gente tem falado lá desde a primeira aula, aqui no nosso treinamento gratuito. Por fim, a última estatística que eu quero compartilhar com vocês é que 61% dos profissionais que utilizam a Agilidade entendem que isso aumenta a produtividade das pessoas e das equipes. Então as pessoas trabalham melhor, entregam mais rápido e, inclusive, ficam mais motivadas para gerar resultado.
+
+

docs/O Agilista precisa ser minimalista_.txt

@@ -0,0 +1,16 @@
+Trazer pro time muita autonomia, e aí é uma das coisas que o Guia fala muito, na verdade a agilidade como todo mundo fala muito, e trazer autonomia com responsabilidade. Então assim, as tomadas de decisão eram do time e o que não funcionava também eram deles e que eles lidavam. Então isso é muito bom, porque você gera confiança, você gera, você torna o time mais íntegro, né? E aí eu comecei a discutir sobre isso.
+
+Cara, o que é isso em seu quadro? Então assim, eu sempre fui muito curioso. E essa informação não tá no guia. Ou seja, em resumo da conversa, se você só olha pra o guia, você só vai ter o guia como ferramenta e como boa prática. Então começa a olhar também pra outras coisas, seguir pessoas que são referência, conhecer o mercado, e aplicar aquilo que você está fazendo.
+
+Por exemplo, nesse mesmo projeto, aconteceram situações do tipo, eu era muito metódico, ainda sou, mas eu era muito mais metódico, então eu fui taxado como buy the book. Na época eu achava tudo muito ruim, hoje eu vejo isso como uma coisa muito boa, porque é necessário às vezes ser buy the book. Porque como é que você vai saber se o negócio funciona se você não coloca na prática aquilo que está escrito ali? Como é que você sabe o que é maleável, flexível ou não se você não colocar em prática? Por exemplo, daily. Ah, daily tem que durar 15 minutos. Beleza, e se ela passar e eu vou parar, galera? Não, cara. Então assim, começar aí trazendo um pouco para a questão das evidências aí. Começa a gerar evidência. Quantas vezes passou de 20? Por que passou de 20?
+
+Porque você te barrar as pessoas de falarem, você vai fazer com que elas nunca mais falem. Então você vai começar a ficar num clima muito ruim. Então assim, começa a tangibilizar essas coisas, né? Então põe em prática o que tá ali. Porque quando você for questionado, você vai ter não só conhecimento como um todo, mas nesse náutico sonho. Naquele talvez não. E essa aplicabilidade do guia para um todo. Você sabe que eu sempre adotei, e eu acho que é uma característica minha até hoje, eu sempre adotei muito um estilo de gestão, um estilo de liderança minimalista. E por que eu faço isso? Se você olhar para o ágil, a raiz, o que o pessoal falava 20 anos atrás quando lançaram o manifesto ágil, é que você, até antes disso, na década de 50, quando o Lean e o Kanban surgiram lá na Toyota, você precisa evitar o desperdício e não tem nada que gera mais desperdício na sua vida do que trabalho que ninguém tá vendo.
+
+Então, eu já fui duramente criticado por esse estilo, tá, ao longo da minha carreira e muitas vezes eu tive que bater o pé e falar, não, eu gerencio assim, eu lidero assim, é assim que vai ser. Então, o agilista, né, um dos valores do Strong é a coragem. Você tem que ter a coragem de acreditar no seu estilo de liderança, no seu estilo de gestão. E eu sempre busquei utilizar a menor quantidade possível de qualquer coisa para poder fazer gestão. Então, se você olhar, por exemplo, naquela época que a gente estava trabalhando juntos, cara, eu olhava para dois times, eram 20 pessoas e beleza. Hoje eu olho para mais de 700, devo estar chegando em 800 pessoas. Óbvio que eu não olho para 800 pessoas diretamente, eu tenho lá as pessoas que estão abaixo de mim que cuidam, eu tenho gerentes que olham para os gerentes, mas eu gerencio 800 pessoas com a menor quantidade possível de ferramentas.
+
+Cara, eu adoro um fluxo CFD, adoro entender aonde que estão as pessoas dentro do processo. A gente criou uma sala de guerra para poder atacar um assunto que é super prioritário para a gente. Gente, eu estou gerenciando uma sala de guerra que impacta, sabe, um negócio de algumas dezenas de milhões de reais com CFD. É um Kanban, eu estou gerenciando o fluxo Kanban, limitando o trabalho que está em andamento, entendendo, sabe, lead time, SQL time e com isso, assim ó, é Kanban simples, lead time, SQL time e CFD. Com isso, a gente já conseguiu aumentar a performance disso que a gente está fazendo em 25%. Duas semanas de sala de guerra.
+
+A primeira semana foi levantamento, desenho da solução. Uma semana de trabalho efetivo, aumento de 25% da performance. Já me falaram, durante essa sala de guerra, que cara, não, tem que fazer uma análise de pareto, usa aí, pelo amor de Deus, uma curva gaussiana para poder medir não sei o que lá. Vamos criar aqui, sabe? Minimalismo. Existem muitas técnicas. Ah, legal! Vamos fazer Scrum com Kanban? Lindo!
+
+Show da vida! Vamos colocar Canvas com Scrum com Kanban? Também funciona. Vamos colocar canvas, scrum, kanban e aí a gente chama a dona Jurema aqui porque ela vai me ajudar a desenhar gráficos customizados todos os dias. Você provavelmente está desperdiçando muito esforço para poder fazer a gestão. E de novo, linkando isso com a PSM2.
+

docs/Scrum só serve pra projetos de software_.txt

@@ -0,0 +1,6 @@
+Podemos dizer que o objetivo do novo guia do Scrum é que o framework fique ainda mais flexível para utilizar em qualquer área e não só em desenvolvimento de produto de software. Tenho certeza que essa mudança foi só para registrar algo que já estava acontecendo. O Scrum, quando ele surgiu lá atrás, na década de 90, ele surgiu dentro de times de software. E esses times de software, que eram os times em que o Ken e o Jeff trabalhavam, eles não tinham ainda uma visão de produto. Então o Scrum não nasceu pronto, pessoal. Conforme o tempo foi passando, de 95 até 2001, que foi quando teve o manifesto ágil, o Scrum ainda era muito focado em software.
+
+O que acabou acontecendo aí no começo dos anos 2000, entre 2000 até 2010? O Scrum começou a ser utilizado cada vez mais com uma visão de produto. Então, ele deixou de ser algo que olhava exclusivamente para projetos. E o que é olhar só para o projeto? É você olhar se você está entregando o seu escopo inicial no prazo e no custo que foi combinado. Você não está olhando para algo maior que é métricas de produto. Então, você não está olhando se a sua entrega está deixando o cliente feliz. Você, quando olha só para o projeto, você não está olhando pra saber se você está gerando mais valor para a empresa. Então o Scrum saiu dessa visão de projeto e começou a ir para uma visão de produto. Nessa visão de produto, ele começou a se afastar da exclusividade de projetos de software e ele começou a servir para produtos de todo tipo. Então ele serve para produtos físicos, então ele serve para produto de hardware, para celular, ele serve também para produtos abstratos de software e isso já acontecia. Eu já usei o Scrum, por exemplo, para poder desenhar processos novos, eu já usei o Scrum para poder desenhar produtos de vendas, eu já usei o Scrum para poder entregar, é o que a gente chama de projetos de advisory, que a gente entra, entende como funciona um negócio e faz recomendações para que o negócio melhore, não tem nada de software envolvido.
+
+Isso já acontecia. Essa mudança vem não para mudar o Scrum, ela vem para corroborar, ela vem para carimbar, ela vem para oficializar algo que já existia. Então a retirada desses termos de software que ainda existiam no Guia, nessa versão de 2017, vem para deixar isso cada vez mais claro. de 2017, vem para deixar isso cada vez mais claro.
+

docs/Tudo sobre o Manifesto Ágil _ Treinamento grátis de Scrum - Módulo 01 Aula 05.txt

@@ -0,0 +1,14 @@
+Vamos falar sobre o Manifesto Ágil. Assim como nós comentamos na aula passada sobre as 3 ondas da agilidade, o Manifesto Ágil é o documento sobre agilidade mais influente da história dessa disciplina, justamente porque ele é considerado como marco inicial da prática da agilidade e por ter sido criado em 2001 pelos maiores agilistas daquela época, incluindo nomes como os criadores do Scrum, Ken Schwaber e Jeff Sutherland, autores renomados como Martin Fowler, Alistair Cockburn e vários outros agilistas de renome como os criadores do Extreme Programming e muitos outros. Outro dos motivos pelo qual o Manifesto Ágil é tão relevante até os dias de hoje é porque ele é extremamente simples, ele é conciso na sua criação, mas apesar disso ele é extremamente poderoso porque ele ajuda a nos guiar nos nossos valores e nos nossos comportamentos em tudo que fazemos. Na prática, o que isso quer dizer é que com os quatro valores e os 12 princípios que existem no Manifesto do Ásio, a gente pode sempre verificar se aquilo que nós estamos fazendo está alinhado com a essência, com a alma da agilidade. Vocês vão entender assim que a gente passar por esses valores e por esses princípios aqui. E eu vou começar justamente pelos valores, porque eles são somente quatro, muito mais simples, muito mais fáceis de serem entendidos. O primeiro deles diz que nós valorizamos, quem somos nós? As pessoas que assinaram o Manifesto Ágil lá em 2001, mas também todo mundo que pratica agilidade. Então nós, praticantes da agilidade, valorizamos muito mais os indivíduos e a interação entre eles do que processos e ferramentas. O que essa frase quer dizer não é que a gente não precisa de processos nem de ferramentas ou que a gente não valoriza processos e ferramentas. Isso não é verdade.
+
+Tanto que hoje nós temos o Scrum como um dos principais frameworks da agilidade do mundo que diz pra gente como aplicar agilidade. A gente tem o SAFE, o LES, tem o Discipline Agile do PMI, tem uma série de processos e ferramentas que nos ajudam a entender a essência da agilidade e aplicá-la melhor no nosso dia a dia. Mas, mais importante do que sair aprendendo esses processos e essas ferramentas, nós precisamos conhecer e atuar melhor com as pessoas que estão ao nosso redor, porque é através desse relacionamento, dessa interação das pessoas, que resultado é gerado. Já o segundo valor diz que nós agilistas valorizamos o software funcionando mais do que uma documentação abrangente. Aqui é super importante vocês entenderem que naquela época a agilidade começou dentro da tecnologia, em times de tecnologia, é por isso que o vocabulário fala de software, mas como a gente sabe, a agilidade hoje pode ser aplicada para qualquer coisa, criação de produtos de hardware, serviços, software, para poder melhorar processos na sua empresa de RH, de entregas, enfim, vendas, tudo o que vocês podem fazer na empresa pode ser feito com agilidade. Uma forma da gente traduzir essa parte do software para a realidade de todo mundo é falar que nós agilistas valorizamos muito mais o produto entregue e sendo utilizado pelos seus usuários finais do que a documentação desse produto ou do que os requisitos escritos desse produto ou as coisas que nos ajudam a criar ele mas que no fim não geram valor diretamente para a empresa e que também não geram valor para os usuários. Então na agilidade a gente gosta muito de cortar ou evitar desperdício. E uma das formas de evitar desperdício é reduzir o que não é o produto, os documentos, aquilo que não nos ajuda a ter o produto, para o mínimo necessário. Notem aqui que a documentação é sim importante.
+
+Nós precisamos de documentação, seja por motivos legais, seja para atender os requisitos da empresa, às vezes que contrata uma consultoria, seja para poder facilitar a manutenção do produto ou do sistema lá para frente. Então a documentação tem que existir. Mas é muito melhor você ter um produto, por exemplo, com código-fonte comentado, que é o caso do software, ou com protótipos que sejam bem explicativos em caso de eletrônicos ou coisas assim do que você tem uma documentação gigante falando como ele funciona. O terceiro valor do manifesto ágil diz que nós valorizamos a colaboração com clientes muito mais do que negociar contratos. Na prática o que isso quer dizer? Na prática isso significa que se você não tiver um bom relacionamento com o seu cliente, se você não tiver um bom trabalho em equipe com as pessoas com quem você está atuando, não adianta você ter um contrato super bem escrito, regras de como as coisas vão funcionar, que se você precisar, vamos lá, pensem aqui comigo, se você precisar ir no seu contrato, citar uma cláusula para o seu cliente, falando que ele está errado com base no contrato, você não tem um relacionamento. A primeira oportunidade que ele tiver, ele vai te abandonar, vai trocar você por um outro fornecedor, um outro produto com quem ele tem um relacionamento melhor. Então aqui, de novo, nós temos que ter contratos entre empresas, temos que ter contratos entre pessoas, até para deixar a regra do jogo clara e para todo mundo entender como as coisas vão funcionar. Mas muito mais importante do que o contrato é você manter um relacionamento vivo com os seus parceiros, colegas de trabalho, colaboradores, usuários e clientes. É você conversar com eles, ter um canal aberto de comunicação com eles, para que você escute as reclamações de maneira recorrente e consiga atuar nelas antes que o problema escale para você ter que ir para uma batalha judicial, ou você tem que resolver isso com um advogado, ou simplesmente ter que ficar citando regras para as outras pessoas.
+
+Não é legal! Então valorizamos muito mais esse relacionamento com o cliente do que ficar discutindo o contrato e brigando com ele. E o nosso quarto valorágio diz que é muito mais importante responder as mudanças do que seguir um plano. E isso aqui está extremamente ligado com todas as aulas que nós vimos até aqui, nesse módulo sobre fundamentos da agilidade. É muito melhor a gente fazer entregas pequenas, aprender com elas, ler o ambiente à nossa volta e gerar adaptação, do que criar um plano fechado, como se a gente tivesse uma bola de cristal, e ficar fazendo de tudo para o plano ser verdade.
+
+No final, você pode até conseguir fazer tudo alinhado com o cronograma que você montou lá no começo. Não quer dizer que isso que você está entregando de fato vai ser útil pra alguém, vai gerar valor para a sua empresa ou que os seus clientes vão gostar. É super comum hoje em dia, inclusive, a gente escutar histórias de várias empresas que seguiram o plano, acharam que tinha uma resposta certa e que faliram, porque não foram espertos ou adaptáveis o suficiente para escutar os seus clientes e para poderem entregar aquilo que eles precisavam. 
+
+Outra coisa que vocês podem perceber é que muitos, ou até todos os quatro valores do manifesto ágil, às vezes até parecem como senso comum. O que o manifesto ágil não faz, ele não te diz exatamente como você transforma isso em realidade. Então não adianta também a gente falar eu sigo o manifesto ágil, mas não falar o como. E o Scrum nos ajuda nisso. Então é por isso, inclusive, que eu sempre faço essa introdução nos meus treinamentos e sempre tenho esse módulo de fundamentos da agilidade. É super importante que vocês entendam esses valores, todo esse fundamento que nos guia para poder usar o Agile melhor. Não quer dizer que isso substitui um framework ou um processo integrado, como é o caso do Sprint.
+
+O Sprint vai te falar exatamente como você pode, por exemplo, usar o seu backlog do produto para poder negociar com seus clientes a parte de documentação e de contrato. Então ele substitui, ou praticamente substitui, esses dois elementos, mas ele é mais conciso do que uma documentação tradicional. Outra coisa que o manifesto ágil faz para poder ajudar a gente é trazer um conjunto de 12 princípios que também nos ajudam a guiar o nosso dia a dia e nos ajudam a guiar as nossas ações quando a gente está trabalhando em times ágeis. Alguns deles são, por exemplo, entregar de maneira frequente? Usando sprints no Scrum, que a gente vai ver nas próximas aulas. Ele também fala muito sobre construir projetos, entregar produtos ao redor de indivíduos que estejam motivados. Poxa, como que eu motivo os indivíduos? Vamos ter uma aula, falando dos papéis do Scrum, sobre como motivamos os times, como ela é muito importante e mais efetiva até do que a documentação escrita. Eles falam sobre excelência técnica, falam sobre um bom design da sua solução, do seu produto, fala sobre a importância de refletir e ajustar aquilo que você está fazendo. 
+

docs/estruturar_times_ageis.txt

@@ -0,0 +1,12 @@
+Querem saber o que o Masterchef tem a ver com gestão de projetos ágeis?  Mesmo que você nunca tenha assistido, com certeza você já ouviu falar do Masterchef, um reality show culinário, onde os competidores criam pratos em todas as edições do programa para definir quem é o melhor cozinheiro. Apesar de parecer que não tem nada a ver com gestão de projetos ágeis ou metodologias ágeis, lá no Masterchef existe uma competição chamada de Caixa Misteriosa. Nessa competição, os competidores cheiram no programa e encontram nas suas bancadas uma caixa como essa que vocês estão vendo aí na sua tela. Dentro dessa caixa, existe uma série de ingredientes.
+
+Eles podem encontrar, inclusive, ingredientes que não se conversam. Então, vocês podem ver aí na imagem, a gente tem camarões, a gente tem morango, a gente tem queijo, a gente tem manteiga, tem ovos, a gente tem uma série de ingredientes que tem muito potencial para fazer pratos saborosos, mas que não necessariamente conversam entre si. O grande desafio, inclusive, não é utilizar todos os ingredientes. Se você tentar utilizar todos os ingredientes que vocês estão vendo na tela, dificilmente vocês vão fazer o melhor prato possível. A ideia é criar um prato que tenha apelo visual, que seja saboroso e que as pessoas tenham prazer de comer. Se você não souber utilizar os ingredientes, você acaba fazendo algo parecido com isso que vocês estão vendo aí na imagem, que é eu tentando cozinhar numa sexta-feira à noite, se eu estiver sozinho em casa.
+
+Quando todo candidato do Masterchef sabe que ele não pode misturar todos os ingredientes e tem uma ordem, uma maneira certa para misturar os ingredientes, quando a gente vai fazer uma transformação ágil, ou quando a gente vai aplicar o ágil em uma organização, a gente sabe que o mais importante não é conhecer um monte de técnicas. Tem várias ferramentas, tem vários processos, tem várias formas de se fazer o ágio. O mais importante é entender a receita que a gente está fazendo. E uma boa receita de como transformar a sua empresa, de como tornar ela ágil, inclui processos ágeis, ferramentas ágeis e uma cultura ágil que permita essa transformação. E eu gosto de falar que a dose certa de cada um desses componentes é parecida com o triângulo do fogo. No triângulo do fogo a gente tem lá calor, oxigênio e o combustível.
+
+A gente forma o triângulo. Se a gente tira um componente desse triângulo, a gente não tem mais fogo. Com o ágil, é a mesma coisa. A gente tem que começar a criar uma cultura ágil através de treinamentos, através de palestras, através de bastante conteúdo. E aí com isso a gente começa a implementar processos ágeis também. Então as pessoas já sabem o que é ser o ágio com a cultura e aí com os processos elas começam a entender o como elas devem trabalhar para que elas sejam ágeis. Depois que a gente tem os processos, aí a gente entra com ferramentas para poder apoiar essa execução e essa transformação. É super comum as pessoas começarem, por exemplo, com uma ferramenta, então, vou adotar um gira, vou adotar um trelo e aí eles acham que estão fazendo a Ajo porque a ferramenta é Ajo.
+
+Não! Tem a ordem certa. A gente começa com as pessoas, vai para os processos e aí chega nas ferramentas. E é interessante porque a base tem várias técnicas, mas não são tantas assim. A gente tem que deixar as pessoas seguras, tem que valorizar elas, tem que reduzir os riscos. Então tem uma maneira certa de trabalhar com as pessoas. Da mesma forma com os processos. Notem que a gente já tem mais processos aqui do que a gente tinha técnicas para as pessoas. Então o processo a gente pode rodar um Scrum, um Linkamban, a gente pode rodar Safe, pode rodar Nexus.
+
+Tem um processo certo que a gente vai escolher para o momento que a gente está trabalhando, para a forma como a gente está trabalhando. E aí quando a gente chega nas ferramentas, a gente tem dezenas de ferramentas para utilizar. Se a gente tentar começar por aqui, a gente com certeza vai fracassar, porque a gente não vai saber qual é o processo que está vinculado à ferramenta, a gente não vai ter as pessoas com a prática e o costume correto para utilizar ela. Então a gente tem que trabalhar vindo aqui nessa imagem da esquerda para a direita. Então a gente começa com esse mindset ágil, começa entendendo o que é ser ágil, para depois a gente começar a colocar os processos, a cultura e por último a ferramenta. A gente nunca pode inverter essa ordem. 
+