Getting Real is an excellent PM handbook
The three ways of getting things done (hierarchy, heterarchy and responsible autonomy)
Systemantics ou A Bíblia dos Sistemas
Twitter Weekly Updates for 2010-01-16
500m borboleta / 500m butterfly
Acabou de ser publicado hoje, na InfoQ, um whitepaper que escrevi sobre Gestão Ágil de Produtos:
http://www.infoq.com/vendorcontent/show.action?vcr=581
Posted originally in Portuguese at Locaweb’s AgilBlog
I recently read about agile culture and how some teams use only the processes embedded into the agile methodologies without absorbing the agile culture:
Doing some research on Wikipedia, I found:
which means that while process is “how things get done”, culture explains “why things should be done that way”.
What matters the most is the culture, since without knowing “why” something should be done in some way it is very difficult to follow and maintain that way - the “how” to do those things.
We can have an agile culture without any methodologies. If we present the Agile Manifesto and its principles to someone who never heard of agile methodologies, is very likely that she end up creating some processes which enable the agile culture.
On the other side, given an agile methodology like Scrum or XP, it is not easy to understand why this process should be followed. We can even see some benefits in the daily routine of software development but without knowing why we should follow this process, the probability that the process continues to be followed or, even more important, that the process evolves, are minimum.
That’s why it is so important to understand the agile culture before implementing any agile methodology
But culture change is a long term task, slow and difficult to measure. And any long term, slow and difficult to measure task is of little attractiveness. People look for the culture change benefits but are not willing to spend what is necessary to get to the results. That’s why we see the recipes.
Implementing methodologies and process changes are short term tasks, with great impact and easy to measure (graphs, points, etc.). That’s why we naturally prefer methodologies, the recipes.
It is very important to coordinate the methodology implementation and the process change in order to be sure they are not performed mechanically and that they are gradually inserted as a new organizational culture.
Coordinating the methodology implementation and the process change is not about knowing a lot about the topic and answering questions like “what should I do with the story points of this unfinished story?” or “should we estimate stories in points or hours?” or “should we use kanbam, lean, XP, scrum, …?” or …
This coordination must be in the direction of “agile thinking”. Agile methodologies are supposed to helps us think agile but many times it makes us stop thinking. :-/
Culture can only be changed through thinking, arguing, listening, experimenting.
Following recipes without thinking, arguing, listening and experimenting is a sure recipe for a mechanical implementation of the methodologies and a good chance of failure.
As mentioned in Outliers and in a very interesting Scientific American article, in order to be a specialist in anything we must practice in a thoughtful way and understanding what we are practicing and never execute the “blind practice”.
So in your next revision and planning meeting, or even during your daily stand up meeting, remember that prior to the methodologies comes the agile culture. Re-read with your team the agile manifesto and its principles and discuss the following topics:
Agile is culture, agile methodologies are the processes that help create this culture.
Would you like to read more about this topic? Please check other posts on agile and agile methodologies.
Publicado originalmente no AgilBlog da Locaweb
Recentemente li dois posts sobre a questão da cultura ágil e como alguns times usam apenas os processos embutidos nas metodologias ágeis sem absorver a cultura da agilidade:
Pesquisando na Wikipedia, encontrei as definições abaixo:
Ou seja, o processo é o “como” enquanto a cultura é o “porquê”.
Sem dúvida o que mais importa é a cultura, já que sem o “porquê” é muito mais difícil seguir e manter o respectivo “como”.
As metodologias ágeis, ou seja, os processos de desenvolvimento de software que as metodologias ágeis definem, são consequência da cultura ágil.
A cultura ágil consegue existir sem as metodologias ágeis. Se falarmos apenas no manifesto ágil e em seus princípios para alguém que nunca ouviu falar nas metodologias ágeis, é muito provável que essa pessoa acabe criando os processos necessários para viabilizar a cultura ágil.
Por outro lado, dado o processo ágil, por exemplo o Scrum, é difícil entender o “porquê” esse processo deve ser seguido. Dá até para perceber que esse processo melhora o dia-a-dia do desenvolvimento de software, mas sem saber o “porquê” de o seguir, as chances de que o processo se mantenha ou, mais importante, de que o processo melhore, são bem baixas.
Daí a importância de entender a cultura ágil antes de implementar as metodologias ágeis.
Só que mudar cultura é tarefa de longo prazo, gradual e de difícil mensuração. E como toda tarefa de longo prazo, gradual e de difícil mensuração, é pouco atraente. As pessoas querem os resultados da mudança de cultura, mas não querem gastar o que é necessário para se chegar ao resultado. Daí a busca por receitas de bolo.
Implementar metodologias e mudar processos são tarefas de curto prazo, de impacto e de fácil mensuração (gráficos, pontos, etc.). Daí a preferência natural que temos pelas metodologias, pelas “receitas de bolo”.
É fundamental orientar a implementação das metodologias e as mudanças de processo para garantir que elas não se transformem em atos mecânicos e para que sejam gradualmente absorvidos como cultura da organização.
E orientar a implementação das metodologias e as mudanças de processo não é conhecer muito sobre o tema e fornecer respostas para perguntas do tipo “o que eu faço com os pontos dessa história que não acabamos nesse sprint?” ou “devo pontuar as histórias com pontos ou com horas?” ou “será que devo usar kanbam, lean, XP, Scrum, …?” ou …
A orientação que deve ser dada está em ensinar a “pensar ágil”. As metodologias ágeis são um auxílio para nos ajudar a pensar ágil mas muitas vezes, ao invés de nos ajudar a pensar ágil, nos faz não pensar. :-/
Só se muda uma cultura pensando, discutindo, argumentando, ouvindo, experimentando.
Seguir “receitas de bolo” sem pensar, discutir, argumentar, ouvir e escutar é receita certa para uma implementação mecanizada das metodologias e consquente fracasso.
Como dito no Outliers e em um artigo bem bacana de Scientific American, para ser um especialista em algo, devemos praticar de forma consciente, ou seja, sempre questionando e entendendo o que estamos praticando e nunca executar a “prática cega”.
Por isso, em sua próxima reunião de revisão e planejamento de sprint, ou mesmo na sua reunião diária, lembre-se que antes da metodologia ágil deve vir a cultura ágil. Releia junto com o seu time o manifesto ágil e seus princípios e discutam:
Agilidade é cultura, as metodologias ágeis são os processos que ajudam a sedimentar essa cultura.
Quer ler mais sobre o tema? Então veja outros posts sobre agilidade e métodos ágeis.
Há quase um ano atrás eu comentei sobre a mudança do papel do gerente em um time que resolveu adotar metodologias ágeis. Na London QCon 2009 foi apresentada a palestra Managers in Scrum de Roman Pichler, um consultor inglês especializado em gestão ágil de produtos.
A apresentação completa pode ser vista em:
http://www.infoq.com/presentations/managers-in-scrum
Quem quiser ver só os slides, pode baixá-los aqui.
Vou destacar 4 slides que resumem a apresentação. Primeiro um slide que mostra como funciona a gerência tradicional:
Em seguida um slide que ilustra como deve ser a gerência em um ambiente ágil:
Uma comparação entre o processo de padronização antes e depois do uso de metodologias ágeis e o papel do gerente nesse processo:
E, por último, um resumo:
Vale conferir essa apresentação.
Texto muito interessante da infoQ sobre como ter times super produtivos:
http://www.infoq.com/news/2009/03/hyper-productive-team
Aliás, esse texto é um resumo de 4 artigos sobre Group Coherence de Joanna Zweig e Cesar Idrovo publicados Agile Journal baseados em uma pesquisa feita por eles:
Ao contrário do que reza a lenda, não basta só ter certeza que a máquina de café esteja funcionado…
Vou fazer como a infoQ e vou colocar abaixo um resumo do resumo!
Primeiro a motivação:
“Group characteristics and group dynamics are invisible to most of us. We are not trained to detect them, let alone manage them. Our work is influenced by much more than what we see. This can make project success (and failure) sometimes appear to be random.”
Em seguida, uma definição:
“Group Coherence is the shared state reached by a group of people that allows them to perform one or more tasks in perfect rhythm and harmony with great energy to overcome obstacles. This simplistic interpretation is a starting point for discussion and we acknowledge that it doesn’t begin to do justice to all the interdisciplinary components of Group Coherence that include behavioral, psychological, spiritual and sociological.”
E depois vêm as constatações (os destaques são meus):
“In our continuing search for Hyper-Productivity, we have observed that a strong and highly adaptable shared sense of Common Purpose can increase the group’s ability to execute on the project vision or enterprise strategy.”
“The hyper-productive teams we have observed apply high rates of practical collaboration. We believe that fostering Collaborative Interaction leads to increases in productivity, yet performance is recognized at the individual rather than team level. In environments where collaboration is required, managers should avoid assigning project work and accountability to individuals.”
“Creative achievement is typically associated with individual effort. Think of Newton, Edison, or Leonardo Da Vinci. Until not very long ago, creativity and design were the focus of a few, while the work of the masses was broken down into repeatable steps. Creativity was perceived to undermine the result of mass-production. Today, the work depends on the design and creative skills of the knowledge workers that perform it. In this post, we explore the different ways in which Agile methods foster individual creativity and allow for something far less commonly acknowledged: group creativity. We discuss four attenuators and five amplifiers of group creative activity.”
“Creative achievement is typically associated with individual effort. Think of Newton, Edison, or Leonardo Da Vinci. Until not very long ago, creativity and design were the focus of a few, while the work of the masses was broken down into repeatable steps. Creativity was perceived to undermine the result of mass-production.
Today, the work depends on the design and creative skills of the knowledge workers that perform it. In this post, we explore the different ways in which Agile methods foster individual creativity and allow for something far less commonly acknowledged: group creativity. We discuss four attenuators and five amplifiers of group creative activity.”
Abaixo estão os 4 atenuadores:
E os 5 amplificadores:
E a conclusão:
“In hyper-productive teams there are high levels of group creativity despite functional specialization. These are groups that are willing and allowed to experiment. Group Coherence can help understand the ingredients that can be observed when this happens. In the research these include Trust and Respect, Bonding, Loosening Boundaries, Shared Leadership, Agreement on a Shared Goal and Tolerance for Chaos. These formed the basis for this post. They cannot guarantee an earlier or more dynamic occurrence of group creativity, but their absence can prevent or delay its emergence. They are also all available to Agile teams.”
“In hyper-productive teams there are high levels of group creativity despite functional specialization. These are groups that are willing and allowed to experiment. Group Coherence can help understand the ingredients that can be observed when this happens. In the research these include Trust and Respect, Bonding, Loosening Boundaries, Shared Leadership, Agreement on a Shared Goal and Tolerance for Chaos. These formed the basis for this post. They cannot guarantee an earlier or more dynamic occurrence of group creativity, but their absence can prevent or delay its emergence.
They are also all available to Agile teams.”
O termo maçã podre, apesar de bastante forte, serve para descrever uma situação bastante delicada na formação e gerenciamento de times. Chamamos de maçã podre (rotten apple) a pessoa que destoa negativamente do resto do time e que, com seu comportamento, poderá estragar a equipe.
A InfoQ falou bastante sobre esse tema da maçã podre do ponto de vista técnico, o under-performer, aquele que é ou está tecnicamente abaixo do resto da equipe. Esse post da InfoQ é um resumo de um thread na lista Scrum Development no Yahoo! Groups que gerou mais de 100 mensagens sobre o tema.
Agora, o que fazer quando nos deparamos com uma maçã podre do ponto de vista comportamental? Alguém que é tecnicamente bom, mas que tem problemas de comportamento? Tecnicamente essa pessoa pode ter bastante para contribuir para o time mas seu comportamento faz com que o time não consiga ter um bom relacionamento com essa pessoa.
Nesses casos há dois caminhos a seguir. O mais simples é tirar essa pessoa do time. Essa é uma solução fácil tanto para o time quanto para o seu líder. A tendência numa situação dessas é o time isolar a pessoa difícil até que ela, por vontade própria ou por decisão do chefe, saia do time.
O caminho mais difícil, mas que certamente trará mais benefícios para a equipe, é ajudar essa pessoa difícil a se integrar ao time ao ponto de essa pessoa deixar de ser uma maçã podre.
É fácil receber no time pessoas fáceis de lidar. O desafio é receber uma pessoa difícil e ajudá-la a se integrar ao time. Os valores do time devem ser mais fortes que os valores da pessoa difícil ao ponto de os valores do time serem absorvidos e assumidos pela pessoa difícil.
Conversas francas com todo o time e com a pessoa difícil é um bom caminho. A transparência é essencial. Se houver boa vontade e disposição tanto do time quanto da maçã podre, há boas chances de a situação ser revertida.
Vale lembrar que, na maioria das vezes, uma maçã podre não quer ser maçã podre. Ela pode não se dar conta de que seu comportamento é prejudicial para o time. Ela pode ter tido experiências anteriores onde seu comportamento seria considerado normal. Por isso vale investir em ajudar o time e a pessoa difícil a se entenderem. Contudo, não dá para tentar indefinidamente fazer com que as coisas se ajeitem. É importante definir um prazo para reavaliar a situação e, caso ela não tenha se resolvido, talvez não haja outra opção a não ser tomar uma decisão mais difícil: dispensar uma ou mais pessoas do time.
Consegui achar mais um tema que une a natação com gestão de produtos, métodos ágeis e desenvolvimento de sistemas, a questão de como se tornar muito bom em alguma coisa. Afinal, nascemos com um dom, ou com prática poderemos ser muito bom em algo?
Há uns 4 meses atrás li um artigo sobre natação em:
http://www.totalimmersion.net/2007articles/january/expert.html
Que me levou ao artigo “The Expert Mind” da Scientific American. O mote das duas é que dá para se transformar em um especialista do assunto desde que:
Recentemente esse tema voltou à tona com o novo livro do Malcom Gladwell, autor de “The Tipping Point: How Little Things Can Make a Big Difference” e “Blink: The Power of Thinking Without Thinking“, chamado “Outliers: The Story of Success“.
Curiosamente a receita de sucesso é mais ou menos a mesma: para se transformar em um especialista em algum assunto (natação, programação, gestão, aplicação em bolsa, etc.) deve-se:
Flexibilidade nunca é demais. Hoje li um post muito interessante, entitulado “I Follow My Rules, You Follow Yours“, escrito por Jurgen Appelo, CIO de uma empresa holandesa chamada ISM eCompany e adepto das metodologias ágeis.
Fala da importância da flexibilidade na liderança. A princípio é um texto falando sobre metodologias ágeis de desenvolvimento, mas ao ler percebi que há ótimas dicas de liderança em geral e não somente liderença de times ágeis:
Vale a leitura!
Recentemente li dois posts sobre como “encaixar” UX em times que estão usando metodologias ágeis. Um deles é o “Agile UX: Como trabalhar com os designers” do Guilherme Chapiewski que trabalha na Globo.com. O outro é o “Agile UX: como integrar UX e desenvolvimento” do Antonio Carlos Silveira do Yahoo! Brasil.
Como o próprio Antonio apontou bem, essa preocupação sobre como integrar UX em um time de desenvolvimento de software que segue alguma metodologia ágil existe desde o início das metodologias ágeis. Alguns posts sobre o tema:
Aliás a busca por Agile UX no Google retorna muitas e muitas páginas dedicadas ao tema.
Um exemplo interessante é a apresentação abaixo, da Leisa Reichert que ela apresentou na Web 2.0 Expo Berlin:
Sem dúvida há várias maneiras de se integrar UX e metodologias ágeis e o correto é escolher a maneira que se adapta melhor à sua situação e disponibilidade de recursos (tempo, dinheiro e pessoas).
Contudo, queria adicionar meus 2 centavos a essa conversa. Apesar de ser importante termos especialistas em UX, pessoas que conheçam a fundo sobre arquitetura da informação, design de interação, design visual e todos os temas relacionados à experiência do usuário, acredito que UX deve ser uma preocupação de todas as pessoas do time. Não há razão alguma para o PO e os membros do time não se preocuparem com o tema e deixarem tudo nas mãos de um especialista. E se esse especialista um dia não estiver disponível? Se ele estiver ocupado cuidando de outras coisas? Ou mesmo se não tivermos um especialista em UX no time?
Não estou querendo dizer que UX não é um tema complexo, que requer muito estudo e prática, mas acredito que todos nós devemos conhecer os conceitos básicos de UX.
Vou citar duas situações exemplo que ilustram bem a importância de todo o time se preocupar com UX:
Ou seja, não é necessário ser um especialista em UX para ajudar no desenvolvimento e melhoria de UX dos sistemas que seu time cuida. Leia, estude, informe-se, afinal conhecimento nunca é em excesso!
Outro dia me deparei com um post no blog da 37signals sobre sistemas complexos que trazia uma citação de John Gall: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.
Fuçando um pouco descobri que esse John Gall, um pediatra, escreveu em 1978 um livro chamado “Systemantics, How Systems Really Work and Especially How They Fail” com um conjunto de leis que regem quaisquer tipos de sistemas, que podem ser desde de programas de computador até o corpo humano, o universo, uma cidade, uma empresa, etc.
O livro é uma espécie de paródia ou crítica à teoria de sistemas que foi criada por Ludwig von Bertalanffy, um biólogo austríaco, no início do século passado.
Systemantics teve uma segunda edição, “Systemantics: The Underground Text of Systems Lore”:
E na terceira edição foi rebatizado como “The Systems Bible: The Beginner’s Guide to Systems Large and Small”:
Apesar de ser uma paródia, no estilo das Leis de Murphy, ou mesmo por ser uma paródia, as leis de Systemantics fazem refletir, principalmente quando as lemos pensando em desenvolvimento de siistemas e produtos de internet.
Além da citação do início desse post, gosto particularmente das leis abaixo, que refletem muito a forma de pensar das metologias ágeis: The Functional Indeterminacy Theorem (F.I.T.): In complex systems, malfunction and even total non-function may not be detectable for long periods, if ever. The mode of failure of a complex system cannot ordinarily be predicted from its structure. The larger the system, the greater the probability of unexpected failure. Colossal systems foster colossal errors. Choose your systems with care.
As 5 primeiras leis são bem interessantes também: The Primal Scenario or Basic Datum of Experience: Systems in general work poorly or not at all. (Complicated systems seldom exceed five percent efficiency.) The Fundamental Theorem: New systems generate new problems. The Law of Conservation of Anergy [sic]: The total amount of anergy in the universe is constant. (”Anergy” = ‘human energy’) Laws of Growth: Systems tend to grow, and as they grow, they encroach. The Generalized Uncertainty Principle: Systems display antics. (Complicated systems produce unexpected outcomes. The total behavior of large systems cannot be predicted.)
Uma lista mais completa das leis pode ser encontrada em:
http://en.wikipedia.org/wiki/Systemantics
E nos links abaixo há a lista de leis com alguns comentários:
http://www.laetusinpraesens.org/docs/systfail.phphttp://www.draftymanor.com/bart/systems1.htmhttp://www.ece.osu.edu/~fasiha/systemantics
Fecho esse post com uma lei específica sobre evolução que é bem apropriada aos sistemas desenvolvidos usando metodologias ágeis: As evolution is the only system known to produce intelligent behaviour, it is to be preferred.
As evolution is the only system known to produce intelligent behaviour, it is to be preferred.
