No post “Acredite: Agilidade, e o Scrum em particular, não são somente para uma equipe de craques”  eu apresentei um debate entre dois autores onde em “Limitações do Desenvolvimento Ágil de Projetos” o autor elenca 6 objeções à Agilidade. Por isso eu apelidei esse artigo de “A Acusação”. Já em “A Causa Contra Agilidade: 10 Objeções Gerenciais Perenes” o autor contrapõe todos os argumentos da Acusação, acrescentado mais quatro. Por isso eu apelidei o segundo artigo de “A Defesa”. A primeira objeção discutida referiu-se ao mito de que Agilidade é somente para equipes constituídas exclusivamente de profissionais competentes.

No post de hoje eu abordarei a segunda objeção, que consiste em que implementar Agilidade depende da cultura organizacional. No julgamento dessa objeção seguirei o mesmo roteiro. Apresentarei os argumentos da Acusação, seguirei elencando os contrapontos da Defesa, ampliarei a discussão com dados tangíveis e concluirei com as palavras de um craque para dar o veredito.

A Acusação levanta a bola de que Agilidade adapta-se melhor em organizações onde:

1. As responsabilidades das pessoas não estão bem definidas, ou, nas palavras do autor, naquelas organizações onde a “descrição de cargos é ampla”;
2. Os processos são definidos por cada equipe de forma independente;
3. Inexiste um manual com políticas da organização; e
4. Os processos são secundários em relação às pessoas.

A Acusação continua seu discurso afirmando que Agilidade requer muita liberdade tanto para o indivíduo como para as equipes. Segundo ela isso leva a uma constante mudança tanto na forma de trabalhar (ou seja, nos processos) como no papel que as pessoas exercem no desenvolvimento de um projeto. Com essa argumentação ela induz o leitor a acreditar que Agilidade não se encaixa em organizações onde:

1. A descrição de cargos define as responsabilidades de cada indivíduo;
2. Existe uma metodologia explícita para o desenvolvimento de projetos de todos os tamanhos;
3. Políticas organizacionais devem ser respeitadas para permitir controles; e
4. Respeito à hierarquia é chave para o sucesso de uma organização;
    

Ela estereotipa alegando que Agilidade cai bem em empresas que estão começando suas atividades, normalmente com produtos ou serviços inovadores e que não cai bem em empresas grandes e bem estabelecidas onde a observância à burocracia e à hierarquia são fundamentais para o controle e consequente sucesso organizacional.

A Defesa, por sua vez, contrapõe, afirmando que para sobreviver no mercado atual as necessidades dos clientes devem estar à frente da burocracia e que um ambiente de trabalho adaptável a mudanças é fundamental para atender às mencionadas necessidades. Essa é a chave para o sucesso organizacional. Ponto para a Defesa!

Entretanto a Defesa conclui que se a cultura organizacional não se adapta à Agilidade então deve-se mudar a cultura. Lamentavelmente a Defesa não diz como mudar essa cultura… Mas existe uma coisa muito pior do que essa omissão. A Defesa, nesse ponto, está errada!

Para implementar Agilidade não é necessária transformar uma grande empresa, ou qualquer empresa estabelecida, em uma “start-up”. No livro “Papéis do Scrum: Porcas, Parafusos e as Origens de um Framework Ágil”  os cocriadores do Scrum, Jeff Sutherland e Ken Schwaber, descrevem como empresas grandes como a Google, Microsoft, Lockheed Martin, SAP, CISCO, GE e US Federal Reserve utilizaram o Scrum para desenvolverem grandes projetos constituídos de várias equipes Scrum, totalizando mais de 1500 pessoas distribuídas geograficamente. Eu não conheço essas empresas e menos ainda os projetos mencionados, mas acredite, caro leitor ou leitora, que todas elas têm em menor ou maior grau todos os 4 itens que a Acusação descreve como não adequados à implementação do Scrum.

A Acusação, por sua vez, comente um grande erro. O de afirmar coisas baseadas em crenças e não em fatos. Em uma rápida pesquisa utilizando o Google encontrei o artigo “Scrum e o CMMI Nível 5: A Poção Mágica dos Guerreiros da Programação”.

