Existe vida no escopo fechado

e podemos ser ágeis....

Sim, depois de alguns anos atuando fortemente com o processo iterativo e incremental, com ciclos cada vez mais curtos e feedbacks cada vez mais contínuo, dentro de ambientes fortemente engessados, com processos certificados, percebi, na prática, que podemos sim ser ágeis com o escopo e prazo fechados. Talvez isso seja um dos golaços da inspeção e adaptação dos próprios métodos ágeis e das práticas encontradas nos milhares de contextos pelo mundo, que optou por processos mais enxutos, eliminio de desperdício, foco no valor e mapeamento de fluxo.

Os contextos que começaram uma mudança para o mindset Lean, perceberam que as práticas poderiam emergir do próprio contexto e direcionados, segundo os princípios e valores deste tipo de gestão. Com uma série de práticas identificadas, podemos avaliar o contexto e, pela nossa experiência, identificar rapidamente sugestões que possam melhorar aquele contexto particular. Continuamente, aplicando a inspeção e adaptação, identificamos e eliminamos práticas que não agregaram valor ou não serviu para reduzir os desperdícios, e inserimos novas, para mais um ciclo de avaliação de hipóteses.

Qualquer semelhança com o método científico, não é mera coincidência.

Mas como fazemos praticamente?

Quando mapeamos o fluxo e facilitamos a conversa do time de desenvolvimento com quem conhece do negócio, começamos a perceber algo muito interessante. A informação flui bidirecionalmente entre as duas partes e o aprendizado é aproveitado pelos dois.

Mas em que momento?

Bem, temos um documento bíblia de escopo com 250 páginas onde, Analistas de Negócio (AN) cascata, acham que conseguiram cumprir uma missão bem complicada e que durou longos 3 meses de muito trabalho, com muitas horas extras. Ao terminar, o AN acredita que gerou um artefato de muito valor e não "será mais incomodado" pelos desenvolvedores e pode ir feliz para mais 3 meses para escrever outra bíblia.

E o ciclo continua.

Quando rodamos este modelo sob a ótica da inspeção e adaptação contínuas, observando a teoria dos sistemas, olhando para o todo e com as atividades mapeadas, percebemos que a coisa não funciona desta forma.

Em equipes de alto índice de qualidade, com processos bem definidos que garantem esta qualidade, 99.9% dos bugs em homologação e produção, tem origem em um mal entendimento de uma regra, que poderia estar mal escrita. Quando analistas de negócios e desenvolvedores analisam este bug, a informação está tão envelhecida, que ambos levam dias e as vezes semanas para entender e resolver. Este processo só piora quando quem analisa e corrige são outras pessoas, o que acontece em quase todos os contextos tradicionais.

Só para evitar este desperdício, o trabalho do AN dedicado já se paga.

Não é só isso. Algo mais interessante acontecerá.

Quando sugerimos uma nova proposta, aumentando a disponibilidade do AN para o time durante o processo inteiro e, conseguimos um tempo diário do AN para realizar um breakdown do documento bíblia de escopo em épicos e histórias pequenas, autocontidas, testáveis..., não é raro o próprio AN encontrar problemas de entendimento e regras mal definidas por ele mesmo.

Não é incomum o AN afirmar que este breakdown e o mapeamento das histórias sobre a mesa, com post-its, absolutamente low tech, lhe deu uma visão que ele não conhecia até então. Neste momento, histórias são canceladas, outras aparecem, prioridades mudam. É impressionante ver o sistema ganhando vida.

Também é bastante normal percebermos este estado reflexivo do AN quando os desenvolvedores o chamam para tirar um dúvida complexa e crítica. Nestes casos, é muito comum esta reflexão ser promovida até em quem pediu aquela funcionalidade.

A causa raiz para estas historinhas é muito simples. Poderíamos chamar de grau de frescor da informação. Quanto mais fresca é a informação, mais qualidade ela tem. Como consequência temos uma alavancagem clara do processo de aprendizado e o desenvolvimento flui de uma maneira mais eficiente.

Não é o Scrum, XP, Lean, Kanban que resolvem o problema da sua corporação. O que vai resolver a maioria dos seus problemas são os ciclos curtos de inspeção e adaptação. Poderíamos chamar ciclos curtos de feedback e ação.

Neste contexto, o papel do AN é muito importante e requisitado. Visando acabar com os maiores desperdícios em um processo de desenvolvimento, não só paga a presença "full time" de um AN, como retorna lucros sobre a medida em um curto período de tempo.

O trabalho dele seria o detalhamento contínuo do backlog, fazendo de forma contínua, alimentando a entrada do fluxo, e a solução de dúvidas que possam (irão) aparecer no restante do time.

O resultado é um produto final com muito mais qualidade e, na grande maioria dos casos, mais barato e em menos tempo.

Acho que é fácil perceber o que acontecerá no mundo competitivo que vivemos....

As empresas que acordaram para este fato e estão se reinventando, olhando para dentro, entendendo os seus processos e os melhorando de forma contínua estarão anos luz a frente das empresas que ainda estarão dormindo e precisarão passar por todo processo de aprendizado.

Não acontece como uma virada de chave. Para a sua empresa deixar seus processos enxutos, exigirá um processo árduo de aprendizado e retroalimentação. Fundamental.

