Tag: Agile Coach

Como vencer os impedimentos nos times Scrum

Publicado em por .

“Impedimento” é uma palavra com dois possíveis significados no dicionário da língua portuguesa. A primeira refere-se àquilo que impede, como um estorvo ou obstáculo, enquanto segunda se refere à posição irregular no futebol (Brasil sil sil ?).

No primeiro exemplo temos um significado que descreve muito bem o contexto que desejamos. Um obstáculo, ou seja, algo que deve ser ultrapassado para atingir um objetivo.
Já no segundo, podemos brincar lembrando que o “impedimento” de um jogador pode anular um gol, impedindo o bom desempenho do time.

Quando falamos de Scrum, o impedimento (impediment, em Inglês) é citado no guia duas vezes, sendo uma para o papel Scrum Master e outra para o evento Daily Scrum:

Entenda como o Scrum Master ajuda o time:

Removing impediments to the Development Team’s progress;

Descrevendo a Daily Scrum:

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.

O que é um impedimento?

Impedimento é qualquer fator que impeça ou retarde o time de realizar o trabalho. Com isso, o impacto é bem nítido na queda da produtividade e/ou velocidade do time.
Outra maneira de definir seria qualquer problema que vai além da auto-organização do time.

Mas afinal, quem remove impedimentos ?
O papel no Scrum que é responsável pela remoção de impedimentos é do Scrum Master, conforme citado acima, pois ele sempre está presente, conectado com o time e com o ecossistema corporativo.

Um bom Scrum Master tem a capacidade de distinguir o que é um bloqueio (que afeta uma tarefa, por exemplo) de um impedimento (que afeta o resultado da Sprint em geral) e além disso faz o rastreio desse impedimento, realiza uma facilitação entre áreas de negócio, assim como o remove definitivamente.

Faço um contraponto, colocando a responsabilidade também para o time de desenvolvimento, pois eles precisam se comunicar bem quando acontece um impedimento, assim como quando se tem um Scrum Master que empodera seus times ele deixa o próprio time correr atrás e remover o impedimento que está afetando o resultado final.

O impedimento terá proporções e até significados diferentes durante a curva de maturidade do time, vou dar alguns exemplos com a “curva de Tuckman”, lembrando que isso não é uma regra, mas acontece na maioria das vezes:

Durante o Forming (formação do time)

Pouco impedimento, tudo corre bem, o time ainda não entende o que é impedimento, mas como a meta das sprints não são atendidas e o BOM Scrum Master orientará o time. O time começará a reportar impedimentos timidamente.

Durante o Storming (“pau quebrando” ?)

Neste momento tudo é impedimento. “O P.O mandou um e-mail sobre uma história” o time já diz que é “impedimento”, troca de algum item do backlog (mesmo que tenha a mesma pontuação) o time dirá que é “impedimento, o ar condicionado não esta gelando bem = impedimento, o almoço não estava legal = impedimento, o outro time demorou 45 minutos pra responder uma dúvida = impedimento. Este é o momento que toda desculpa será chamada de “impedimento”.

Força Scrum Master isso vai passar mas, neste momento, um bom Scrum Master deve ser paciente e mentor.

Durante o Norming (time vivendo a realidade)

Neste momento os impedimentos que aparecerão serão mais pontuais e provavelmente precisarão da liderança, negociação e “jogo de cintura” do Scrum Master. Este time já resolve quase tudo por conta e quando dizem que tem um impedimento, o Scrum Master já entende que não é tempo de ser “mentor” e sim de ser “removedor”.

Durante o Performing (time voando)

Aqui quase não se vê impedimentos no board.

O time já conhece os processos e as pessoas, já articula bem a resolução de todos os itens simples e médios ficando para o Scrum Master apenas os obstáculos que envolvem: ego, negociação, politicagem, etc.

Mas, quais os principais tipos de impedimentos?

Segue abaixo um infográfico, onde destacamos alguns dos impedimentos mais comuns relacionados a : tecnologia, processo e pessoas:

Como conseguimos remover e tratar os impedimentos?

Seguem abaixo algumas dicas sobre remoção de impedimentos:

  1. Não espere a Daily Scrum para falar sobre um impedimento identificado, registre esse impedimento, chame o Scrum Master para que isso traga o menor impacto possível para a meta da Sprint;
  2. Usar objetivo da Sprint, se o impedimento não afeta a Sprint em questão, registre, mas não gaste esforços extras: Não gaste tempo na solução do problema errado!
  3. Melhorar a transparência, dêem visibilidade para todos, através de ferramentas e radiadores de informação (seu board, kanban etc.);
  4. Acompanhe e faça rastreabilidade de impedimentos fixos;
  5. Seja corajoso e criativo;
  6. Colaborem com o Product Owner;
  7. Usem o refinamento para se antecipar a impedimentos clássicos;
  8. Coloquem no DOR (Definition of Ready, em português “definição de preparado”). Deixem claro que PBI (item de backlog) que já possui um impedimento conhecido não deve entrar até o impedimento ser removido.
  9. Revisem os impedimentos conhecidos na planning. Caso algum PBI passe pelo refinamento não deixe entrar no Sprint Backlog.
  10. Esse 10 só entrou para ter 10 mesmo, como se fossem os 10 mandamentos.