Antes de prosseguir é necessário descrever que o CMMI consiste num modelo de maturidade, desenvolvido pela Universidade Carnegie Mellon que ajuda as organizações no objetivo de aperfeiçoar seus processos, visando a contínua melhoria do seu desempenho. Para alcançar o Nível 5 (que é o maior) as empresas precisam ter seus processos definidos e gerenciados para então focarem na melhoria contínua. Uma certificação dessa requer tempo, burocracia e dinheiro (a Acusação não fala nada sobre dinheiro). Mas esses não são atributos que inviabilizam a implementação de metodologia ágil em uma organização, segundo a Acusação?

Voltando ao artigo, os autores concluem que: “projetos que combinam métodos ágeis com CMMI são mais bem sucedidos em produzir software com mais qualidade e que mais efetivamente atendem as necessidades dos clientes em uma velocidade maior”; que “…a produtividade das equipes Scrum foi quase o dobro da produtividade das equipes tradicionais”; e que “…utilizando uma abordagem de teste baseada em histórias para o desenvolvimento de software reduziu os defeitos encontrados nos testes finais do um projeto em 40%”.

A minha conclusão, baseada tanto na literatura quanto na minha experiência, é a de que a implementação de metodologia ágil requer coragem, vontade e determinação dos líderes de uma organização. Os aspectos culturais, em particular as crenças que levam às objeções, se esvaem com os resultados obtidos. Mas processos, políticas e definição de responsabilidades não são incompatíveis com metodologias ágeis e em particular com o Scrum.

Um forte abraço e até o próximo post!

The post Derrubando a Crença de que Implementar Metodologia Ágil Depende da Cultura Organizacional appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Recentemente a Forbes publicou um artigo muito interessante, cujo título traduzido é “A Causa Contra Agilidade: 10 Objeções Gerenciais Perenes”, onde o autor discute 10 objeções à Agilidade, sendo 6 delas apontadas em outro post (“Limitações do Desenvolvimento Ágil de Projetos”).

Meu objetivo é ampliar essa discussão, entrando no debate entre os autores dos posts mencionados acima. Se eu fizesse isso apenas nesse momento acabaria com um texto muito longo. Assim vou dividir essa discussão em 6 posts, sendo esse o primeiro. Mais do que reproduzir esse debate, meu objetivo é incrementá-lo. Para facilitar o entendimento apelidarei o primeiro post (o da Causa Contra a Agilidade) como “A Defesa” e o segundo (o das Limitações) como “A Acusação”.

A Acusação, antes de colocar seus pontos, alega de que não há estatísticas confiáveis comprovando que projetos desenvolvidos com metodologias ágeis são mais bem sucedidos do que aqueles desenvolvidos com metodologias tradicionais.

A Acusação não começou bem… Aqui nesse blog já escrevi sobre uma pesquisa (“CHAOS Report: Métodos Ágeis Aumentam Taxa de Sucesso de Projetos“) do Standish Group. Nesse relatório o instituto aponta que o aumento do número de projetos desenvolvidos com metodologias ágeis é uma das 4 razões para o aumento do número de projetos bem sucedidos.

Mas vamos para a primeira objeção, o assunto desse post, … A Acusação alega: “Agilidade é somente para uma equipe de craques”. Ela menciona que Agilidade foi desenvolvida por pessoas experientes, inteligentes e bem sucedidas. Na visão dela pessoas como Martin Fowler ou Jeff Sutherland seriam bem sucedidas no desenvolvimento de projetos utilizando qualquer metodologia.

A Defesa, por sua vez,  contra-argumenta, dizendo que enquanto os métodos tradicionais pressupõe que as pessoas precisam de uma gerência rigorosa por não serem competentes o suficiente, as metodologias ágeis pressupõe o contrário, de que as pessoas são competentes, desde que livres das amarras de uma hierarquia burocrática.

Penso que competência é fundamental, independente da metodologia. A Agilidade apoia-se em um conjunto de 12 princípios. Um deles diz que software deve ser entregue em ciclos de poucas semanas. Outro que software funcionando consiste na primeira medida de progresso. Sem competência esses princípios não serão alcançados e isso será verificado logo no começo do projeto (em detrimento dos métodos tradicionais cujo sinal de alerta emerge em decorrência de orçamento estourado ou cronograma atrasado), quando medidas corretivas podem e devem ser tomadas.

