PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Scrum

  • Pelo Prazer de Aprender – Parte 2

    Pelo Prazer de Aprender – Parte 2

    Uma boa aula nos leva para cima, numa diagonal que combina ação e validação. Ela valoriza a exploração em detrimento da decoreba. Requer gente ativa e até indisciplinada ao invés de passivos ouvintes. O artigo anterior apresentou um modelo de aprendizagem e um processo. Agora vamos conversar sobre a estrutura de um projeto de aprendizagem.

    Antes, porém, preciso responder a pergunta colocada no artigo anterior: Se a ideia é utilizar o Scrum como peça fundamental do modelo de aprendizagem, quem é o Dono do Produto? Esse papel, como o nome sugere, é fundamental. Ele é o dono do que será criado pelo projeto. É o maior INTERESSADO em sua eficácia. Colocando assim, ficou mais fácil? Pois é, o Dono é o próprio ALUNO¹.

    Porque é ele quem tem um problema a resolver. Por exemplo: iniciar uma carreira de analista de negócios; desenvolver requisitos; gerenciar projetos; escrever um livro; programar em Python; tocar violão em festinhas; preparar pratos típicos da cozinha mineira; dançar cumbia e salsa; fabricar cervejas; cultivar frutas e ervas; desenhar negócios; pensar sistemicamente; elaborar projetos de aprendizagem… Exagero para mostrar a flexibilidade do modelo proposto.

    Todos os exemplos acima são Trabalhos a Executar² (JTBD?—?Jobs to be Done). Um bom projeto de aprendizagem mira um trabalho específico. Elaborado como na figura ao lado. O quê é colocado como um verbo + substantivo. A motivação deve ser clara.

    Delimitado o trabalho a executar, podemos iniciar o desenho da aula. No primeiro estágio detalhamos dos RESULTADOS DESEJADOS. Sem reinventar rodas, falamos em conhecimentos, habilidades e atitudes. Nos preparamos para: “eu não sei/não conheço”, “eu não sei fazer”, “eu não quero fazer”.

    Essa divisão é tão crucial quanto mal entendida³. Existem aulas puramente teóricas, chatas pra chuchu. E outras aparentemente divertidas, repletas de atividades. São rasas e frouxas ao desconsiderar os princípios, conceitos e histórias que dão sustentação para as ferramentas e métodos aplicados.

    Provas, Testes e Avaliações

    O segundo estágio é formado pelas EVIDÊNCIAS: Como os alunos poderão demonstrar o que aprenderam? Como eles farão uma auto-avaliação? Quais critérios e formatos de avaliação são mais adequados? Eles apontam, de forma inequívoca, para a realização dos Resultados Desejados?

    Pois é, estamos pensando nas “provas” antes mesmo de elaborar a aula propriamente dita. Trata-se de uma inversão do processo tradicional. Como antecipei no artigo anterior, essa sugestão é parecida com um método de desenvolvimento de sistemas chamado TDD (Test-Driven Development). O modelo?—?esse jeito de pensar?—?nos ajuda a elaborar aulas mais objetivas.

    O Plano de Aprendizagem

    Aqui detalhamos e sequenciamos todas as exposições e atividades necessárias para a realização dos objetivos colocados. Seguindo o Scrum, também é aqui que fixamos os fidbeques: Revisão e Retrospectiva.

    Os Planos de Aprendizagem não têm um padrão pré-determinado. Aliás, é importante que se diga que a proposta aqui apresentada não é prescritiva. Trata-se apenas de um modelo. As aulas serão muito diferentes, não apenas devido ao tema/Trabalho a Executar. Uma aula no nível Shu (Abrace), por exemplo, não tem nada a ver com as aulas nos níveis seguintes, Ha (Solte) e Ri (Deixe Voar).

    Pense comigo: o aluno tem um Trabalho a Executar. Ele vê, lá no primeiro estágio, tudo o que precisa conhecer e saber fazer. E entende, através das evidências, como está evoluindo. Sendo assim, ele saberá avaliar quando uma teoria ou prática não estiver agregando nenhum valor. E cobrará?—?para nosso deleite enquanto instrutores?—?por mais daquilo que o faz aprender e avançar.

    Sobre o Modelo

    A proposta deriva do Design Reverso ( Backwards Design ou Understanding by Design®). Ele é um modelo de planejamento curricular apresentado por Grant Wiggins e Jay McThyge em livro homônimo (ACSD?—?Association for Supervision and Curriculum Development, 2005). Sua combinação com o conceito de Trabalhos a Executar (JTBD) se justifica porque miro o público adulto e profissional. Isso não consta do modelo original, assim como a mistura com o Scrum.

    A peça fundamental do modelo é chamada UNIDADE. Prefiro o termo AULA. Pense nelas como peças de Lego®. Através delas podemos montar oficinas e cursos dos mais variados. Veja a oficina FAN, por exemplo. Ela contempla oito Trabalhos a Executar?—?ou seja, oito aulas. Cada uma tem seus objetivos, evidências e plano. O conjunto mira um alvo maior: a formação de analistas de negócios.

    Eu poderia falar mais sobre a flexibilidade e coesão lógica do modelo?—?seu desenho fractal. Desnecessário. Resta, então, a última questão. Sabe qual método utilizamos para desenvolver as aulas? O mesmo que aplicamos para conduzi-las: Scrum!

    Reclame

    Fluxo + ShuHaRi + Scrum + JTBD + Design Reverso

    Essas são as 5 peças principais que apresento na OPA! Oficina de Projetos de Aprendizagem. Resultado de mais de 10 anos rodando o Brasil, aprendendo a ensinar. Um resumo está disponível no Youtube.

    Notas

    1. Se você pretende lidar com crianças e pré-adolescentes talvez questione a posição deles como DONOS. Afinal, eles sabem o que precisam aprender? Desconfio que, do jeito deles, sabem mais do que muitos adultos.
    2. JTBD (Jobs to be Done) é um conceito/ferramenta proposto por Clayton Christensen e articulado em vários de seus trabalhos, particularmente no último: Competing Against Luck ( HarperBusiness, 2016). Eu abuso da ideia. Tem gente que não gosta da sugestão de ver tarefas como trabalhos. Perdem a chance de tirar o máximo da ferramenta.
    3. Algumas disciplinas parecem ser essencialmente teóricas. Filosofia, por exemplo. Quer ver como uma aula de filosofia pode ser prática e divertida? Não perca a excelente série catalã Merlí, disponível no Netflix. A segunda temporada acaba de ser liberada.
    4. Outro Indiana Quilt ilustra o artigo. Também compartilhado pela Biblioteca Pública de Allen County (IN).
  • Pelo Prazer de Aprender – Parte 2

    Pelo Prazer de Aprender – Parte 2

    Uma boa aula nos leva para cima, numa diagonal que combina ação e validação. Ela valoriza a exploração em detrimento da decoreba. Requer gente ativa e até indisciplinada ao invés de passivos ouvintes. O artigo anterior apresentou um modelo de aprendizagem e um processo. Agora vamos conversar sobre a estrutura de um projeto de aprendizagem.

    Antes, porém, preciso responder a pergunta colocada no artigo anterior: Se a ideia é utilizar o Scrum como peça fundamental do modelo de aprendizagem, quem é o Dono do Produto? Esse papel, como o nome sugere, é fundamental. Ele é o dono do que será criado pelo projeto. É o maior INTERESSADO em sua eficácia. Colocando assim, ficou mais fácil? Pois é, o Dono é o próprio ALUNO¹.

    Porque é ele quem tem um problema a resolver. Por exemplo: iniciar uma carreira de analista de negócios; desenvolver requisitos; gerenciar projetos; escrever um livro; programar em Python; tocar violão em festinhas; preparar pratos típicos da cozinha mineira; dançar cumbia e salsa; fabricar cervejas; cultivar frutas e ervas; desenhar negócios; pensar sistemicamente; elaborar projetos de aprendizagem… Exagero para mostrar a flexibilidade do modelo proposto.

    Todos os exemplos acima são Trabalhos a Executar² (JTBD?—?Jobs to be Done). Um bom projeto de aprendizagem mira um trabalho específico. Elaborado como na figura ao lado. O quê é colocado como um verbo + substantivo. A motivação deve ser clara.

    Delimitado o trabalho a executar, podemos iniciar o desenho da aula. No primeiro estágio detalhamos dos RESULTADOS DESEJADOS. Sem reinventar rodas, falamos em conhecimentos, habilidades e atitudes. Nos preparamos para: “eu não sei/não conheço”, “eu não sei fazer”, “eu não quero fazer”.

    Essa divisão é tão crucial quanto mal entendida³. Existem aulas puramente teóricas, chatas pra chuchu. E outras aparentemente divertidas, repletas de atividades. São rasas e frouxas ao desconsiderar os princípios, conceitos e histórias que dão sustentação para as ferramentas e métodos aplicados.

    Provas, Testes e Avaliações

    O segundo estágio é formado pelas EVIDÊNCIAS: Como os alunos poderão demonstrar o que aprenderam? Como eles farão uma auto-avaliação? Quais critérios e formatos de avaliação são mais adequados? Eles apontam, de forma inequívoca, para a realização dos Resultados Desejados?

    Pois é, estamos pensando nas “provas” antes mesmo de elaborar a aula propriamente dita. Trata-se de uma inversão do processo tradicional. Como antecipei no artigo anterior, essa sugestão é parecida com um método de desenvolvimento de sistemas chamado TDD (Test-Driven Development). O modelo?—?esse jeito de pensar?—?nos ajuda a elaborar aulas mais objetivas.

    O Plano de Aprendizagem

    Aqui detalhamos e sequenciamos todas as exposições e atividades necessárias para a realização dos objetivos colocados. Seguindo o Scrum, também é aqui que fixamos os fidbeques: Revisão e Retrospectiva.

    Os Planos de Aprendizagem não têm um padrão pré-determinado. Aliás, é importante que se diga que a proposta aqui apresentada não é prescritiva. Trata-se apenas de um modelo. As aulas serão muito diferentes, não apenas devido ao tema/Trabalho a Executar. Uma aula no nível Shu (Abrace), por exemplo, não tem nada a ver com as aulas nos níveis seguintes, Ha (Solte) e Ri (Deixe Voar).

    Pense comigo: o aluno tem um Trabalho a Executar. Ele vê, lá no primeiro estágio, tudo o que precisa conhecer e saber fazer. E entende, através das evidências, como está evoluindo. Sendo assim, ele saberá avaliar quando uma teoria ou prática não estiver agregando nenhum valor. E cobrará?—?para nosso deleite enquanto instrutores?—?por mais daquilo que o faz aprender e avançar.

    Sobre o Modelo

    A proposta deriva do Design Reverso ( Backwards Design ou Understanding by Design®). Ele é um modelo de planejamento curricular apresentado por Grant Wiggins e Jay McThyge em livro homônimo (ACSD?—?Association for Supervision and Curriculum Development, 2005). Sua combinação com o conceito de Trabalhos a Executar (JTBD) se justifica porque miro o público adulto e profissional. Isso não consta do modelo original, assim como a mistura com o Scrum.

    A peça fundamental do modelo é chamada UNIDADE. Prefiro o termo AULA. Pense nelas como peças de Lego®. Através delas podemos montar oficinas e cursos dos mais variados. Veja a oficina FAN, por exemplo. Ela contempla oito Trabalhos a Executar?—?ou seja, oito aulas. Cada uma tem seus objetivos, evidências e plano. O conjunto mira um alvo maior: a formação de analistas de negócios.

    Eu poderia falar mais sobre a flexibilidade e coesão lógica do modelo?—?seu desenho fractal. Desnecessário. Resta, então, a última questão. Sabe qual método utilizamos para desenvolver as aulas? O mesmo que aplicamos para conduzi-las: Scrum!

    Reclame

    Fluxo + ShuHaRi + Scrum + JTBD + Design Reverso

    Essas são as 5 peças principais que apresento na OPA! Oficina de Projetos de Aprendizagem. Resultado de mais de 10 anos rodando o Brasil, aprendendo a ensinar. Um resumo está disponível no Youtube.

    Notas

    1. Se você pretende lidar com crianças e pré-adolescentes talvez questione a posição deles como DONOS. Afinal, eles sabem o que precisam aprender? Desconfio que, do jeito deles, sabem mais do que muitos adultos.
    2. JTBD (Jobs to be Done) é um conceito/ferramenta proposto por Clayton Christensen e articulado em vários de seus trabalhos, particularmente no último: Competing Against Luck ( HarperBusiness, 2016). Eu abuso da ideia. Tem gente que não gosta da sugestão de ver tarefas como trabalhos. Perdem a chance de tirar o máximo da ferramenta.
    3. Algumas disciplinas parecem ser essencialmente teóricas. Filosofia, por exemplo. Quer ver como uma aula de filosofia pode ser prática e divertida? Não perca a excelente série catalã Merlí, disponível no Netflix. A segunda temporada acaba de ser liberada.
    4. Outro Indiana Quilt ilustra o artigo. Também compartilhado pela Biblioteca Pública de Allen County (IN).
  • Pelo Prazer de Aprender

    Pelo Prazer de Aprender

    Lembre-se de uma aula muito boa. O que a tornou inesquecível? Um professor atencioso e conhecedor, com certeza. A turma, interessada e entrosada, ajudou. Assim como a sala, arejada em todos os sentidos. Falta um último ingrediente. Qual?Oras, a aula propriamente dita. É possível que você nem tivesse interesse pelo tema. Mas a forma como ele foi exposto te pegou. É fácil dar todo o crédito da experiência ao talento do mestre, sua didática e paciência. Não vamos desmerecer isso. Mas tente se lembrar da organização do conteúdo. Nosso cérebro tem uma quedinha por estrutura, por hierarquia. Memorizamos melhor as ideias bem elaboradas¹. Posso apostar: a aula que te agradou era bem estruturada e fluiu de maneira lógica e natural. Você cresceu com ela. Mal viu o tempo passar. E ficou com um gostinho de “quero mais”. Como criar experiências assim?

    “Domine a música. Domine o instrumento.
    Agora, esqueça essa baboseira toda e apenas toque.”
    – Charlie “Bird” Parker

    Bird ajudou a reinventar o jazz e ensinou muita gente. Não há registro de que tenha estudado aikidô ou qualquer outra arte marcial japonesa. Mas sua dica fundamental, citada acima, parece uma versão bebop do ShuHaRi. O ShuHaRi é um conceito, um modelo que descreve estágios de aprendizagem². Voltando à questão acima: para criar uma boa experiência, começamos pela adoção de um modelo de aprendizagem. O nosso é um jazz de kimono:Shu: abrace, cuide do aprendiz. Apresente os fundamentos – a teoria e os movimentos básicos. E cobre disciplina e respeito pelas fronteiras estabelecidas. Que o aluno “domine a música”.

    Ha: solte e incentive a prática. Entenda que o aprendiz vai errar e quebrar a cara inúmeras vezes. É parte indissociável da aprendizagem eficaz. Mas entenda e aponte os erros – o fidbeque é fundamental. O aluno precisa “dominar o instrumento” (ferramentas e métodos). A indisciplina, a quebra de regras, atesta a evolução. Ri: sorria, você acaba de perder um aluno. Deixe-o voar. Ele não é mais um aprendiz, é seu colega. Como você, “esqueceu essa baboseira toda e agora apenas toca”. Aliás, ele imagina, cria e inova. Veja só que curioso: os três últimos verbos do parágrafo anterior sugerem o caminho inverso da diagonal ShuHaRi. Em fluxo desenhado por Ken Robinson em Libertando o Poder Criativo (HSM, 2012). Se parece também com o Funil do Conhecimento, conceito apresentado por Roger Martin em Design de Negócios (Campus, 2010). Neste caso, os termos são: Palpites, Heurística e Algoritmo. O que isso significa?Pode até ser que alguém atinja um ponto notável de aprendizagem e não queira retribuir. Vai ficar imaginando solos a la Coltrane e tocando escondidinho, para o próprio deleite, num sótão qualquer. Desconfio que a grande maioria das pessoas queira outro destino para suas ideias. São elas que vão imaginar cenários, criar soluções e botar pra rodar ou quebrar. O prazer em jogo é dobrado: primeiro, ao aprender; depois, ao ver sua criação espalhada por aí.

    E assim, falando de prazer, reencontramos o ponto do artigo anterior: o FLUXO. A diagonal em mão dupla o representa. Chega a hora de um precioso alerta: a diagonal não é uma linha reta. Esse raciocínio linear, faseado, trava e detona os modelos de ensino tradicionais. A melhor imagem para o FLUXO é uma espiral. Cada giro representa valiosos ciclos de fidbeque. Hora de falar sobre o Scrum.

    Scrum

    Antes de ser um “framework para o gerenciamento de projetos ágeis”, o Scrum é um modelo de aprendizagem. Foi por azar, muito azar, que ele foi parar em nossas mãos, profissionais de projetos e de TI. Ficou bitolado. Quem conhece o trabalho de seus pais biológicos, Takeuchi e Nonaka, vai entender o que estou falando. Eles são especialistas em Gestão do Conhecimento. Quando registraram o Scrum³, no distante 1986, pretendiam mostrar como empresas japonesas aprendiam melhor que as ocidentais. Não aprendiam mais e nem mais rápido: aprendiam melhor! É uma questão de eficácia, muito mais do que de eficiência. É mais qualitativa do que quantitativa. Parafraseando Ackoff de novo: “é melhor fazer a coisa certa do jeito errado do que fazer a coisa errada do jeito certo”. Melhor ainda é fazer a coisa certa de maneira eficiente. O Scrum tem um laço de fidbeque para cada questão.

    São dois  compromissos. O primeiro é a Revisão – mira a coisa certa, a eficácia. Os envolvidos avaliam o resultado de determinado esforço. Em nosso caso, uma aula, por exemplo. O aluno compreendeu de fato o que foi ensinado? Aprendeu a fazer?

    O segundo compromisso é a Retrospectiva – uma avaliação do processo, da eficiência. Por exemplo: em que o professor pode melhorar? Quais atitudes da turma devemos incentivar e quais devem ser evitadas? E por aí vai.

    Os dois compromissos ocorrem de forma consecutiva, ao término de um ciclo (Sprint na terminologia original). No nosso caso, o ciclo pode significar um tópico, uma aula ou módulo. Quanto menor, melhor.

    Quem conhece o Scrum pode estar se perguntando: peraí, como os papéis são distribuídos numa sala de aula? Quem é o PO (Product Owner – Dono do Produto)? O instrutor é o mestre – ScrumMaster. O Time é formado pelos alunos. Quem é o Dono? Você arrisca uma resposta?Na próxima semana concluo a trilogia “Hey! o que você tá esperando para se inscrever na OPA!?” Além de responder a questão acima, vou apresentar o terceiro pilar do modelo de aprendizagem, a Unidade. Ela se baseia, principalmente, no Understanding by Design®. Um modelo bem legal que, em conceito, é semelhante ao TDD (Test-Driven Development).

    Notas

    1. Brain Rules, John Medina (Pear Press, 2014).
      A Mente Organizada, Daniel J. Levitin (Objetiva, 2015).
    2. O modelo de aprendizagem (maturidade?) com três estágios vive ressurgindo com outros nomes e quase sempre sem crédito. Douglas Thomas e John Seely Brown, em A New Culture of Learning (Publicação independente, 2011), sugerem três etapas: Hanging Out, Messing Around e Geeking Out. Partiram de um estudo etnográfico sobre a interação de jovens com mídias sociais.
      Harold Stolovitch e Erika Keeps, em Telling Ain’t Training (ASTD, 2011), falam em Teach (Ensine), Prompt (Incentive) e Release (Libere). Como eu disse, variações da mesma sugestão apresentada neste artigo.
    3. The New New Product Development Game é o nome do artigo, publicado na Harvard Business Review em jan-fev/1986, que apresentou o Scrum. Não desconsidero nem desmereço o fato de Jeff Sutherland e Ken Schwaber terem dado uma cara e roupa nova para ele. Mas não me conformo com o desrespeito ao sentido original do Scrum. Por isso tem gente por aí que diz, por exemplo, que Retrospectivas são perda de tempo.
    4. Art Out of the Box 2009: Indiana Quilts é o nome da imagem no topo. Foi compartilhada no flickr pela Biblioteca Pública de Allen County (IN). O rabisco da molecada lembra muito o diagrama do FLUXO. Sincronicidade?
  • Pelo Prazer de Aprender

    Pelo Prazer de Aprender

    Lembre-se de uma aula muito boa. O que a tornou inesquecível? Um professor atencioso e conhecedor, com certeza. A turma, interessada e entrosada, ajudou. Assim como a sala, arejada em todos os sentidos. Falta um último ingrediente. Qual?Oras, a aula propriamente dita. É possível que você nem tivesse interesse pelo tema. Mas a forma como ele foi exposto te pegou. É fácil dar todo o crédito da experiência ao talento do mestre, sua didática e paciência. Não vamos desmerecer isso. Mas tente se lembrar da organização do conteúdo. Nosso cérebro tem uma quedinha por estrutura, por hierarquia. Memorizamos melhor as ideias bem elaboradas¹. Posso apostar: a aula que te agradou era bem estruturada e fluiu de maneira lógica e natural. Você cresceu com ela. Mal viu o tempo passar. E ficou com um gostinho de “quero mais”. Como criar experiências assim?

    “Domine a música. Domine o instrumento.
    Agora, esqueça essa baboseira toda e apenas toque.”
    – Charlie “Bird” Parker

    Bird ajudou a reinventar o jazz e ensinou muita gente. Não há registro de que tenha estudado aikidô ou qualquer outra arte marcial japonesa. Mas sua dica fundamental, citada acima, parece uma versão bebop do ShuHaRi. O ShuHaRi é um conceito, um modelo que descreve estágios de aprendizagem². Voltando à questão acima: para criar uma boa experiência, começamos pela adoção de um modelo de aprendizagem. O nosso é um jazz de kimono:Shu: abrace, cuide do aprendiz. Apresente os fundamentos – a teoria e os movimentos básicos. E cobre disciplina e respeito pelas fronteiras estabelecidas. Que o aluno “domine a música”.

    Ha: solte e incentive a prática. Entenda que o aprendiz vai errar e quebrar a cara inúmeras vezes. É parte indissociável da aprendizagem eficaz. Mas entenda e aponte os erros – o fidbeque é fundamental. O aluno precisa “dominar o instrumento” (ferramentas e métodos). A indisciplina, a quebra de regras, atesta a evolução. Ri: sorria, você acaba de perder um aluno. Deixe-o voar. Ele não é mais um aprendiz, é seu colega. Como você, “esqueceu essa baboseira toda e agora apenas toca”. Aliás, ele imagina, cria e inova. Veja só que curioso: os três últimos verbos do parágrafo anterior sugerem o caminho inverso da diagonal ShuHaRi. Em fluxo desenhado por Ken Robinson em Libertando o Poder Criativo (HSM, 2012). Se parece também com o Funil do Conhecimento, conceito apresentado por Roger Martin em Design de Negócios (Campus, 2010). Neste caso, os termos são: Palpites, Heurística e Algoritmo. O que isso significa?Pode até ser que alguém atinja um ponto notável de aprendizagem e não queira retribuir. Vai ficar imaginando solos a la Coltrane e tocando escondidinho, para o próprio deleite, num sótão qualquer. Desconfio que a grande maioria das pessoas queira outro destino para suas ideias. São elas que vão imaginar cenários, criar soluções e botar pra rodar ou quebrar. O prazer em jogo é dobrado: primeiro, ao aprender; depois, ao ver sua criação espalhada por aí.

    E assim, falando de prazer, reencontramos o ponto do artigo anterior: o FLUXO. A diagonal em mão dupla o representa. Chega a hora de um precioso alerta: a diagonal não é uma linha reta. Esse raciocínio linear, faseado, trava e detona os modelos de ensino tradicionais. A melhor imagem para o FLUXO é uma espiral. Cada giro representa valiosos ciclos de fidbeque. Hora de falar sobre o Scrum.

    Scrum

    Antes de ser um “framework para o gerenciamento de projetos ágeis”, o Scrum é um modelo de aprendizagem. Foi por azar, muito azar, que ele foi parar em nossas mãos, profissionais de projetos e de TI. Ficou bitolado. Quem conhece o trabalho de seus pais biológicos, Takeuchi e Nonaka, vai entender o que estou falando. Eles são especialistas em Gestão do Conhecimento. Quando registraram o Scrum³, no distante 1986, pretendiam mostrar como empresas japonesas aprendiam melhor que as ocidentais. Não aprendiam mais e nem mais rápido: aprendiam melhor! É uma questão de eficácia, muito mais do que de eficiência. É mais qualitativa do que quantitativa. Parafraseando Ackoff de novo: “é melhor fazer a coisa certa do jeito errado do que fazer a coisa errada do jeito certo”. Melhor ainda é fazer a coisa certa de maneira eficiente. O Scrum tem um laço de fidbeque para cada questão.

    São dois  compromissos. O primeiro é a Revisão – mira a coisa certa, a eficácia. Os envolvidos avaliam o resultado de determinado esforço. Em nosso caso, uma aula, por exemplo. O aluno compreendeu de fato o que foi ensinado? Aprendeu a fazer?

    O segundo compromisso é a Retrospectiva – uma avaliação do processo, da eficiência. Por exemplo: em que o professor pode melhorar? Quais atitudes da turma devemos incentivar e quais devem ser evitadas? E por aí vai.

    Os dois compromissos ocorrem de forma consecutiva, ao término de um ciclo (Sprint na terminologia original). No nosso caso, o ciclo pode significar um tópico, uma aula ou módulo. Quanto menor, melhor.

    Quem conhece o Scrum pode estar se perguntando: peraí, como os papéis são distribuídos numa sala de aula? Quem é o PO (Product Owner – Dono do Produto)? O instrutor é o mestre – ScrumMaster. O Time é formado pelos alunos. Quem é o Dono? Você arrisca uma resposta?Na próxima semana concluo a trilogia “Hey! o que você tá esperando para se inscrever na OPA!?” Além de responder a questão acima, vou apresentar o terceiro pilar do modelo de aprendizagem, a Unidade. Ela se baseia, principalmente, no Understanding by Design®. Um modelo bem legal que, em conceito, é semelhante ao TDD (Test-Driven Development).

    Notas

    1. Brain Rules, John Medina (Pear Press, 2014).
      A Mente Organizada, Daniel J. Levitin (Objetiva, 2015).
    2. O modelo de aprendizagem (maturidade?) com três estágios vive ressurgindo com outros nomes e quase sempre sem crédito. Douglas Thomas e John Seely Brown, em A New Culture of Learning (Publicação independente, 2011), sugerem três etapas: Hanging Out, Messing Around e Geeking Out. Partiram de um estudo etnográfico sobre a interação de jovens com mídias sociais.
      Harold Stolovitch e Erika Keeps, em Telling Ain’t Training (ASTD, 2011), falam em Teach (Ensine), Prompt (Incentive) e Release (Libere). Como eu disse, variações da mesma sugestão apresentada neste artigo.
    3. The New New Product Development Game é o nome do artigo, publicado na Harvard Business Review em jan-fev/1986, que apresentou o Scrum. Não desconsidero nem desmereço o fato de Jeff Sutherland e Ken Schwaber terem dado uma cara e roupa nova para ele. Mas não me conformo com o desrespeito ao sentido original do Scrum. Por isso tem gente por aí que diz, por exemplo, que Retrospectivas são perda de tempo.
    4. Art Out of the Box 2009: Indiana Quilts é o nome da imagem no topo. Foi compartilhada no flickr pela Biblioteca Pública de Allen County (IN). O rabisco da molecada lembra muito o diagrama do FLUXO. Sincronicidade?
  • Um Professor Acidental

    Um Professor Acidental

    “Se quiser que Deus dê umas boas gargalhadas, conte a Ele os seus planos.”
    – Woody Allen

    1987, terceiro ano do curso técnico em Processamento de Dados. O professor de informática divide a sala em duas e me delega todas as aulas práticas. No ano seguinte, já formado, eu tinha uma sala só minha, em outra escola. Curso noturno, com muita gente boa tão cansada quanto eu. Eu acumulava exército (tiro de guerra: 6h ~ 8h30), um trampo como programador numa empresa japonesa (9h ~ 17h) e o curso noturno. Aos domingos, pra descansar, apresentava o Clube do Rock numa rádio local.

    1993, o Brasil, como na década anterior, atravessava uma crise feia. Assumi a área de informática da Cooperativa Regional do Sul de Minas. Gerente? Que nada. O Atílio era digitador. Eu fazia todo o resto, de instalação de redes até análise e programação. E dava manutenção num legado Cobol mal escrito pra chuchu. DevOps de um homem só. De noite ia para a escola cuidar de outra turma de Processamento de Dados.

    1998, o país estava quebrado de novo. E eu precisava ganhar mais. Embarquei para Sampa, onde o salário médio era de três a quatro vezes maior do que no Sul de Minas. Dei alguns cursos de VB (que vergonha) e de Lógica de Programação (que orgulho) até arrumar um trampo como Gerente de Projetos. Foi acidente, eu era programador. Mas aquilo mudou tudo.

    2004, com um punhado de bons e maus projetos nas costas, lanço este finito. Ele nasceu para ancorar minha primeira pesquisa digna do nome: Aprendizado InterProjetos. Trabalho que foi selecionado para um evento do PMI. No ano anterior já havia palestrado no mesmo evento, falando sobre Engenharia de Requerimentos (sic¹).

    2005, encerra-se o ciclo paulistano com três anos de atraso. Tem início a “carreira solo”. Utilizando o modelo Lucro-Troco-Truco, decidi que serviços de consultoria ocupariam 70% de meu tempo (lucro). Cursos e palestras seriam o troco (20%). Como disse um colega-consultor-argentino, “nosso negócio é inviável”. E é mesmo. Em consultorias, para cada pequena vitória há um sem número de dissabores.

    2007, o FAN é lançado. Deveria ser troco – um chamariz para serviços mais polpudos. Mas aí vieram demandas da Oi, Net, Embraer, JBS Friboi, BrasilPrev, SoftPlan, Mercado Eletrônico, Linx, Gauge, Unisys e Bradesco, dentre outras. Caramba, de um porão em Varginha eu estava atendendo uma bela parcela do PIB tupiniquim! E em algumas turmas abertas cheguei a receber mais de 70 pessoas. O troco tinha virado lucro.

    2009, o FAN é incorporado a um curso de extensão da Federal de São Carlos. Alguns alunos disseram que foi “a melhor aula que já tiveram”. Um deles era mineiro, de Guaxupé, e desconfiei de nosso tradicional bairrismo. Estimulei, algum tempo depois, a adoção do Scrum para guiar todo o curso. Assim foi feito. Eu já fazia experiências similares nos meus próprios cursos.

    Aliás, foi nessa época que passei a me perguntar: Como ensinar? Aliás, como facilitar a  aprendizagem? Posso tornar o FAN e outras ofertas mais eficazes? Por que algumas turmas fluem muito bem e outras tropeçam? Não basta dominar o assunto. Nem ter uma didática aceitável. Passei a incorporar ensinamentos de Mel Silberman, Harold Stolovitch e outros². O Design Instrucional virou uma necessidade.

    2013, a complexidade crescente e a bagunça nas ruas – prenúncio de uma nova crise –  me levaram ao desenho do flit. Processo sem pressa. Afinal, era o primeiro truco³ em quase dez anos. O flit pedia por uma estrutura diferente – por algo que chamo Unidade Básica de Aprendizagem. Foi assim que descobri o Learning Object e, principalmente, o Understanding by Design®  (Design Reverso). O flit também pedia por um processo. E eu ganhei uma boa desculpa para finalmente adotar as ideias do húngaro Mihaly Csikszentmihalyi, principalmente seu Fluxo. Ele combina bem com o Scrum e outras propostas legais.

    2016, o flit não vingou (ainda). Pindorama, que surpresa, vive outra crise homérica. E uma ficha desaba: por que não vender a alma? Não a minha, mas a alma do flit. Ela é um sistema de aprendizagem completo. Por que não torná-la um produto por si só?

    Assim nasce a OPA! Oficina de Projetos de Aprendizagem. Devo confessar, temi que o novo produto parecesse um estranho no ninho finito. Até relembrar essa história toda e finalmente aceitar que, acidentalmente, estou virando um professor.

    Notas

    1. Pois é, eu ainda insistia no termo “Requerimentos”. Pouco depois, através do saudoso grupo CMM-br, aprendi que “Requisitos” era bem melhor.
    2. A bibliografia é imensa. Vou citar dois estopins: Active Training, de Mel Silberman (Wiley, 2015. Está na 4ª edição, comemorando aniversário de 25 anos!); e Telling Ain’t Training, de Harold Stolovitch e Erica Keeps (ASTD, 2011).
    3. Lucro-Troco-Truco é a versão tropicalizada do modelo 70-20-10 que, diz a lenda, guia o trabalho dos colaboradores da Google.
    4. Teaching é o título do rabisco acima. Executado e compartilhado por Daniel Friedman via flickr.
  • Planejando o Todo – Parte 2

    Planejando o Todo – Parte 2

    No último artigo começamos a ver o LogFrame (Logical Framework) e como ele pode apoiar um processo de planejamento. Hoje, além de completar a apresentação da ferramenta, veremos suas relações com o Design Idealizado de Ackoff e com propostas mais Pop, como o Scrum e o OKR (Objectives and Key Results).A matriz abaixo resume o artigo anterior.Das quatro questões fundamentais que o LogFrame ajuda a responder, resta uma: Como o trabalho será executado e por quem? Se a quebra dos artigos se deu por questão de espaço, ela foi conveniente. Porque nos permite sugerir que o plano, a partir de agora, muda de mãos. As pessoas que de fato vão trabalhar na realização (construção) dos produtos são as mais indicadas para dizer como pretendem fazê-lo.

    Mas, cuidado: “Quando sugerimos que há uma fronteira entre estratégia e táticas, estamos dispensando as pessoas de usar a cuca.” – Peter Morville, em Intertwingled (2014).

    O planejamento das atividades pode ser suportado pelo LogFrame como sugerido no quadro abaixo:O gráfico Gantt deve ter causado arrepios em alguns. É importante dizer que a imagem acima representa apenas uma das diversas opções que temos. Ela é detalhista ao quebrar atividades e tarefas. Pretende ser mais completa ao relacionar as pessoas envolvidas e o papel que cada uma terá. E abre espaço até para um orçamento por atividade/tarefa! Demasiadas minúcias em tempos de não-planejamento (aka XGH)?

    O fato é que o LogFrame é bastante flexível. Não atenderia aquele maluco que quer relacionar centenas de atividades a fim de (micro)gerenciá-las. O outro extremo – aquele que acha que não precisa pensar nem dizer como um produto será construído – também não verá utilidade na ferramenta. Todos entre os dois pólos podem se beneficiar do uso do LogFrame. Por quê?

    1. Ganham uma Visão do Todo, com uma relação clara e simples entre Fins e Meios;
    2. Aumentam o grau de comprometimento ao dar sentido para todo o trabalho a ser executado;
    3. Simplificam o processo de planejamento; e
    4. Facilitam a implementação e o controle de mudanças e projetos.

    LogFrame X Design Idealizado¹

    A lista acima foi elaborada por Russell Ackoff para ilustrar os “efeitos do Design Idealizado”. Ao utilizar o LogFrame para suportar o processo tentamos potencializar os efeitos. Como colocado anteriormente nesta série, processo e ferramenta nasceram em berços diferentes. Mas compartilham bases comuns, dentre elas o Pensamento Sistêmico. Não é coincidência o fato deles se completarem.

    LogFrame X Scrum

    O Scrum parte de uma visão pré-estabelecida. Quem trabalha com ele acaba “inventando” um jeito de construir a Visão. Vêm daí os incríveis sprints 0, -1 e sabe-se lá onde isso vai parar. Ainda é uma experiência, mas parece que LogFrame e Scrum também nasceram um para o outro.Ideal e objetivos fundamentam a Visão de um projeto. Da lista de Produtos derivamos os mapas (roadmaps) e backlogs. A partir da lista de atividades podemos planejar os Sprints. Atenção: não estamos criando mais um artefato. Estamos apenas reforçando o significado original de algumas peças do Scrum. Rastrear a mais singela tarefa até o grande Ideal, passando por produtos e objetivos, é característica inerente ao Scrum. Se o LogFrame e o Design Idealizado apenas forçarem tal lembrança já justificam o seu uso.

    LogFrame X OKR

    No artigo anterior coloquei que o LogFrame não é pop². O mesmo não pode ser dito de seus possíveis filhotes, particularmente o OKR³ (Objectives and Key Results). Inventado  nos anos 1970 na Intel, a sigla ganhou corações e mentes depois de ser responsabilizada por fazer o LinkedIn valer US$ 20 bilhões, por exemplo. Seria o framework gerencial padrão de empresas do Vale do Silício, dentre elas Google, Zynga e outras.

    Um apressado poderia dizer que o OKR é o LogFrame sem pé (atividades) nem cabeça (ideal). Com menos pressa ele entenderia que os objetivos do OKR derivam de declarações de “missão e visão” e que, a partir dos resultados chave esperados (e medidos tal e qual no LogFrame), os responsáveis montam seu plano de… atividades. Podemos concluir que LogFrame e OKR são a mesma coisa? Não, por uma pequena mas significativa diferença.

    No OKR você fixa objetivos e resultados trimestrais e anuais. Você começa a jogar com previsões – a brincar com o fogo do monstro do tempo. Tudo o que a gente quer evitar quando adota o Design Idealizado e seu co-irmão LogFrame.O prometido exemplo fica para a próxima semana, ok? Inté!

    Notas

    1. Passa da hora de decidir por um dos dois nomes do “processo do Ackoff”. Em alguns artigos optei por Processo Interativo. Neste comecei a achar que Design Idealizado é melhor. Design é mais pop, não?
    2. E por falar em tornar as coisas pop (como se isso fosse importante). Alguém sugeriu que LogCanvas seria promissor. Blergh!
    3. Marc Benioff, do SalesForce.com, também “inventou” um método de planejamento e alinhamento. Atende pelo nome de V2MOM. Talvez por isso não seja tão pop…
    4. Pop é o pato que enfeita todos os últimos episódios. Hoje ele está entre o ócio e a negação do ócio (negócio): l? cong?ttur? d? Arl?cch?no . . (?n-b?tw??n ot?um?n?got?um) Imagem de Jef Safi.
  • +Aprendizado sobre Requisitos

    +Aprendizado sobre Requisitos

    Foi sincera a questão que encerrou o capítulo anterior: o que viria a seguir? Por natural que pareça o tema que será desenvolvido nesta parte – aprendizado – não é comum vê-lo em trabalhos sobre requisitos. A exagerada compartimentalização de disciplinas que inventamos no século passado e, infelizmente, seguimos alimentando, deixa entender que conhecimento e aprendizagem organizacional ficam em um lado, requisitos ou engenharia de requisitos noutro. Divisão falsa e danosa. O aprendizado e desenvolvimento de requisitos é um tipo de aprendizagem organizacional. Em minha opinião, o mais importante deles. Porque é em projetos que geramos e disseminamos o maior número de novos conhecimentos.

    Para esta sequência precisamos recuperar duas citações do artigo anterior:

    De carona nas afirmações acima conclui que “requisito é conhecimento produzido por conhecimento”. Estamos falando de aprendizagem – aprendizagem organizacional. Como uma organização aprende? Como ela gera (produz) e dissemina conhecimentos¹?

    A resposta exige que saibamos que existem apenas dois tipos de conhecimentos²:

    • Tácito: pessoal, específico de um contexto, difícil de comunicar. Existe em duas dimensões:
      • Técnica: comumente identificado como know-how (saber como fazer);
      • Cognitiva: crenças, valores, ideais, percepções, emoções e modelos mentais.
    • Explícito: codificado, transmitido de maneira formal e sistemática.

    O conhecimento tácito reside nos corações e mentes das pessoas. É aquele que vai embora da empresa todo dia lá pelas cinco ou seis da tarde³. O explícito fica – persistido em documentos, sistemas, bancos de dados, pôsteres, mensagens em correios eletrônicos e redes sociais etc.

    A aprendizagem organizacional – a geração e disseminação de conhecimentos – se dá nas conversões de conhecimentos ilustradas no diagrama ao lado.

    Na socialização – de conhecimento tácito para tácito – a troca se dá através de conversas e da observação ou experiência direta, tête-à-tête. É como se inicia um processo de aprendizado. Aqui temos razoável largura de banda – quantidade de informações transmitidas. Por outro lado, temos também um problema de escalabilidade. Pense em uma reunião com dezenas ou centenas de pessoas. A eficácia do aprendizado via socialização é inversamente proporcional ao número de participantes.

    Ao sintetizar conhecimento tácito em explícito temos a externalização. Quando critico as verborrágicas especificações funcionais estou apontando para este quadrante. São notórias nossas dificuldades neste tipo de conversão de conhecimento. Mas não são novas. Diderot também penou bastante para transcrever naquela que seria nossa primeira enciclopédia um conhecimento que até então (circa 1750) era exclusivamente tácito. Ele queria explicar pelo menos o básico sobre todos os trabalhos artesanais da época. Descobriu que a observação ativa (para aprender) e as imagens (para explicar) eram as ferramentas mais eficazes. Hoje, no trabalho com requisitos, Diderot ainda tem muito a nos ensinar.

    A conversão de conhecimento explícito em outro formato explícito é o que acontece na combinação. É o que faz um desenvolvedor, por exemplo, quando parte de modelos e especificações para criar código. É importante entender que combinação é síntese – criação de um novo todo a partir de partes distintas – e não uma mera tradução de formatos (ou o fatídico e dispendioso passar a limpo). Na combinação não há conhecimento novo sendo gerado. Por isso cada conversão deste tipo deve ser avaliada com carinho. O produto da conversão deve ter inequívoco valor para alguém ou para a organização. Um modelo ou documento que só existe porque “a metodologia exige” é grana que escorreu pelo ralo.

    Por fim, temos a internalização – a conversão de conhecimento explícito em tácito. É o aprendizado que se dá a partir do que está escrito, desenhado ou registrado de alguma forma. Ao contrário da socialização, aqui temos grande potencial de escala (de atingir grande número de pessoas). Por outro lado, a banda não é tão larga – a quantidade de informações passíveis de transmissão é consideravelmente menor.

    Essas conversões não ocorrem de maneira isolada ou única. A sequência descrita acima acontece infinitas vezes dentro de uma organização, formando uma espiral. Pois é, a aprendizagem organizacional é naturalmente iterativa (iterar = repetir) e incremental (construída a partir dos produtos das etapas anteriores). Dá pra imaginar o espanto e desalento dos papas dessa matéria quando apresentados aos cansativos debates sobre processos plan-driven versus change-driven. Porque essa divisão não existe!

    O modelo SECI, nome do diagrama acima, não é uma proposta de processo ou método. É a conclusão de uma pesquisa²: é assim que as organizações aprendem, intencionalmente ou não. Reconhecer o modelo é o primeiro passo para uma conversa séria sobre aprendizagem organizacional e gestão do conhecimento.

    Sintetizando: Nós conversamos sobre necessidades e restrições com nossos usuários e clientes (socialização); Durante e depois das conversas nós transcrevemos parte daquele aprendizado – estruturando requisitos, redigindo especificações de casos de uso, rabiscando modelos etc. (externalização); Criamos outras derivações dos requisitos – como mockups, storyboards, protótipos ou versões alpha e beta – de forma a confirmar que todos os envolvidos compartilham o mesmo entendimento (combinação); o confronto com esse conhecimento explicitado na forma de modelos ou versões de um sistema (internalização) nos dá novas certezas e dúvidas – novas necessidades e restrições – sobre as quais vamos conversar, o que nos remete ao início deste parágrafo.

    Desta vez ficou fácil cravar o tema da próxima parte. Será sobre canais de comunicação e ferramentas sociais.
    Porque tudo começa na socialização. Até lá!

     

    Notas

    1. Conhecimento é uma das cinco dimensões de um sistema sociocultural (de uma empresa, por exemplo). Quando apresentei o tema na série anterior, Pensando Negócios, escrevi que são dois verbos – duas preocupações – que caracterizam a forma como uma organização trata cada dimensão. Os verbos são Gerar e Disseminar. Neste novo contexto eles podem ser trocados por apenas um: Aprender. Se o tema lhe interessa, recomendo a leitura das partes V e VI daquela série.
    2. Os pais do modelo aqui apresentado são Hirotaka Takeuchi e Ikujiro Nonaka. Recomendo dois trabalhos: Gestão do Conhecimento (Bookman, 2008) e Knowledge Management – Classic and Contemporary Works, coletânea de artigos compilada por Daryl Morey, Mark Maybury e Bhavani Thuraisingham (MIT Press, 2000). Os artigos clássicos de Takeuchi e Nonaka são de 1995/96. Um deles está neste último livro. Outro deu origem ao método conhecido como Scrum.
    3. Tenho quase certeza de que o autor original desta brincadeira foi Thomas Stewart, autor de outro livro fundamental sobre aprendizagem organizacional: Capital Intelectual (Campus, 1998).

     

     

  • Scaling Lean & Agile Development

    Scaling Lean & Agile Development

    Craig Larman e Bas Vodde

    A quem pode interessar: Todos que estejam levando métodos ágeis e o pensamento Lean para além de um produto, um projeto ou um time. Deve interessar a todos que já rodaram mais de dois experimentos com métodos ágeis, particularmente com o Scrum.

    Porque ler: Larman tem um histórico de livros que fizeram a cabeça de muita gente, aqui e lá fora. São dele “Utilizando UML e Padrões” (Bookman, 2007) e “Agile & Iterative Development: A Manager’s Guide” (Addison-Wesley, 2004). Seus escritos seguem consistentes e didáticos. Mas agora ele parece um pouco mais divertido e direto. Porque sabe que o sucesso de suas sugestões depende de opiniões claras – de conclusões que podem não agradar todo mundo. Este é um dos poucos títulos (sérios) sobre a utilização do Scrum em projetos de médio e grande portes.

    Estrutura & Conteúdo: O livro tem apenas duas grandes partes, Ferramentas de Pensamento e Ferramentas Organizacionais. Cada uma mereceu cinco capítulos. Os autores começam pegando pesado, citando Woody Allen (!) e falando sobre o Pensamento Sistêmico. Quem sempre se sentiu intimidado ou constrangido pelo “A Quinta Disciplina” de Peter Senge (Best Seller, 2009) sentirá imenso alívio ao ler o primeiro capítulo de “Scaling Lean & Agile Development”. Combinado ao pensamento Lean, o Pensamento Sistêmico é apresentado de forma extremamente prática e didática.

    Também merece destaque o segundo capítulo, sobre o Pensamento Lean. Não se trata de um derivado de outros escritos, mas de um trabalho de pesquisa que envolveu interações diretas dentro da própria Toyota no Japão. Não é por nada não, mas a dupla conseguiu explicar em um capítulo o que muita gente não fez em um livro inteiro! Fechando a primeira parte temos os seguinte capítulos: Teoria das Filas, Falsas Dicotomias e Seja Ágil.

    A segunda parte, sobre Ferramentas Organizacionais, apresenta sugestões um pouco mais controversas. Eu gostei demais de boa parte delas, mas sei que algumas pessoas virarão piruetas ao ler, por exemplo, que “organizações ágeis não precisam de Escritórios de Projetos (PMO’s)” (p. 249). Os autores dizem, no mesmo trecho, que pior que um PMO é a sugestão de um Agile PMO. Claro, não deixam de citar o pai da (indesejada) criança: Jochen Krebs, em “Agile Portfolio Management” (Microsoft Press, 2008). Acho que nem preciso dizer que também gostei muito da alternativa sugerida pela dupla para troca de conhecimentos e experiências: as Comunidades de Prática (p. 252).

    Aliás, o livro todo apresenta dois grandes conjuntos de sugestões (experimentos) etiquetados como “Try…” (Tente) e “Avoid…” (Evite). Uma lista com todas as sugestões aparece logo de cara, na terceira página. Todas são apresentadas e justificadas no decorrer do texto.

    Trechos (livremente traduzidos):

    “Evite… pensar que o gerenciamento de filas, kanban e outras ferramentas são pilares do Lean.”

    “Tente… refletir sobre os dois pilares do Lean: Respeito pelas Pessoas e Melhoria Contínua.”
    (N.T.: Reparou que “eliminar desperdício” também não pintou aqui? Acontece que certos “desperdícios temporários” são necessários. Um buffer com itens do backlog do produto, por exemplo).

    “Uma das mais ignoradas e valiosas sugestões do Scrum diz que algo entre cinco e dez porcento de cada Sprint deve ser dedicado pelo time ao refinamento do backlog do Produto.”

    “O último projeto simples foi feito em 1962. Não acredite que exista algum projeto que não envolva aprendizado ou complexidade ou alguma variabilidade e, consequentemente, não se beneficie do desenvolvimento ágil.”

    “Encoraje os especialistas a ensinar, não a fazer.”

    “Se não há conflito aparente então o time está com problemas.”

    “Evite… ferramentas tradicionais de gerenciamento de requisitos.”

    “Evite… organizações matriciais e escritórios de projetos.”

    “Evite… a IBM.”

    Serviço:

    Scaling Lean & Agile Development
    Craig Larman e Bas Vodde
    Addison-Wesley, 2009
    US$ 39,41 na Amazon (em 24/jan/12)
    US$ 15,92 pela versão eletrônica.

    ?

  • Scrum ‘de Raiz’

    Scrum ‘de Raiz’

    Assim como existem o samba e a música sertaneja ‘de raiz’, também existe um Scrum ‘de raiz’: ideias, princípios e práticas que antecederam e deram forma e jeito ao framework como é conhecido hoje. Ajornada antropológica proposta por este artigo tem como principais objetivos: i) Revisitar os pilares do Scrum; e ii) Descobrir se estamos esquecendo alguma coisa importante em nossos trabalhos com ele. Posso adiantar: estamos!

    ?

    O Scrum foi provocado pelo artigo “The New New Product Development Game” publicado na edição de Jan-Fev/1986 da Harvard Business Review (HBR). Escrito por Hirotaka Takeuchi e Ikujiro Nonaka, o artigo descreve o sucesso de empresas como Fuji-Xerox, Honda e Canon no desenvolvimento de novos produtos. Os autores descobriram que as empresas analisadas compartilhavam seis características fundamentais:

    1. Instabilidade intencional: os times de projetos recebem apenas uma diretriz geral, normalmente uma metáfora indicando o tipo de produto que a organização espera receber. Não existem especificações detalhadas ou plano de projeto. Tensão, pressão, ambiguidade e outros efeitos colaterais da prática são compensadas por tolerância aos erros e pela autonomia concedida ao time.
    2. Times auto-organizados: a autonomia, citada acima, é uma das três condições para a criação de um time auto-organizado. Auto-transcendência (equipe parece buscar algo além de seu limite normal) e fertilização cruzada (time é multifuncional e todos aprendem com todos) são as outras duas.
    3. Fases sobrepostas de desenvolvimento: como em um jogo de rúgbi, onde todos correm juntos e passam a bola lateralmente. A metáfora oposta é a corrida de revezamento (desenvolvimento sequencial ou linear), com um participante aguardando a passagem do bastão por outro.
    4. “Multi-aprendizado”: ocorre o aprendizado multiníveis (indivíduo, time e empresa aprendem) e o aprendizado multifuncional (fruto da fertilização cruzada, citada acima. Um especialista é provocado a aprender coisas de outras áreas).
    5. Controle sutil: a autonomia de um time não significa falta de controle, apenas um tipo diferente de gerenciamento.
    6. Transferência do aprendizado: o item 4 acima trata do aprendizado que ocorre entre as partes interessadas de um projeto específico. Aqui se trata do aprendizado interprojetos e também da transferência da e para a organização.

    A derivação da lista acima que hoje conhecemos como Scrum, criada por Jeff Sutherland e Ken Schwaber, parece dar ênfase aos itens 2~5 em detrimento do primeiro e último tópicos. Jim Highsmith, mesmo sem dar nome ao boi, sugere algumas correções (ou avanços) no já comentado “Agile Project Management“. Craig Larman e Bas Vodde, em “Scaling Lean & Agile Development” (Addison-Wesley, 2009) tentam o mesmo. Apesar de valiosas, essas colaborações não são suficientes.

    Enquanto o Scrum era gestado, Takeuchi e Nonaka prosseguiram com suas pesquisas no campo da Gestão do Conhecimento¹. Do segundo a mesma HBR publicou, na edição Nov-Dez/1991, “The Knowledge-Creating Company“. Em 1995 a dupla voltou com outro artigo seminal, “The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation“. Por mais que a estagnação da economia japonesa – que já dura duas décadas – tente provar o contrário, esses artigos não poderiam ter sido ignorados como aparentemente foram (pelos “criadores” do Scrum e demais envolvidos com métodos ágeis). Porque eles recolocam e evoluem os temas tratados no trabalho original de 1986.

    A crítica sem rodeios nem meias palavras ao jeito ocidental – cartesiano e taylorista – de ver as organizações talvez explique o fato desses artigos terem passado em branco. Mas é exatamente nesta crítica que está seu grande valor. O tal ‘jeito ocidental’ vê as empresas como “mecanismos para processamento de informações”. Nonaka explica:

    “De acordo com essa visão, o único conhecimento verdadeiramente útil é o formal e sistemático – dados difíceis² (leia-se quantificáveis), procedimentos codificados, princípios universais. E as métricas-chave para mensurar o valor do novo conhecimento são similarmente difíceis e quantificáveis – crescente eficiência, custos mais baixos, melhor retorno do investimento (ROI).”

    Por outro lado, no modo oriental (ou japonês):

    1. Há reconhecimento e valorização do conhecimento tático;
    2. A questão não se limita a “gerenciar conhecimentos” mas, principalmente CRIAR conhecimentos;
    3. Entende que todos os colaboradores, e não apenas os gerentes e diretores, são potenciais criadores de novos conhecimentos; e
    4. Recursos e atividades são organizados e desenhados de forma a facilitar a criação e transferência de conhecimentos.

    Voltemos a um ponto chave que deixei um tanto solto acima: a área de especialização de Takeuchi e Nonaka é a Gestão (ou Criação) de Conhecimentos. Eles entendem que cada projeto é uma oportunidade única para criação de conhecimentos (leia-se Inovação). Por isso depositam boa parte de suas sugestões nas trocas e transformações de conhecimentos. O Scrum, até certo ponto, reflete bem a mesma preocupação. Através de suas reuniões diárias, de revisão (de iterações ou sprints) e retrospectivas. Mas ele peca ao desconsiderar ou dar pouca importância ao que existe fora do time de projeto.

    Takeuchi e Nonaka descobriram um tipo de organização que chamaram “hipertexto”. Convivência, confronto e troca entre a estrutura hierárquica (sistemas de negócios) e times de projetos (forças-tarefa) dão forma a uma “hiper-rede”. Uma rede que não se desliga nunca! Por que isso é importante e muito diferente do que vemos no Scrum?

    O Scrum instituiu um e apenas um ponto de contato (ou interface) entre negócio (estrutura hierárquica) e time de projeto: o Dono do Produto. Se por um lado esse “mecanismo” simplificou o processo de comunicação, por outro ele destruiu a permeabilidade e transparência que existem na proposta original da dupla japonesa. Repare no diagrama ao lado. Times de projetos e o negócio se comunicam constantemente. E essa comunicação não se dá através de um “ponto focal”. Acontece que os times são de fato multidisciplinares, compostos por pessoas de todas as áreas de negócio envolvidas. Takeuchi e Nonaka chegam a falar de times com 20~30 pessoas e um “núcleo duro” de 5 integrantes. Essas 15~25 pessoas “extras” são gente do negócio atuando na força tarefa. Gente que “leva e traz”, no bom sentido, o conhecimento necessário.

    Por favor, não estou sugerindo que a figura do Dono do Produto é desnecessária e muito menos que ela seja redondamente equivocada. Mas precisamos aceitar que ela é um “ponto único de falha” nesse sistema chamado Scrum. Suas vantagens (particularmente a esperada agilidade na tomada de decisões) não a livra de um risco potencial: a falta de conhecimento.

    Existem ainda outros dois fatores que diferenciam essa proposta do Scrum. Os times, apesar de levemente acoplados, mantêm comunicação constante. Sei que isso começou a ser tratado quando pipocaram questionamentos sobre a escalabilidade do Scrum. Aquele papo sobre “Scrum de Scrums” e coisa e tal. O fato é que esse patch não seria necessário se o desenho original³ fosse preservado. O segundo fator é a “Base de Conhecimentos”: aqui temos todo o conhecimento explícito acumulado a cada projeto. A ênfase no conhecimento tácito (e na comunicação direta entre times de projetos e o negócio) não significa o desmerecimento de tudo o que pode e deve ser explicitado (e documentado).

    Resumindo, eu vejo dois grandes problemas no Scrum que não existiriam caso seguíssemos acompanhando os trabalhos de Takeuchi e Nonaka:

    1. O “sistema” original é completo. Ele entende que quem cria conhecimentos são os indivíduos mas quem os amplifica é a organização. Times de projetos são sintetizadores desse conhecimento. O Scrum não pode ignorar ou tratar de forma simplista essas trocas;
    2. A ênfase em dados “duros” e conhecimento explícito (e mensurável) é a prorrogação de uma mentalidade herdada do século XX, de Taylor, Ford e afins. Um pensamento que desemboca em um absurdo que vi na forma de um cartaz no último Agile Vale realizado em São José dos Campos: “Se o miojo fosse ágil ficaria pronto em um minuto e meio”. O Scrum, lá na sua raiz, nunca prometeu a agilidade pela agilidade. Nunca foi uma questão de fazer de maneira ultra-rápida o mesmo trabalho. A busca cega por eficiência está nos desviando de forma muito preocupante do que é fundamental: fazer a coisa certa!

    ?

    Observações:

    1. Os dois artigos citados, de 1991 e 95, podem ser encontrados em “Gestão do Conhecimento“, de Hirotaka Takeuchi e Ikujiro Nonaka (Bookman, 2008). Aproveito a deixa para recomendar outro livro, mais completo, que apresenta a versão original (em inglês) do segundo artigo: “Knowledge Management: Classic and Contemporary Works“, editado por Daryl Morey, Mark Maybury e Bhavani Thuraisingham (The MIT Press, 2000).
    2. Ana Thorell, tradutora do primeiro livro acima, optou por “difícil” ao traduzir “hard”. Mantive a tradução original mas, logo abaixo, falei de “dados ‘duros’”. Não sei qual ficou pior.
    3. Assim como não sei se Takeuchi e Nonaka têm noção do belo monstro que ajudaram a criar, o tal de Scrum. É importante lembrar, antes que levem a culpa por alguma coisa, que eles não tinham a intenção de criar um framework para gerenciamento de projetos ágeis. Miravam a lua. É importante que nossos tiros, a partir do momento que são cópias ou derivações, não se contentem em atingir apenas o topo da montanha.
    4. “Tree-in-Pot” é o nome do cartoon de hoje. Pra variar, do HikingArtist.

     

  • UMA Resumida e outros Desabafos

    UMA Resumida e outros Desabafos

    Necessária revisão dos últimos artigos publicados. Motivadas por alguns comentários? Sim, mas principalmente pela falta de comentários. Uma breve introdução tentará justificar os “desabafos”. Na sequência, a reapresentação dos últimos artigos utilizando uma perspectiva um pouco diferente.

    ?

    Scientia Interruptus

    Triste verdade: no processo de construção de conhecimento, o {finito} é interrompido em 1/3 do caminho. Porque praticamente não há diálogo algum acontecendo. Agradeço demais as reações, retweets e os poucos comentários que aparecem. Mas eles raramente representam uma conversa construtiva – raramente agregam conhecimento novo. As poucas críticas, particularmente as mais recentes, utilizam um tom e uma agressividade que impedem qualquer tipo de interação civilizada. Ou então simplesmente detonam uma ideia sem propor nada em troca. É o malho pelo gosto do malho, puro e simples. Como esta casa é minha, eu poderia simplesmente eliminá-los. Opto por mantê-los porque não aprovo nenhum tipo de censura¹. Mas também na vã esperança de que reações extremadas incentivem novas discussões. Por enquanto, não funcionou.

    Queria um dia entender todo esse consumo passivo de informações em pleno século XXI, na era da interatividade. Desconfio que minha redação e meu “estilo” não sejam muito convidativos. Desconfio também que alguns temas simplesmente não merecem um dedo de prosa. Erros exclusivamente meus que vivo tentando corrigir. Mas, por enquanto, é apenas isso que tenho: desconfianças. Porque nem retorno sobre elas eu tenho. E não vou fazer “pesquisinhas” porque não acredito nelas. Pesquisa não é conversa. Pesquisas não substituem conversas.

    Meus artigos são teses. Mesmo quando desastrados, são convites para um bate papo. Antíteses são esperadas. Elas não precisam, necessariamente, negar toda a tese apresentada. Mas, obrigatoriamente, deveriam agregar valor – jogar conhecimento novo no ventilador. Só então seria possível uma SÍNTESE, que simploriamente descrevo como uma combinação do melhor da tese com o melhor das “anti-teses”. Por isso falei que o {finito} é interrompido em 1/3 do caminho da criação de bom conhecimento. Ele praticamente morre nas teses. Por exemplo…

    Arquitetura Lean & Ágil

    Uma das duas críticas apresentadas ao último artigo, UMA Modesta Arquitetura, dizia que aquele era papo de “viado, charlatão, chefe com desejo de ser superstar etc”. Mesmo com a melhor das boas vontades eu não conseguiria compor algo novo a partir de tão grosseira reação. Mas esta e outra crítica acertaram em um ponto: aquele artigo ficou longo demais. Apelarei para o outro extremo e tentarei resumi-lo no parágrafo abaixo.

    A arquitetura dos sistemas de uma organização deveria refletir exatamente aquele negócio. Quando olhamos para a arquitetura de um negócio vemos três grandes conjuntos: Objetivos, Estrutura e Processos. Nossos sistemas deveriam respeitar essa organização. Para: i)Viabilizar o uso de um vocabulário comum; ii) Separar aquilo que muda muito (processos) daquilo que muda menos (estrutura); e assim iii) Garantir a agilidade e flexibilidade requeridas em tempos de mudanças e hipercompetitividade. A proposta DCI (Data-Context-Interaction) vai exatamente neste caminho, de separação nítida entre forma e funcionalidades de um sistema. Na distinção entre o que o sistema É e o que o sistema FAZ. Sem saber (ou sem citar), esta proposta também combina com uma leitura recente da Teoria da Complexidade que sugere a separação do que desafia nosso entendimento (estrutura) daquilo que desafia nossa habilidade de prever (comportamento). Três campos (ou domínios) – arquitetura do negócio, arquitetura de software e teoria da complexidade – parecem sinalizar UMA visão unificada. Ainda modesta, mas bastante promissora.

    Gastei três mil e tantas palavras para explicar e detalhar o que descrevo no parágrafo acima. Acho que pequei pelo excesso e pelas redundâncias. Minha intenção única e exclusiva foi mostrar bases e origens de cada uma das três áreas que parecem pedir por uma leitura unificada. Mas este problema, o tamanho do artigo, é quase insignificante quando comparado com uma famosa sugestão contrária ao DCI.

    Intencionalmente deixei de citar uma proposta que parece bater literalmente de frente com as sugestões de Trygve Reenskaug, James Coplien e Gertrud Bjørnvig. O DCI sugere a criação de um “Modelo Anêmico”, um anti-padrão (anti-pattern) arquitetônico documentado por Martin Fowler nos idos de 2003. Ok, tenho certeza de que esta última frase não está correta. Mas eu fiz vista grossa para o escancarado conflito exatamente para receber reações e desafios. Se minha memória não me engana, Coplien também ignora o anti-pattern no livro “Lean Architecture“. Não me interessam mais os debates que acontecem lá fora. Queria ver assunto tão caro em agendas e grupos de discussão tupiniquins. Combustível não falta. Coplien, por exemplo, disse que “SOA is Dead!” Não me preocupa a acusação de charlatanismo. Mas a falta de debate é assustadora.

    Scrum “de raiz”

    A pequena série “Sistema de Blindagem Inteligente” (partes 1 e 2) também mereceu uma crítica. A colega Nara disse não ter visto “nada de extraordinário” em minha proposta. Eu não havia prometido nada do tipo. Mas temo ter desperdiçado a oportunidade de uma boa conversa. Temo que ela tenha entendido que eu propus simplesmente a inversão das prioridades dos times que atendem verticais daquele negócio. Que eles, os times, passariam a dedicar 80% e não 20% do tempo para atender projetos (ou demandas evolutivas). Não foi o que sugeri.

    Citei “organizações ambidestras” e outras referências para sustentar a sugestão de separação radical dos times que deveriam cuidar exclusivamente de projetos. Desta separação radical viria a desejável “blindagem”. Perdi a oportunidade, naquele momento, de citar uma referência que deve fazer muito mais sentido.

    Todos sabemos que o Scrum foi provocado por um artigo de Hirotaka Takeuchi e Ikujiro Nonaka, “The New New Product Development  Game”, publicado na Harvard Business Review de Jan-Fev/1986. Este artigo compila uma série de achados da dupla ao pesquisar o desenvolvimento de produtos em empresas como Fuji-Xerox, NEC, Canon e Honda, dentre outras. Os autores sugerem a adoção de um estilo “rugby” para desenvolvimento de produtos em detrimento do tradicional modo linear (comparado a uma corrida de revezamento). Takeuchi e Nonaka, em outros trabalhos, enriqueceram suas sugestões originais.

    Neste caso nos interessa principalmente a “organização hipertexto”, proposta apresentada originalmente em “The Knowledge-Creating Company” (Oxford University Press, 1995) e reapresentada em “Gestão do Conhecimento” (Bookman, 2009). A organização hipertexto é formada por três níveis: equipe de projetos, sistemas de negócios e base de conhecimentos. Esta “base” seria a síntese do conhecimento proveniente dos sistemas de negócios (hierarquia) e das forças-tarefa (equipes de projetos). Interessante destacar que, para os autores, a distinção entre projetos e o dia a dia seria algo bastante natural. Isso nos idos de 1995. E a gente aqui, correndo atrás de um “sistema inteligente de blindagem”.

    Encerro desconfiado de que o tema “Scrum ‘de raiz’” merece um pouco mais de espaço e atenção. Espero, sinceramente, que você me diga que sim (ou não). E espero, claro, que você não seja tão “binário”. Desde já agradeço. Inté!

    ?

    Observações:

    1. É claro que spams são totalmente censurados. Mas já fui obrigado a barrar outros comentários, infelizmente. Não se dá carona para gente desonesta.
    2. “Three Monkeys“, o cartoon utilizado, foi legalmente surrupiado do HikingArtist.