Pesquisando sobre abordagem para lidar com impedimentos, achamos uma forma interessante, com 5 etapas: Confirmar, Triagem, Remover, Dar Visibilidade e Aprender (ConTROL):

Fonte: https://www.axisagile.com.au/blog/planning-and-metrics/incriminating-impediments/

Concluindo

Para identificar e remover impedimentos não existem varinha mágica ou bala de prata, por isso é sempre importante que uma vez identificado, todos se responsabilizem para correr atrás e remover o mais rápido possível.

Impedimentos nos levam a desperdício, e precisam ser eliminados em tempo real para não impactarem a produtividade do time.

Mas acredito que a dica de ouro é: tente se antecipar aos impedimentos conhecidos.

E aí, como vocês abordam seus impedimentos? Como os tornam visíveis? Vocês tem uma lista de impedimentos conhecidos?

Vamos discutir o tema com a comunidade; compartilhe, comente sua experiência, dê like no artigo para ele ganhar relevância e vamos falar sério sobre o tema.

Tem dúvidas sobre o mundo ágil? Conte pra gente!

—

Este artigo foi escrito pelos parceiros Ricardo Bruno, MBA, CSM, CSPO, SFC, CLF, CAC

e João Batista Santos – JB.

Como um Agile Coach pode ajudar o Product Owner a não se tornar um simples “tirador de pedidos”?

Publicado em por .

Atualmente nas empresas que estão passando por um processo de transformação organizacional, querendo sair da inércia, de quebrar o paradigma do caminho hierárquico e dos silos departamentais, acabam não dando todos os subsídios para que os profissionais possam exercer suas funções em plenitude. Vemos cada vez mais, gerentes de áreas de negócio, analistas de requisitos ou “hard users” dessas mesmas áreas assumirem um papel de Product Owner, simplesmente por que de um dia para outro a empresa falou que serão ágeis. Nesse contexto, frequentemente esses profissionais nem conhecem e nem sabem de fato o que precisam fazer, realizando um trabalho aquém do esperado e sem trazer eficácia na entrega e na qualidade dos produtos.