A Acusação, ainda nessa objeção, convida o leitor para pensar em qual seria o resultado de um projeto desenvolvido em sua empresa por uma equipe auto-organizada constituída de funcionários medianos sem uma supervisão próxima. Outro princípio desconhecido pela Acusação  diz que as melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis. Esse princípio resulta de um estudo publicado pela Harvard Business Review onde os autores descobrem que foram justamente equipes auto-organizadas constituídas pelos próprios funcionários de organizações como Cannon, Honda e Toyota que permitiram a essas empresas inovarem com rapidez sem a perda de qualidade e flexibilidade de forma a competirem em mercados cada vez mais competitivos. Assim tenho certeza que se o leitor for de uma empresa com esse tipo de cultura reponderá positivamente à pergunta da Acusação.

Entendo que a Defesa perdeu uma grande oportunidade aqui. Se as pessoas que desenvolveram o Manifesto Ágil são caracterizadas pela Acusação como craques (a tradução correta seria “estrelas”, mas penso que craque está mais próximo da cultura do país do futebol), então ela deveria perguntar por que esses craques sentiram a necessidade e desenvolveram metodologias ágeis, se as tradicionais, que eles utilizavam, os levavam ao sucesso?

Em 1993 Jeff Sutherland se preocupava com a baixa produtividade no desenvolvimento de software, um problema que as metodologias tradicionais não endereçavam. O Scrum nasce dessa preocupação e, nas palavras de Jeff, “…deriva da teoria de sistemas adaptativos complexos e foi influenciado pelas melhores práticas na indústria japonesa… Scrum não é um método de desenvolvimento ou um processo formal, consiste num algoritmo de compressão das melhores práticas no desenvolvimento de software observadas por um período de 50 anos.”

Com as palavras de Jeff termino esse post. No próximo discutirei a objeção cultural das organizações à implementação de metodologias ágeis e, em particular, o Scrum.

Aqui fica o meu abraço pra você.

The post Acredite: Agilidade, e o Scrum em particular, não são somente para uma equipe de craques appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Fora o fato de não podermos desenvolvê-los durante uma única “sprint”, não existe nada de errado com eles. Esse escudo nos protege até o momento em que o Product Owner (PO) volta das férias e prioriza um monstro desse. Qual a primeira reação? Afirmar que trata-se de um tal de “Épico”. Com coragem lembramos ao PO o seu significado. O PO, também com coragem, responde… E daí?

Nesse momento temos que explicar ao representante do cliente (o tal do PO) que esse requisito, afinal uma história surge de um requisito de negócio, precisa ser dividido em vários outros, de preferência menores do que o original, para que possam ser desenvolvidos e, com sorte, ao final de algumas “sprints”, termos aquele épico, digo, requisito de negócio, desenvolvido.

E qual é a dificuldade disso? A dificuldade está no fato de que uma história necessariamente deve corresponder a um requisito que agregue valor para o cliente. Em outras palavras… O cliente precisa perceber aquilo como importante para o negócio. Adicionalmente a isso o cliente terá que aprovar o desenvolvimento. Se ele não entender o valor do trabalho e não souber como validá-lo (se está completo e sem erros) ainda não teremos uma história.

Recentemente passei por uma situação como essa. O cliente queria apenas um gráfico. Esse gráfico tinha que ser consultado através de uma aplicação que roda em “browser”. Nesse gráfico deveríamos computar o número de vezes ao longo de um período de 30 dias que uma determinada marca aparecia nos diversos blogs, revistas e jornais online. Entretanto havia um quesito adicional. Esse número diário deveria se dividido em conjuntos do tipo: economia, marketing, finanças, entre outros. Como são milhares de notícias diárias, e a marca poderia variar entre inúmeras marcas existentes, precisávamos que essa classificação, ou seja, associar uma notícia da marca desejada em um desses conjuntos, fosse feita de forma automática.