Isso não é verdade apenas no contexto de desenvolvimento de software. Já exemplifiquei como "leanizei" a minha criação de canários e temos estes princípios e valores aplicados nos líderes de todos os segmentos de mercado no mundo, tanto na indústria quanto na prestação de serviços.

Deixo abaixo, novamente, um vídeo da montagem final do Boeing 737, com as práticas fundamentadas na legenda.

https://www.youtube.com/watch?v=Ihtl-SZLU9o

Formação superior e certificações - O que mudou?

Hoje tive uma discussão interessante no facebook, onde participaram meus irmãos e alguns amigos. Revisitamos esse assunto e pude expor onde evoluímos, nesta necessidade que é essencial para termos um Brasil mais legal para se trabalhar.

Sinceramente, na área de certificações tivemos pouca mudança e eu continuo achando pouco relevantes. Passaram dois anos desde o lançamento do Accredited Kanban Training e a minha previsão não se concretizou. Realmente não sei se foi a forma do treinamento que não permitiu ou se de fato o mercado está despertando. Pelo menos a LKU assumiu o nome certificação. Estava ridículo.

Mas por que o mercado está despertando?

Talvez o mercado tenha percebido que a sopa de letras em um CV não quer dizer muita coisa. Quantas pessoas você conhece que vai sempre para um curso ou para a faculdade pesarosos? Como se estivessem fazendo algo por pura obrigação, apenas para aumentar o salário e ganhar status na empresa. São estas mesmas pessoas que odeiam a segunda-feira e amam a sexta-feira. Precisamos amar os dois dias, como todos os outros.

Seu dia de trabalho tem que ser um momento desejado, independente da sua função. Sempre encontramos propósito, nem que ele esteja "apenas" relacionado à nossa honra.

Se você odeia o seu trabalho ou o curso/faculdade, você está desperdiçando a sua vida em troca de um monte de papel no fim do mês.

Mas o problema não é apenas falta de paixão. A estrutura da maioria das certificações que temos é ruim. A avaliação de um CSM, na minha visão, deveria ser o cara atuar como SM de um time de verdade por uma semana ou mais. Mesma coisa para uma certificação Kanban, XP, Change Management, whatever. Em situações onde não existe a possibilidade de um contexto real, um contexto seria simulado - uma empresa cascata, por exemplo.

Nas faculdades e MBA parece que o cenário está mudando um pouco. Pelas informações que tenho, a academia começa a se preocupar um pouco em mostrar outras opções a este modelo ultrapassado de gestão de projetos e de produtos, principalmente de software.

É estranha essa demora de reação da academia a ideias como o Management 3.0 e ao Lean. As "ideias" do Appelo já estão aí há décadas, ele apenas fez uma compilação. Me digam onde "energizing people, empowering teams, aligning constraints, developing competence, growing structure, and improving everything" é novidade? A grande novidade foi envelopar tudo isso e usar a teoria da complexidade para tudo. O Sistema Toyota, surgiu logo depois da segunda guerra mundial e com o Japão se reinventando. Há quanto tempo Goldratt nos deu "The Goal"?

A academia precisa, pelo menos, falar sobre as alternativas e aprofundar no pensamento complexo e na teoria dos sistemas. Entender como um sistema se comporta e compreender que as relações entre as partes afetam mais este comportamento que as próprias partes em si.

Vejo estes assuntos como obrigação. Primeiro e segundo semestre e referências nos semestres posteriores, relacionando tudo.

Outro fator que me leva a estranhar bastante esta demora é o uso claro do método científico para avaliar hipóteses dentro de cada contexto específico e toda esta teoria estar fundamentada por números.

Este trabalho é todo baseado em princípios e valores. Não existe um manual de práticas escrito em pedra. Cada decisão é confrontada com os princípios e valores e cada transição toma uma forma própria, customizada para aquele contexto.

Isso quer dizer que devemos matar as faculdades e acabar com todos os cursos?

É óbvio que não. A ideia é que o processo de seleção das empresas sejam repensados. E os sinais indicam isso já começou.

A academia precisa também precisa se reinventar. Não adianta mais cuspir profissionais despreparados no mercado. Neste sentido, empresas boas que conheço, preferem ser coaches de um funcionário mais cru, sem os vícios que aparecem nas faculdades de TI e mostra-lo como adquirir conhecimento. Este funcionário tem que ter paixão. Este funcionário precisa amar a segunda da mesma forma como ama a sexta.

Poderíamos dizer que a faculdade poderia ser usada como um norte para pessoas que não conseguem estruturar um programa de estudos independente. Mas o problema novamente é o foco. Para este direcionamento, penso que os maiores eventos do mundo agregam mais valor. O networking é melhor e em bate papos descontraídos você encontra o seu direcionamento.

Normalmente, um livro bom puxa mais uma dezena de outros livros que valem a pena o estudo. Destes outros são puxados, e quando você notar, estará viciado e ciente do seu rumo.

E o PMI? Se eu fosse o PMI declararia a minha incompetência para ensinar a gerir projetos de software e pediria ajuda para também se reinventar neste sentido. Me parece que eles são bem competentes para definir e gerir outros tipos de projetos, como de navios.

Declaração:
Tudo que foi escrito aqui reflete apenas a minha visão sobre o assunto.
Não fui forçado a escrever isso. =P
Não existem verdades absolutas.