Segundo o Scrum Guide (http://scrumguides.org/scrum-guide.html):

“O Product Owner é responsável por maximizar o valor do produto e o trabalho do time de desenvolvimento. O Product Owner é a única pessoa responsável por gerenciar o backlog do produto. O Product Owner pode representar os desejos de um comitê no backlog do produto, mas aqueles que desejam alterar a prioridade de um item no Backlog devem recorrer ao Product Owner.”

E agora P.O.?

No contexto descrito anteriormente, o que acontece em muitos casos? Os Product Owners não sabem a dimensão do seu trabalho, não tem a mínima ideia de como escrever histórias e nem definir as prioridades de um produto, consequentemente mal conseguem responder aos inúmeros questionamentos que são feitos pelo time de desenvolvimento.

Isso também, quando não são abordados por gerentes, diretores, CEO, entre outros que fazem todos os tipos de solicitação, nesse caso, o Product Owner submetido por pressão ou intimidação, acabam “tirando o pedido”, sem nenhum critério, criando uma alta expectativa para quem realizou essa solicitação. Podendo com isso gerar um PBI (Product Backlog Item) para adicioná-lo no planejamento de uma próxima Sprint, ou até mesmo inseri-lo indevidamente na Sprint atual.

Por não fazer perguntas poderosas, esse Product Owner acaba sendo um mero repassador de problemas e não entendendo se a demanda solicitada vai atender ou não a real necessidade do cliente, podendo até gerar um novo problema.

Dado esse contexto, onde entraria o Agile Coach nesse cenário?

Um Agile Coach seria de extrema importância para atuar em conjunto com o Product Owner, que dada a situação encontra-se totalmente perdido, desde que consentido por ele, para realizar um forte trabalho, fazendo com que o PO entenda e consiga enxergar alternativas e métodos para mudar essa situação.

O primeiro ato desse Agile Coach seria ter uma conversa de coaching com o Product Owner, identificando o seu momento atual e qual é de fato o seu nível de conhecimento sobre o papel que ele desempenhará para a empresa e para o time, podendo assim treiná-lo minimamente sobre o que é esperado na sua posição de PO, repassando conceitos básicos de SCRUM, ensinando técnicas preliminares de como se comportar e agir diante das mais variadas solicitações que ele receberá.

Após entender a situação atual e trazer o PO para um novo nível de conhecimento, será muito importante o Agile Coach acompanhar e apoiar esse Product Owner para que aos poucos ele vá se engajando melhor e possa realizar de forma eficaz o seu trabalho.

É válido orientar o Product Owner na busca de conhecimento complementar através de cursos e certificações existentes no mercado.

O Agile Coach deve estabelecer um prazo junto com o PO para medir os seus avanços e identificar junto com ele novas necessidades de melhorias no seu trabalho.

O Product Owner deverá imergir profundamente nas solicitações que ele receber e entender qual é de fato o problema que precisa ser resolvido. Qual o retorno que essa demanda terá para a organização? Diminuição de custos? Aumento de receitas? Diminuição de reclamações de clientes? E assim escrever histórias completas, detalhadas e com um nível pré-acordado (Definition of Ready) com o time para que seja possível realizar de forma mais assertiva as suas estimativas.

Essas são algumas questões que o Agile Coach pode trabalhar com o Product Owner para melhorar o refinamento do backlog do produto, melhorar a qualidade da escrita das histórias que serão priorizadas e assim poder repassar para o time de desenvolvimento nas reuniões de Sprint Planning o real motivo da inclusão desse PBI e o quanto de valor e benefício será gerado no final dessa Sprint, fazendo com que o time de desenvolvimento esteja sempre engajado, mais motivado e contextualizado com o valor que será obtido com os esforços que serão dispendidos.

Concluindo

O papel do Product Owner é importantíssimo, pois ele traduzirá as necessidades estratégicas das empresas em desenvolvimento de novos produtos, melhorias de produtos existentes e também para passar de forma mais detalhada possível as informações para o time que fará “a mágica” acontecer. Esse é um papel que o Agile Coach precisa sempre acompanhar de perto e auxiliar sempre que possível para ter uma melhor integração e obtenção dos melhores resultados.

 

Sobre o autor: Ricardo Bruno

Ricardo Bruno Alves da Silva

Ricardo Bruno, tem mais de 20 anos de experiência com tecnologia. Foi sócio fundador de 2 startups, trabalhou em empresas de médio e grande porte, como provedor de internet, indústria, varejo e serviços. Amante de frameworks ágeis como Scrum, Kanban, Lean, XP e Lean Inception. Hoje é Agile Coach de uma fintech em grande crescimento. Além de Agile Coach (CAC) certificado é também:
Leader Coach
Certified Scrum Master (CSM)
Certified Scrum Product Owner (CSPO)
CLF® – Certified Lean Inception Facilitator

https://www.linkedin.com/in/ricardo-bruno-alves-silva/

Não existe Agile sem Desenvolvimento Ágil de Software

Publicado em por .

Durante a formação para minha certificação CAC – Certified Agile Coach da Massimus, tive a oportunidade de participar de 2 módulos com o Peterson Larentis referentes a Agile Software Development e que trouxe a tona diversas situações que eu já defendia e já havia escrito a respeito. E o fato é que não existe um time ágil que não desenvolve software de forma ágil.

Mas como assim, como desenvolvemos software de maneira ágil?

Como será que o Scrum Dev Team vai desenvolver ágil? Será que é programando mais rápido? Trabalhando mais horas? Usando um framework milagroso que otimiza 50% do tempo? (Afinal o time deverá desenvolver o dobro na metade do tempo, principalmente se seu chefe só leu a capa do livro do co-criador do Scrum e do manifesto ágil Dr. Jeff Sutherland “A arte de fazer o dobro do trabalho na metade do tempo”). A resposta para estas perguntas são mais simples do que parecem.

Me formei em Ciências da Computação na Universidade Católica de Pernambuco em 2002 e mesmo antes de entrar nesse mundo acadêmico eu já trabalhava com programação (época de Clipper e Delphi), mas por falta de conhecimento, programava sem nenhuma técnica, simplesmente ia escrevendo o programa, sem se preocupar com usuário, com o aumento do processamento, com limitações de hardware, entre outras variáveis.

Houve muita evolução de lá pra cá… Surgimento de Programação Orientada a Objetos, por exemplo, foi um tapa na cara dos programadores acostumados com desenvolvimento procedural/estruturado.

Muitos programadores tiveram que aprender novamente, literalmente, a como programar com essa estrutura. Entender melhor sobre classes, métodos, linguagens interpretadas, abstração, polimorfismo, design patterns, entre outras técnicas, ferramentas e boas práticas que estavam surgindo a todo vapor.

Confesso que quando deixei de programar em Pascal/Delphi, Visual Basic e comecei a aprender Java, realmente vi que eu não sabia nada de programação.

Nessa mesma época, já começava também a desenvolver alguns web sites em HTML, CSS, Javascript, ASP 3.0, PHP, que eram totalmente diferentes também.

Voltando ao assunto original, o que aprendemos na Universidade sobre os melhores conceitos de Engenharia de Software e como obter os melhores benefícios e resultados sobre as melhores práticas de programação, na maioria das vezes ficavam de fato somente no mundo acadêmico.

Me falavam que na vida real era diferente, que precisava entregar os projetos para os clientes para começarmos sustentação e liberar as equipes para novos projetos.

Muitos programadores da old-school ainda hoje, trazem consigo muito dessa cultura, que para o mundo atual já não faz mais nenhum sentido.

Pegávamos projetos de escopo fechado, passávamos semanas, quiçá meses, escrevendo documentação em UML, especificação de requisitos, modelagem de banco de dados, antes mesmo de iniciar a programação. Quando íamos programar o tempo era mais curto do que o que tinha sido vendido e os programadores para entregar os projetos no prazo, tinham que trabalhar até mais tarde, fins de semana, para não correr o risco da empresa contratante não cobrar multas.

O que acontecia nesses casos, o código que era gerado era em muitas vezes de má qualidade, pois os testes eram deixados de lado, ou só faziam os velhos testes (pelo caminho feliz).

O programa ia para a área de QA (quando tinha) e o que acontecia? Bugs e mais bugs, que geravam uma lista enorme para os programadores corrigirem suas “gambiarras”, o que atrasava ainda mais a entrega dos projetos.

Quando acabavam todos os testes e os bugs eram corrigidos, começava uma nova via-crucis que era fazer deploy no ambiente do cliente. O que acontecia em muitas vezes? No ambiente do cliente não funcionava, pois era diferente do ambiente de desenvolvimento e nessas horas, ouvíamos aquelas frases prontas:

  1. Mas na minha máquina ou no meu ambiente funcionava!
  2. Ah, mas isso é problema de infra-estrutura ou de redes!
  3. A equipe de infra, falava: Ah! O problema é na programação que foi mal feita.

Entre outras frases clássicas que viraram verdadeiros chavões.

O que acontecia? (Será que em alguns lugares ainda acontece? Fica a dúvida)

A TI não entrega no prazo, TI entrega os projetos com problemas, TI não dá suporte e não resolve os problemas em ambiente de produção.

Mas daí então, chegou a bala de prata, “metodologias e frameworks” ágeis, como Scrum, Kanban e XP. Daí começa então o monte de quadros e paredes cheias de Post-Its nas salas, Trello, Jira, TFS, entre outras ferramentas para acompanhamento de Sprints e Releases.

Na maioria dos casos, melhorou muito, pois os erros e problemas eram encontrados mais rápidos, as empresas começaram a ver valor e a disseminação da cultura ágil começou a ser propagada com muita rapidez.

Diversas certificações, cursos, workshops, treinamentos, formação de Scrum Masters, Product Owners e demais outros papéis que foram criados nesse meio tempo.

Só que continuávamos criando produtos sem nos atentar a princípios básicos e importantes de Engenharia de Software.

Uma nova forma de Desenvolvimento de Software

Mas graças a Deus (ou a entidade que você preferir rs..), isso avançou bastante, as empresas, consultorias começaram a enxergar valor nisso e então passaram a investir em mão de obra especializada, arquitetos de sistemas, a investir em testes de software automatizado, através de BDD (Behavior-Driven Development) e TDD (Test-Driven Development), só que pessoas nesse perfil eram poucas, caras e muitos insistiam a não ver valor nisso e sim só custo.

Cresceu com uma ótima fluidez a cultura DevOps, onde a galera sempre injustiçada de infra, começou a desenvolver bastante programação, criação de máquinas virtuais, imagens de servidores em Docker, uso Kubernetes para fazer a orquestração dessas novas imagens de máquinas criadas em Docker.

Cresceu a adoção de softwares como: Sonar Qube, Codacy que realizam inspeção da qualidade do código para revisões automáticas, detecção de bugs e vulnerabilidades de segurança e ferramentas de automação de teste como: Cucumber e Selenium.

Cada vez mais a equipe DevOps está sendo envolvida desde o início dos desenvolvimentos dos produtos, participando de reuniões de planejamento, Lean Inception ou Design Sprint, colaborando com o Dev Team nos deploys cada vez mais automatizados e frequentes.

Concluindo

Não existe Desenvolvimento Ágil de Software sem usar as melhores práticas e técnicas de engenharia de software, sem usar metodologias como XP (independente da linguagem de programação), sem usar um framework ágil (como o Scrum, com o método Kanban), assim como uso de técnicas de desenvolvimento de software BDD, TDD, Continuous Integration (CI), Continuous Delivery (CD), versionamento integrado e acima de tudo um time único, sem “mimimi” por ser de desenvolvimento ou de infra-estrutura, afinal, trabalha-se geralmente numa mesma empresa e o objetivo comum que é entregar o melhor software e ambiente tecnológico para atender o cliente da empresa.

Se alguém se interessou pelo tema, existe um EAD específico no site da Massimus que eu recomendo fortemente e de preço super acessível.

ASD – Agile Software Development – https://ead.massimus.com/asd-agile-software-development

 

Vamos discutir o tema com a comunidade, compartilhe, comente sua experiência, dê like no artigo para ele ganhar relevância, vamos falar sério sobre o tema.

E ai seu time é ágil mesmo ou estão fazendo Go Horse com Post-it?

Como lidar com Débitos Técnicos do Time de Desenvolvimento?

Publicado em por .

Olá Scrum Masters, Product Owners e Agile Coaches, como vocês têm lidado com PBIs (Product Backlog Items) de débitos técnicos do time?

Quis começar esse artigo com uma pergunta e aproveito a oportunidade de colocar alguns pontos de vista sobre essa questão.

Os débitos técnicos são itens gerados pelo Time de Desenvolvimento, onde durante a codificação das histórias percebem a necessidade de criar esse PBI e revisitar futuramente essas partes de código para realizarem refatoração.

É errado isso?

Eu acredito que não, quando temos uma cobrança forte para entrega de uma Sprint, cabe ao time de desenvolvimento definir como devem implementar certos pontos do código e nesse caso se para atingir o objetivo da entrega seja necessário “pecar” em alguma das melhores práticas de desenvolvimento ágil de software para o bem da entrega, nesse caso eu acho válido, desde que esse mesmo desenvolvedor registre esse débito técnico e todo o time tenha ciência que precisa ser refatorado.

E como fazer para reduzir esses PBIs de débitos técnicos?

Durante a Sprint Retrospective, que é o momento onde todo o time de desenvolvimento aproveita para realizar Kaizen do processo, precisam conversar e estabelecer um plano de ação para a redução desses itens. Hoje em dia, diversas ferramentas são utilizadas durante o processo de deploy contínuo, como por exemplo: Sonar Qube e Codacy, que realizam inspeção da qualidade do código para revisões automáticas, detecção de bugs e vulnerabilidades de segurança e que “deduram” pontos para o time de desenvolvimento atuarem para correção/melhoria desses “issues”.

Qualquer Product Owner durante uma Sprint Planning, que ele traz a lista de PBIs priorizados para que o time faça a estimativa e identifique o que cabe na próxima Sprint, dificilmente entenderia a inclusão de um item identificado pelo Dev Team de débito técnico, nesse ponto é salutar que haja uma boa negociação com esse PO para que ele entenda a necessidade de refatoração de partes do código para uma melhor performance e também para evitar bugs e vulnerabilidades nos sistemas.

Uma alternativa válida é se comprometer com um número menor de histórias e ter um “buffer” para refatoração efetiva dos pontos identificados.

Concluindo

Débitos técnicos são ocorrências que sempre existirão durante o ciclo de vida de um produto, é responsabilidade de todos do time de desenvolvimento terem a consciência e a auto-organização necessária para identificá-los e em momentos oportunos realizar as melhorias visando a melhor qualidade do código e a satisfação do cliente com o produto que está sendo entregue.

Vamos discutir o tema com a comunidade, compartilhe, comente sua experiência, dê like no artigo para ele ganhar relevância, vamos falar sério sobre o tema.

Agile: entenda o que é e como aplicá-lo à sua empresa

Publicado em por .

 

Os métodos ágeis ganham cada vez mais proeminência e importância na administração de empresas. De forma simples, podemos dizer que o Agile é um mindset, um conjunto de princípios e valores que norteia a forma de se enxergar as organizações. São quatro os pilares que norteiam o Agile:

  •         Indivíduos e interações mais que processos e ferramentas
  •         Produto ou serviço  em funcionamento mais que documentação abrangente
  •         Colaboração com o cliente mais que negociação de contratos
  •         Responder a mudanças mais que seguir um plano.

A partir destes valores surgem princípios, que por sua vez são sistematizados e operacionalizados por meio de frameworks.

O objetivo, portanto, é remodelar processos para que o foco da administração da empresa seja muito mais na entrega de produtos e resultados do que nos procedimentos. A ideia é desburocratizar processos e dinamizar as relações entre as equipes.

Para atingir tais objetivos, como dissemos, diversos frameworks foram sendo foram sendo desenvolvidos e aplicados às organizações. Dentre estes frameworks, o Scrum talvez seja o de maior destaque.

Como nos explica Heitor Roriz Filho, fundador da Massimus e Certified Scrum Trainer – CST® pela Scrum Alliance, “os métodos ágeis, são atualmente o estopim da Nova Administração, estão pressionando empresas e profissionais a criarem novas formas de condução da empresa como um todo. Claro que alguns métodos se destacam mais que outros. O Scrum é o maior destaque, padrão de mercado internacional.”.

Aplicabilidade do Agile na administração de empresas

O Agile pode ser aplicado nas mais diversas organizações, independentemente de suas atividades finais.

É verdade que suas linhas mestras, registradas num manifesto publicado em fevereiro de 2001, são fruto da reunião de proeminentes figuras da indústria de softwares.

No entanto, se o desenho do Agile fora feito objetivando inicialmente mais eficiência na produção de softwares, hoje, os métodos ágeis extrapolam e muito este escopo inicial.

De acordo com Heitor Roriz Filho, essa aplicabilidade do Agile para outras áreas é um processo natural. Como ele nos diz, “os criadores do Manifesto Ágil não criaram um modelo ou metodologia específicos. Ao criarem um mindset, um zeitgeist, eles abstraíram um conjunto de ideias referentes à forma como pessoas criam produtos dentro de empresas. Obviamente encontramos referências à palavra “software” pois os criadores eram todos dessa indústria.”

Ele continua: “Como Agile é o estopim da Nova Administração, as empresas hoje devem ser muito gratas por estarem existindo neste momento, num mundo em profunda transformação. Uma empresa que se encontra na Realidade da Lei de Moore, onde mudanças ocorrem exponencialmente, tem a grande oportunidade de ser pioneira e estar na frente da competição. Isso porque quem experimentar novos conceitos primeiro, falhar, aprender, ajustar e iterar em cima disso, colherá os frutos de uma governança fluida primeiro. Isso proporciona sustentabilidade a longo prazo para qualquer empresa.

Beyond Agile Project Management

A administração de empresas precisa evoluir em suas práticas. E para isso, apenas vontade não basta. Manter-se atualizado das práticas no estado da arte da gestão, voltadas para a entrega e não para a burocracia dos processos, é um pré-requisito indispensável para a sobrevivência de qualquer organização.

Para Roriz Filho, no entanto, “pouquíssimas são as empresas que compreendem o Agile em sua essência”.

Desta maneira, ciente da importância deste mindset para a sustentabilidade das organizações, é que a Massimus foi fundada.  

“Fiquei impressionado com a desburocratização que as práticas do Scrum ensinam à empresa e isso garante que o que você se propõe a fazer, será entregue. Porém, sempre soube que para isso acontecer de verdade, algo na empresa tinha que mudar fundamentalmente. Então fundei a Massimus em junho de 2007 com o slogan “Beyond Agile Project Management”. Quase 12 anos depois o slogan continua o mesmo! O mercado finalmente está percebendo a necessidade de uma governança fluida. Temos que continuamente melhorar, deixar a empresa hoje melhor que ontem, e a Massimus é uma parceira nesse processo”, completa Heitor.

Cursos e certificações reconhecidos internacionalmente

Hoje, a Massimus é uma das poucas empresas brasileiras autorizadas pela Scrum Alliance a emitir certificações em seu nome. Isso resulta em cursos desenvolvidos dentro dos mais elevados padrões internacionais de qualidade, ministrados exclusivamente por um corpo de instrutores altamente gabaritados.

O sócio fundador da Massimus explica melhor como se dá essa parceria: “A Scrum Alliance é uma organização sem fins lucrativos. O seu único intuito é mudar o mundo do trabalho (change the world of work). A Massimus compartilha do mesmo propósito. Para isso, a Scrum Alliance formou um corpo de instrutores de altíssima qualidade e padrões de treinamento muito altos e bem estruturados. Não basta “montar um treinamento”, tem que medir o aprendizado utilizando objetivos de aprendizados bem claros. Os cursos criados pela Massimus, como a formação em Agile Coaching (CAC®), seguem os mesmos padrões e em alguns casos vamos além.

Desde sua fundação a Massimus vem se consolidando como referência em certificações não apenas no Brasil, mas também ao redor do mundo. Alemanha, Bélgica, Bolívia, Bulgária, Dinamarca, Equador, Espanha, Estados Unidos, Finlândia, Holanda, Hungria, Índia, Inglaterra, Irlanda, Luxemburgo, Peru, Polônia, Portugal, Suécia, Suíça e Venezuela são países já contemplados com cursos e treinamentos ministrados pela Massimus.

Tal experiência e expertise amplamente reconhecidos garantem à Massimus um lugar privilegiado no mercado de treinamento e certificação, diferenciando-a das demais empresas existentes no mercado.

“Nós vivemos e respiramos aquilo que ensinamos: valores e práticas mais humanas. Os valores da empresa são literalmente os valores do Scrum. Toda a gestão usa Scrum. Isso nos permite ter o melhor e mais preparado time de profissionais produzindo, gerindo e entregando produtos e serviços de altíssima qualidade. Nesse aspecto, não temos competição”, diz Heitor.

Agile para a administração de sua empresa

A Massimus oferece uma gama completa de cursos presenciais e on-line para que as organizações e profissionais mantenham-se atualizados e preparados para enfrentar os desafios do século XXI.

Além dos cursos, a Massimus também oferece consultoria para empresas que precisam dinamizar seus processos e efetivar a Transformação Organizacional, etapa tão necessária à gestão eficiente e à eliminação da burocracia.

Entre em contato com a Massimus e posicione a sua organização Beyond Agile Project Management!

           

 

MBA: 7 motivos para você pensar antes de fazer um

Publicado em por .

Se assim como eu, você questiona os modelos tradicionais de educação e se você tem certeza que seus filhos viverão um mundo novo, esse post é para você. Vou comparar os benefícios de cursos sobre a nova economia, Agile e o novo modelo de gestão de pessoas Vs MBA em instituições tradicionais que ainda não se atualizaram.

Estamos no olho do furacão quando o assunto é transformação organizacional. A nova filosofia de gestão ágil é um caminho sem volta. Na contramão global, estão os cursos de graduação e MBA das instituições tradicionais e consagradas.

Não estou dizendo que você deveria desprezar a edução, digamos, clássica, para todas as ciências. Porém, principalmente para gestão de pessoas, fundamentos da administração, gestão de projetos e áreas de TI, as escolas tradicionais não estão acompanhando a revolução que está acontecendo.

Ainda ensinamos pessoas a criar desenhos organizacionais verticais – você sabia que no Brasil temos em média 8 níveis hierárquicos? – e a fazer gestão de projetos baseados em comando e controle. Não ensinamos modelos horizontais, mecanismos de empoderamento de times, gestão de projetos adaptativas e agéis e por aí vai.  

Não estou dizendo que devemos parar de estudar, pelo contrário. Devemos estudar mais porque o mercado está mais rápido e competitivo. Mas vamos estudar “o que” e “onde”?

Com o objetivo de ajudar os jovens talentos a se organizarem e tomar melhores decisões sobre suas carreiras, eu fiz esse post com 7 motivos para não fazer um MBA, que vão fazer você pensar duas vezes antes de fazer um MBA.

  1. Corpo docente formado em sua maioria por mestres e doutores;

Vamos lá! Alguém aqui duvida de que o mercado muda mais e mais ano após ano? Se para quem já está no mercado é difícil se manter atualizado, quem dirá para quem investe praticamente todo o tempo no mundo acadêmico.

Sim, mestres e doutores tem muito valor, mas eu acredito que a balança está desequilibrada. As diretorias de ensino das instituições registradas no MEC obrigam as coordenações a contratarem professores fixos apenas se eles tiverem tais títulos. Eu já vi isso ao vivo! Se pelo menos tivéssemos uma distribuição melhor entre professores que estão no mercado com os mestres e doutores teríamos mais troca. Um aprenderia com o outro e todos ganhariam.

O uso desses títulos foi um argumento de vendas usado no passado. Quando as instituições usavam esse atributo em suas campanhas publicitárias para angariar jovens para os vestibulares. Como esse é um mercado que pouco inovou nos últimos 10 anos, o mote continua e as políticas dessas universidades não promovem nenhuma mudança no status quo.

  1. Grade curricular com temas do século passado;

Eu não quero ser desrespeitoso, então não vou citar os nomes das instituições, mas eu preciso mostrar o que eles vendem/ensinam. Vamos ver o que uma clássica instituição “vende” na apresentação do seu curso de MBA em Gestão de Projetos:

massimus-MBA

Vamos analisar os 4 itens acima?

  • Gestão por meio de processos e outros recursos: nada ágil, hã? Na nova filosofia de gestão nos deveríamos estar orientados por “indivíduos e interações mais do que processos e ferramentas” não acha?
  • Gestor líder: não percebo aqui a máxima do mundo do ágil de hoje, onde preferimos líderes servidores. Aí quando eu olho o item 3 fico aterrorizado.
  • Controlar: em pleno século 21 estamos ensinando aqui o abominável Comando & Controle. Filosofia de gestão do século passado e baseada nos modelos hierárquicos falidos.
  • PMI: bem, é isso. Mindset ágil, scrum, Kanban, Xtreme Manufacturing, XP ou out is, conceitos não são colocados em primeiro nível na descrição do curso ou na grade.

  1. 40 mil reais equivalem a 7 certificações ou formações relevantes (mais um montão de livros);

40.000 reais é o valor aproximado de um curso de MBA na instituição acima. Outros MBA podem chegar até em 70.000 reais aqui em São Paulo. Será que vale a pena? Vamos fazer uma conta de quantos outros cursos você poderia fazer nesses valores tomando como base os 40k.

Com 40.000 reais você poderia fazer:

  • Digital Immersion Program – 9.700 na Digital House. São formações executivas em diversas áreas da transformação digital, por exemplo, marketing e RH.
  • Certified Agile Coach – 7.000 na Massimus, onde você também se certifica como Leader Coach. Te dá uma visão holística sobre agilidade e transformação organizacional. .
  • Certified Scrum Master – 2.500 para ser certificado pela Scrum Alliance. Você terá a visão e ferramentas para implementar o scrum. Você também encontra na Massimus ou na K21.
  • Certified Product Owner – 2.500 para ser certificado pela Scrum Alliance. O papel do Product Owner é fundamental em um time ágil. Você aprenderá como executar e utilizar ferramenta para gestão de produtos no Scrum. Você também encontra na Massimus.
  • Management 3.0 – 2.000 na Adaptworks, por exemplo. Você precisa aprender as técnicas e o mindset da nova gestão. Vai te ajudar a desconstruir o modelo Comando e Controle do século passado.
  • Kanban Management Professional – 2.000 aproximadamente na Adaptworks. Kanban é incrível para gerenciar uma operação com alta demanda e onde o time box do Scrum não é viável.
  • Data Analytics – 12.700 para um curso na Digital House que te dará toda a formação para você trabalhar com grande volume de dados para tomar decisões.
  • E ainda é possível comprar aproximadamente 30 livros sobre os temas acima para complementar seus estudos. Ou fazer um monte de cursos de qualidade no Coursera, por exemplo.

  1. As 7 certificações ou cursos relevantes acima ainda expandem o seu networking aproximadamente 6 vezes mais do que um MBA;

Em uma boa turma de MBA você deverá criar 30 conexões com seus colegas de classe. E se cair em uma turma menos sênior pode ser que não queira desenvolver uma grande conexão com todos.

Participando dos cursos acima você terá aproximadamente 6x mais conexões, devido a média da turma. E ainda se destacar nas turmas e criar conexões também com os instrutores, que em geral são bem ativos nas comunidades de seus assuntos e são um network de muita qualidade.

É claro, escolha bem a escola, os professores e seja exigente com a turma. Afinal, são os alunos que elevam a barra de qualidade.

  1. As profissões ensinadas em MBA não irão existir em 10 ou 15 anos;

Com certeza você já leu inúmeros artigos sobre profissões que irão deixar de existir devido a automação. Pois é, a lista não é pequena não. Por exemplo, Carl Benedikt Frey e Michael A. Osborne, da Universidade de Oxford, estudaram cerca de 700 profissões e suas chances de automação. Pasmem, segundo eles, metade das ocupações deixarão de existir na União Europeia em aproximadamente 20 anos. A lista conta com carreiras de Juristas, Contadores, Arquitetos, Estatísticos e até alguns tipos de professores. Confira o estudo aqui!

Não veremos transformações só pela automação. Outras profissões se reinventarão. Falamos ali em cima sobre liderança servidora ou auto-organização de equipes mais do que comando e controle, por exemplo. Você tem dúvidas de que a filosofia de gestão ágil será predominante nas corporações e startups em um futuro próximo? Os Millennials são muito mais empreendedores. Já imaginou não proporcionar uma estrutura organizacional que não permita empreendedorismo interno e auto-organização? Eles também precisam de propósito. Já pensou como isso impacta a sua estrutura de metas? Veja esse artigo da Michel Page.

Nossos cursos de formação superior e MBAs não estão preparados para essas transformações.

  1. Quando você terminar de pagar o MBA já terão sido lançadas 2 novas versões de iPhone – ou de um novo Sx da Samsung;

Você deve ter achado esse tema estranho, mas pense comigo profundamente. A tecnologia muda a vida das pessoas em uma velocidade nunca antes vista. Todos os anos vemos evoluções tecnológicas que mudam mercados e sociedades mundo a fora. Resumindo, a cada nova versão de um novo smartphone o mundo avança em inovação e o seu curso de MBA fica cada vez mais desatualizado.

O mundo todo vai mudar bem na sua frente nós próximos dois anos. E você estará pagando os R$ 1.000 e poucos reais todos os meses.

  1. Você paga para ter um “título”, que tem cada vez menos valor;

IBM, Apple e Google são só alguns exemplos de gigantes que não exigem diplomas universitários para contratar. Em uma matéria* da Olhar Digital de agosto do ano passado podemos ver que 15% dos novos contratados na IBM nos EUA não tem ensino superior. No mesmo texto, Maggie Stillwell, responsável por recrutamento na gigante Ernst & Young, “qualificações acadêmicas ainda são levadas em consideração e continuam um ponto importante na avaliação de um candidato, mas não são mais uma barreira para colocar o pé para dentro da porta”.

Aqui no Brasil, empresas como a Movile e Nubank também não tem essa exigência**. Essa é uma tendência. Nossas instituições tradicionais não acompanham o desenrolar do mercado. Se cada vez mais não teremos alunos nos cursos universitários, qual será o futuro dos cursos de pós-graduação, como o MBA?

Agora, se você já passou por todos os cursos acima, indico fazer o seu MBA. E ajude a elevar a barra da turma em que você estiver. QUASE TODOS os meus amigos que iniciaram um MBA presencial nos últimos anos abandonaram o curso ou terminaram SÓ PARA TER O TAL SELO de um MBA no currículo. Triste, né?!

Conclusão

Não sou contra o MBA. Acredito que a nossa barra está baixa, que as grades são ultrapassadas e que muitos professores precisam se renovar. Há uma revolução a caminho, assim como vemos na indústria de mídia e logística/transporte, por exemplo. Isso também vai acontecer com a educação.

Não tenho dúvidas que minha filha viverá um mundo diferente no que diz respeito a cursos superiores. Que bom! Tomara que a próxima geração supere a nossa e que as empresas do futuro sejam mais humanas, horizontais e baseadas em tecnologia de ponta. Afinal, é por isso que me tornei Agile Coach. Para que minha filha não precise trabalhar nas empresas que eu me deparei durante toda a carreira.

Se você tem uma experiência diferente, por favor, compartilhe aqui nos comentários. Vamos tornar essa discussão uma troca de ideias rica e interessante.

Quer conferir outros artigos? Confira no blog da Massimus!

*Fonte: https://olhardigital.com.br/pro/noticia/por-que-apple-e-google-nao-exigem-mais-diploma-universitario-para-contratar/78144

**Fonte: https://epocanegocios.globo.com/Carreira/noticia/2018/10/empresas-brasileiras-dispensam-o-diploma-na-hora-de-contratar.html