Comecei a explicação da complexidade para o PO  desmembrando o problema na necessidade de se desenvolver um “crawler” (aquele robô que vai de site em site baixando seu conteúdo). Precisaríamos desenvolver e treinar um classificador probabilístico para classificar cada documento baixado em um dos conjuntos que o cliente precisava. Depois desenvolver um mecanismos de busca e recuperação dos documentos que continha a marca desejada e finalmente estaríamos prontos para desenvolver o gráfico. Eu não percebi que depois de 10 minutos de explicação ainda não tinha chegado na explicação da dificuldade de desenvolver o gráfico propriamente dito. Mas nem tudo estava perdido. Consegui fazer com que o PO percebesse que o problema era mais complicado do que de costume. Entretanto são coisas que o PO não quer nem começar a entender. Para ele “não importava se o pato é macho ou fêmea… o importante é que ponha o ovo” na mesa dele.

Como transformar “crawler”, classificador probabilístico, mecanismo de busca e recuperação de documentos indexados em valor agregado antes de mostrar o gráfico? Procurei sem sucesso pela receita de bolo. Como não encontrei resolvi descrever nesse “post” o que fizemos.

A receita é constituída apenas de dois ingredientes. São duas perguntas e aqui vão elas:

1. Que valor para o cliente, mesmo que seja parcial, podemos agregar com o que desenvolvemos?; e
2. Como apresentar esse resultado incompleto, mas de uma forma que a experiência de consumi-lo seja agradável?

Com o “crawler” o cliente não fazia muita coisa. Mas contando os documentos encontrados em um dia que continham a marca já era alguma coisa que o PO entendeu o valor. Com isso respondemos a primeira pergunta. A resposta para a segunda foi mais fácil ainda. Ele gostou da ideia de receber um “tweet” diariamente com as mensagens… “ A marca (A) apareceu (X) vezes hoje. A marca (B) apareceu (Y) vezes hoje”. Para isso foi necessário que ele listasse as marcas com maior prioridade para serem monitoradas. Todos concordarão que está longe do que foi pedido, entretanto é um bom começo.

Na segunda “sprint” procuramos transformar documento classificado em valor para o cliente. Usufruindo da ideia de valor agregado anterior foi desenvolvida uma planilha, ainda com as mesmas marcas listadas na “sprint” anterior, mas agregando a classificação. Ou seja ele passou a receber na planilha quantas vezes a marca apareceu em um dia em economia, marketing ou em algum dos outros demais conjuntos. O charme estava que na planilha já havia o gráfico plotado. Chegamos mais perto do alvo, mas ainda faltava muito chão.

O valor agregado da terceira “sprint” foi eliminar a lista. Afinal com um mecanismos simples de busca e recuperação o próprio cliente digitava a marca desejada e o sistema construía a planilha. Quase lá, confirmou o PO.

Na quarta “sprint”, em adição a planilha e aos “tweets”, o sistema apresentava online o gráfico originalmente solicitado. Enfim chegamos… Depois de 4 “sprints”!

Esse processo acabou ampliando a satisfação do cliente que terminou com funcionalidades adicionais antes não previstas.

Dois princípios antigos norteiam as perguntas:

1. Dividir para conquistar; e
2. Exceda a expectativa do seu cliente.

Embora os princípios sejam antigo o retorno, eu garanto, é moderno. Essa foi a minha experiência. E a qual foi a sua?

Um abraço e até a próxima oportunidade.

The post Como dividir épicos em histórias menores com apenas duas perguntas appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

O 11^o princípio por trás do Manifesto Ágil diz que "As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis" (The best architectures, requirements, and designs emerge from self-organizing teams). Nesse "post" responderei a duas perguntas:

         1. O que é uma equipe auto-organizável; e

         2. Por que as melhores soluções emergem dessas equipes.

O sintagma "equipe auto-organizável" foi cunhado por Takeuchi e Nonaka e publicado em 1986 em um artigo intitulado "The New New Product Development Game" na conceituada revista "Harvard Business Review". Esse sintagma consistia em uma das 6 características do processo de desenvolvimento de novos produtos em empresas líderes. O estudo desse novo jogo no processo de desenvolvimento de novos produtos foi motivado pelos resultados alcançados por empresas como Canon, Honda e Xerox que perceberam serem necessárias velocidade e flexibilidade, em adição à alta qualidade, baixo custo e diferenciação, para se sobressaírem em mercados competitivos.

