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:
- 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”;
- Os processos são definidos por cada equipe de forma independente;
- Inexiste um manual com políticas da organização; e
- 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:
- A descrição de cargos define as responsabilidades de cada indivíduo;
- Existe uma metodologia explícita para o desenvolvimento de projetos de todos os tamanhos;
- Políticas organizacionais devem ser respeitadas para permitir controles; e
- 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!
Tenho uma pergunta, e ficaria grato se fosse analisada…existe uma área relativamente nova chamada Business Engineering
segue link: http://en.wikipedia.org/wiki/Business_engineering
na forma que esta formatada acima segue a visão de gestão alemã, ou seja, voltada a engenharia/gestão de processos.
seria possível utilizar abordagens modernas e ageis neste método? Ex. ao invés de TOGAF e BE ST.Gallen, utilizarmos Canvas Business Model? ou mesmo incluirmos Scrum como método de gerenciamento do projeto de Business Engineering?
Seria possível mesclar Management 3.0 no dia a dia destas iniciativas?
Obrigado
Luciano
Existem vários artigos que discutem as diferentes metodologias de BE integradas com Scrum. Como exemplo veja em http://www.romanpichler.com/blog/the-product-canvas/ uma discussão de Scrum com Canvas Business Model. Em http://goadingtheitgeek.blogspot.com.br/2013/02/agile-software-development-under-togaf.html uma discussão de integração de Scrum com TOGAF. No artigo "Jumpstarting Scrum with Design Thinking" (http://ares.epic.hpi.uni-potsdam.de/apps/static/papers/TR13-002.pdf) escrito por professores da Universidade de St. Galen você encontraŕá a integração de Scrum com Design Thinking.
De forma geral os autores discutem e recomendam a integração dessas metodologias com Scrum por compatilharem vários aspectos de agilidade.
A resposta positiva para a sua pergunta se é possível integrar Management 3.0 com Scrum você encontrará em vários lugares a começar por essa apresentação (http://www.slideshare.net/ArneAhl/man30-meets-scrum).
Abraços
Bruno