Não é propósito desse "post" descrever sucintamente as outras 5 características, entretanto as listo: instabilidade inerente; fases de desenvolvimento sobrepostas; “multiaprendizagem”; controle sutil; e transferência de conhecimento organizacional.

Uma equipe adquiri uma "personalidade" auto-organizável quando é direcionada para um estado de "zero informação", ou seja, um estado onde conhecimento e paradigmas existentes não se aplicam. Os autores fazem uma analogia dessa "personalidade" comparando-a com a de uma empresa "start-up". Essas equipes caracterizam-se por 3 condições:

1. Autonomia: após receberem uma missão com objetivos claramente definidos, o time está livre para definir sua própria direção. A alta gerência limita-se a dar orientação, recursos e apoio moral;

2. Auto-transcedência: a equipe busca continuamente estender seus limites. Partem da diretriz recebida da alta gerência, estabelecem objetivos iniciais, elevando-os constantemente durante o processo de desenvolvimento. Ao perseguir objetivos aparentemente contraditórios a equipe supera seu "status quo" e faz descobertas incríveis; e

3. Fertilização cruzada: uma equipe multidisciplinar, com variados padrões de comportamento, processos conhecidos e especialização funcional conduz o desenvolvimento do novo produto. A referida fertilização acontece na iteração entre essas pessoas. Ao compartilharem um mesmo ambiente de trabalho o processo de transferência de conhecimento entre seus membros acontece naturalmente, caracterizando o termo fertilização cruzada.

Portanto uma equipe auto-organizável é aquela com comportamento parecido de uma empresa "start-up", que parte para desenvolver um novo produto com autonomia para decidir o que fazer, quando fazer e o porquê fazer, que busca ampliar constantemente seus limites, emergindo dessa busca descobertas incríveis, e onde pessoas com competências distintas trocam conhecimento. Mas por que as melhores soluções emergem dessas equipes?

Sinergia, onde o total é maior do que a soma das parcelas. Uma equipe multidisciplinar funciona como um único organismo. Suas limitações são muito menores do que a dos seus constituintes e o seu conhecimento é muito maior do que aquele que cada indivíduo detém. Adicionalmente um especialista por não tolerar erros em sua área de competência está muito menos propenso a desafiar o "status quo" enquanto o não especialista está constantemente motivado a fazê-lo.

Penso que essas são as razões por trás do princípio "As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis".

The post 11º Princípio do Manifesto Ágil – Equipes auto-organizáveis appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

O The Standish Group aponta quatro razões para a melhoria significativa encontrada em 2010 em relação a 2008:

1. Processos Ágeis: A utilização desses processos cresce a uma taxa de 22% CAGR. Hoje representam 9% de todos os projetos de TI e são adotados em 29% do desenvolvimento de novas aplicações. O instituto conclui que o crescimento da taxa de SUCESSO está diretamente relacionado ao aumento da adoção de metodologias ágeis.
2. Modernização: Esses projetos, que entre outros focam na conversão de código/banco de dados, tem taxa de crescimento anual menor do que a dos processo ágeis. Entretanto tem taxa de projetos rotulados como SUCESSO maior. O instituto conclui que isso acontece devido ao mecanicismo desses processos e de um ambiente relativamente mais homogêneo de perfil de profissionais.
3. Pacotes Empresariais: O número de novos projetos de implantação de ERP e CRM diminuiu. Como, segundo o instituto, consistem em projetos de grande risco com resultados questionados, a diminuição de novas implantações contribuiu para aumentar a taxa de projetos rotulados como SUCESSO.
4. Processos em Cascata: Consistem nos métodos tradicionais e já representaram quase 50% do número de novas implementações. Como crescem a 1% CAGR, sua utilização relativa diminuiu, contribuindo, assim, positivamente para a taxa de SUCESSO.

Não discutirei aqui se o Scrum pode ou não ser adotado no desenvolvimento de todos os projetos, em particular os de TI. Porém se você nunca participou de, ou a empresa onde trabalha nunca desenvolveu, um projeto utilizando metodologia ágil e, dado o quadro descrito pelo The Standish Group, eu pergunto: O que falta para começar já? Leia esse post e pense…

The post CHAOS Report: Métodos Ágeis Aumentam Taxa de Sucesso de Projetos appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.