10 maiores impedimentos organizacionais na adoção de SCRUM
A Scrum Aliance publicou um artigo excelente sobre os 10 maiores impedimentos organizacionais na adoção do SCRUM. Cada ponto de vista, foi defendido por especialistas de diversas empresas. Vou citá-los e colocar minha opinião a respeito de cada um. Fiquem a vontade em criticar,e dar sugestões.
Gostaria de salientar que as traduções foram livres e realizadas por mim.
10. Failure to Remove Organizational Impediments (Falha ao remover barreiras organizacionais)
Muitas empresas na quais trabalhei tem esta dificuldade, ou seja, problemas em promover mudanças a fim de melhorar o processo de trabalho, é como o autor captou a visão de cada uma “é assim que sempre fizemos negócios”, e “não queremos mudar porque já investimos muito nisto”. Para ganhar competitividade muitas vezes é necessário estar a frente do seu tempo. É um risco, mas se der certo você estará na frente dos seus concorrentes. Aqui posso citar o caso de uma grande seguradora, em 1994 a empresa tinha que decidir se utilizaria Windows e plataforma Microsoft, ou , se escolheria outra tecnologia. A decisão foi por Microsoft, na época, uma aposta. A aposta funcionou, em pouco tempo era a única seguradora com diversos processos automáticos e emissão na hora de apólice, com quadro de funcionários enxuto fazíamos o trabalho de grandes seguradoras. Muitas seguradoras já fazem isto, mas começamos bem antes, e, portanto, uma empresa inovadora e competitiva.
9. Misguided Cost Savings and Synergy Efforts (Economia de custos sem orientação e sinergia de esforços)
Este é interessante. Manter equipes com propósitos definidos, por exemplo, como citado, para quais ferramentais que foram homologados e que outras equipes devem usar. Não vejo problema em definir uma ou mais ferramentas, mas no fato de obrigar que outros times usem algo sem ao menos serem consultados. Acho fundamental antes de qualquer tipo de adoção, o envolvimento de todas as equipes, para que possamos ver em conjunto o que agrega e o que atrapalha, e assim, fazer com que todos comprem a idéia. POCs servem para isto. Alguém já viu ferramentas ou metodologias que são adotas por um tempo e depois caem no esquecimento? Por que será?
8. Lack of Training (Necessidade de treinamentos)
Empresas geralmente acham que treinamentos, coaching ou mentoring, são totalmente dispensáveis, isto fica claro em momentos de crises, as que têm este tipo de política, cortam em primeiro lugar treinamentos. O que não é legal é aplicar diversos treinamentos sem nenhum tipo de objetivo, pois com o tempo são totalmente perdidos,e aí sim, dinheiro jogado fora. Quando se deseja entrar em uma nova onda, na qual a equipe ainda não tem fluência, e de vital importância montar um planejamento de implantação, e em seguida selecionar os tipos de capacitações necessárias. Em 2004 na empresa que trabalhei, havia a necessidade de montar uma equipe de arquitetura. Com planejamento, inicialmente foram realizados alguns cursos e para emplacar, solicitamos um trabalho de mentoring, ou seja, condução de um projeto bem orientado e realizado a quatro mãos, que gerou um resultado final compensador.
7. Single-Function Groups (Grupos funcionais únicos)
Em grupos ágeis a comunicação é pilar principal e muitas vezes criar grupos especializados em alguns assuntos, podem coagir outras equipes. Quem nunca viu em uma empresa, aquele grupo denominado “Deuses”, o detentores de conhecimentos privilegiados, os inacessíveis,etc. Para mim, tudo balela, geralmente um grupo de egocêntricos, e no final da contas, pessoas com medo de ceder conhecimento e perder a posição. Em todos estes anos, percebi que o interessante e compensador é evangelizar e disseminar conhecimento.
6. Local vs Global Optimization(Otimização local versus otimização global)
A autora, pelo meu entendimento, critica o fato de montar estratégias locais em vez de globais, ou seja, esquecendo o alinhamento estratégico da organização como um todo e somente atuando pontualmente na organização. Exemplos estes como premiações, controles rígidos conservadores de projetos entre outros.
5. Assumption that Book Learning is Enough (Assumir que aprender com livros é o suficiente)
Vale algo que alguém falou para mim,”..os livros são fundamentais, porem, nos ensinam apenas a metade”. Ler alguns livros não significa que você se tornará um especialista. Nada como o conhecimento acadêmico aliado a prática, quando há a consolidação, temos o estado da arte. Outro ponto que auxilia em muito no aprendizado é o apoio de pessoas que já passaram por situações similares e que já aprenderam muito em outros projetos, o famoso orientador. Vamos aprender com quem já sofreu, não vale a pena reinventar a roda.
4. Individual Performance Evaluation and Reward (Avaliação individual de performance e premiações)
Se mal conduzido, pode jogar qualquer iniciativa no ralo. Quando se coloca prêmio(dinheiro, viagem, etc..) por algo realizado, muitas vezes para chegar em tal meta, “atalhos” são tomados, fora a concorrência interna e picuinhas. Times ágeis devem trabalhar em conjunto, com objetivo único, sem qualquer tipo rincha interna em prol de uma solução sólida.
3. Unrealistic Promises(Promessas irreais)
Típicas de alguns gerente de contas. “Sem problemas, para construir toda a sua intranet levo apenas 1 mês”, ou ,” implantar SOA é simples, em apenas 2 meses teremos serviços atômicos, bem definidos, reutilizáveis e com governança. “. Temos que ser pragmáticos, se for necessário um ano, precisamos falar, se for para fazer mal feito, melhor não fazer e continuar do jeito que está.
2. Assuming Agile Is All About Developers (Assumir que Agile é tudo sobre desenvolvedores)
Trabalhar com metodologias ágeis não é somente escolher uma abordagem TDD, programação em pares, entre outras técnicas de desenvolvimento. Gerenciamento de projetos ágeis envolvem toda uma mudança de paradigmas na organização, desde gestão de pessoas a relacionamento com clientes. Se não houver alinhamento estratégico entre os diversos times, é impossível atingir objetos significativos.
1. Silver bullet thinking and superficial adoption(Pensar que é bala de prata e adoção superficial)
Diversas consultorias de TI realizam fortes incursões de marketing afirmando que adotam metodologia ágil e todos os problemas de software como: funcionalidades não entregues, entrega fora do prazo e acima do custo estão resolvidos. No último Chaos Report do Standish Group 2009 podemos ver que ainda temos problemas. Ágil não resolve, ou levamos os problemas de uma abordagem para a outra? Como mencionei no item anterior, se não houver uma adoção sólida, seguindo boas práticas, com envolvimento real do cliente e alinhamento estratégico de todo o time, não tem jeito, o projeto afunda como todos os outros.
Trabalhamos em parceria com um consultoria que “utilizava” SCRUM, só que não tínhamos: reuniões diárias, feedbacks e muito menos um processo iterativo e incremental. No final das contas, foi um projeto cascata que ainda deixa um gosto amargo na boca.
Em resumo, acho que os autores foram muito felizes com o artigo e conseguiram captar a essência dos problemas, e que acho que podem ser aplicados a outros assuntos além de implantação de SCRUM. Vocês já sofreram com alguns dos itens mencionados?
[]’s
Fábio Margarito Martins de Barros
A vida real e as corporações
Minha esposa faz pós em projetos, gestão de pessoas e negócios. Hoje ela me enviou um texto no qual ela disserta sobre a situação de grandes empresas. Achei o texto muito legal, bem escrito e por isso compartilho com os amigos. O que vocês acham?
"Nosso dia-a-dia, é consumido dentro de um escritório (onde chegamos a não perceber se o dia está ensolarado ou nublado), resolvendo problemas de empresas que não se importam com nossa saúde física muito menos emocional. Que não se dão ao trabalho sequer, de ter um plano de carreira para motivar o desenvolvimento de seus profissionais. Hoje vivemos numa era de tecnologia e correria: tudo fica obsoleto muito rápido, tudo deve ser feito pra ontem e as pessoas, não devem se portar como pessoas - não devem ter vida pessoal, nem horários e nem lazeres. A competitividade é de outro mundo, pois não se compete com competências, mas atitudes de pessoas compulsivas, sem vida própria, arrogantes e por vezes “donas da verdade” que preferem passar de 12 à 15 horas no trabalho ao invés de ir para casa ter uma vida normal, de gente.
Aparentemente esta realidade se torna cada dia mais comum... deixamos de ser esposas, mães e filhas para sermos profissionais. Profissionais que, mais cedo ou mais tarde estamparão no rosto, a infelicidade por não serem reconhecidos pelas pessoas mais importantes da vida dela. Pior, quando dentro deste contexto ainda, há o profissional que não ama o que faz. Trabalha pelas necessidades básicas do ser humano, pra sobreviver, pra dar conforto à família, o que obviamente é aceitável, mas que sabemos, que em algum momento, o nível de angústia por ficar horas a fio em algo que não lhe dá prazer simplesmente o adoecerá, o deprimirá.
A revolução para solucionar este problema, além do compromisso do profissional, necessita do compromisso da organização. Esta por sua vez, ao invés de valorizar o profissional que vive para trabalhar, deveria melhorar sua organização, criar planos de carreira e formas de reconhecer o talento de seus profissionais. Enxergá-lo com ser humano e não como uma máquina que basta dar um “boot” para parar de aparecer aquela telinha de erro... Valorizar o profissional e proporcionar uma distribuição igual de tarefas, melhora as chances deste trabalhador ser mais feliz tanto profissionalmente quanto pessoalmente... faz com que ele pense em oportunidades de crescer.
Acho que o maior investimento das empresas é em pessoas, e o investimento tem que ser pesado. Mudar culturas é muito complicado. As empresas têm muitos heróis e parâmetros um tanto distorcidos como critérios de avaliação. Subestimar o trabalho de uma pessoa em função de outra por segregação ou “amizades”, é patético, mas é comum. Enquanto as pessoas não tiverem maturidade para respeitar umas as outras, o mundo tende ao individualismo e à competitividade destrutiva, portanto, o comprometimento é de todos."
[]'s
Scrumy
Um colega de trabalho, o Jose Otávio, Seninha para os amigos e agora Scrum Master, nos mostrou um site bem interessante sobre uma ferramenta de auxílio ao Scrum. Trata-se do Scrumy, um tipo de painel digital do Scrum, onde você cria as estórias /tarefas e as classifica de acordo com o andamento do projeto(To do, In Progress, Verify??,Done). Na versão gratuíta, você só tem o painel(que já me ajudou bastante), mas se pagar a pechincha de $60,00 ano, você ganha outras funcionalidades, tais como: BackLog, BurnDown Charts, entre outras que você pode conferir aqui.
[]'s
O retorno de um otimista
Hoje vou colocar um post um pouco fora do contexto do blog, mas não resisti. Acabei de assistir o clássico Corinthians x Palmeiras, algo muito fora do meu costume. Além de ser corinthiano, gosto de futebol mas não tenho o hábito de assistir jogos. Assisti o clássico para ver o Ronaldo mostrar o seu futebol. Apesar dos deslises pessoais( o que não é da nossa conta),o acho um profissional guerreiro e com objetivo. O Ronaldo foi eleito três vezes o melhor jogador do mundo, o maior artilheiro de todas as copas, depois de Pelé, acredito que seja o jogador mais conhecido do mundo, venceu contusões que o deixaram fora do futebol por 3 anos dentro dos 16 de carreira, e por mérito, se tornou milhonário. Agora podemos nos perguntar, por que ele com todo o sucesso que um profissonal poderia atingir no seu campo de atuação, precisa voltar a lutar e mostrar seu potencial? Na minha opinião, garra, força de vontade e principalmente amor pelo que faz. Para mim ele é um exemplo que podemos trazer para o nosso laboro.Se muitos dos profissionais que trabalhassem com sistemas tivessem amor e esmero pela profissão em detrimento aos rendimentos financeiros que profissão trás, com certeza não teríamos sistemas “capengas”, com manutenção difícil e sem visão de futuro. Nossa área cada vez está mais inflada de profissionais que na maioria não possuem qualquer embasamento em fundamentos, e, para piorar, o mercado responde com altos salários, seja lá qual for o nível. Espero que todos estes profissionais se espelhem no Ronaldo e se dediquem pelo menos 10% do que ele se dedica e com certeza nossa área crescerá e dará muito orgulho a todos, porque sinceramente, me desaponta muito quando ouço no metrô ou no ônibus, alguém escolhendo nossa área porque paga-se bem.Aonde está a qualidade e aptidão profissional? E a dedicação a profissão que se gosta? Alguém só é feliz e cresce no que gosta de fazer.
[]’s
Implantar um processo de software é fácil?
Atualmente suspeito muito de resultados de implantação de
processos defendidos por CIOs, e/ou representantes de empresas em congressos e
reuniões. Estas pessoas tem habilidades ímpares de comunicação e convencimento
e podem induzir outras empresas e pessoas ao erro. Particularmente, gosto de
apresentações realistas onde são mostrados os pontos de sucesso mas principalmente as falhas, pois
através dos erros podemos enriquecer a discussão. Aqui gostaria de ressaltar a
apresentação do Antônio Zegunis,
onde ele mostra os pontos que foram falhos e as lições aprendidas na
implantação da metodologia ágil SCRUM.
Será que se tudo fosse tão bonito como se prega ainda
teríamos índices tão altos de falhas nos projetos de TI? É para se pensar!
Acho que cada empresa possui necessidades distintas, algumas
se adaptam com metodologias ágeis e outras com metodologias mais formais. Independente
da abordagem escolhida, acho que as empresas falham em três pontos, o primeiro
seria o objetivo da implantação do processo, o segundo, conhecer a forma de
trabalho e em terceiro envolver pessoas.
Objetivo da implantação do processo: vejo que muitos
processos são criados somente para manter um selo ou para atingir alguma
certificação ou ainda, para mostrar que existem diversos artefatos, que,
teoricamente garantem qualidade, mas no final, artefatos que ficam em quadros
bonitos na parede sem a mínima conexão com a realidade. Nestes casos o
principal é esquecido, software de qualidade e aderente as expectativas do
cliente e como conseqüência, processos inchados e não alinhados a realidade.
Conhecer a forma de trabalho: geralmente um processo de software
é implantado para resolver algum problema, índice de bugs muito alto, sistemas
que fogem totalmente do desejado, ou qualquer outro. Acredita-se que
implantando uma metodologia iterativa e incremental seja a bala de prata,
como o UP, RUP
e SCRUM. Perceba que não
estou me atendo a um processo ágil ou
mais formal. Acho fundamental antes de
implantar o processo conhecer os porquês de cada problema, é interessante
observar o dia a dia da equipe, muitas equipes são julgadas mas nem sempre é
avaliado o motivo de nada dar certo. Pessoas estão sobrecarregadas? Pessoas
exercem papéis que não condizem com sua habilidade?É um problema de gestão? Tudo
isto precisa ser avaliado com cautela. Após entender, temos que escolher a
melhor metodologia ou conjunto de metodologias procurando o que se adere melhor
as necessidades e cultura da empresa, é utopia mudar a forma que algumas
pessoas trabalham, principalmente quando o software não é produto principal. Refinamentos
e customizações do processo são necessários para que ele se torne enxuto e
eficaz. Para mim, um processo enxuto é aquele onde as atividades são seguidas e
artefatos úteis gerados. Já vi casos de artefatos que são gerados apenas para
cumprir a metodologia, isto representa dinheiro jogado fora. Cuidado para isto não
acontecer....
Envolver pessoas: Não envolver pessoas na minha opinião é o
maior erro. Montamos um processo, correto? Quem executa? Pessoas. Você gosta de
fazer algo que lhe foi imposto sem ao menos consultá-lo ou interá-lo do que
será feito? Eu não gosto. Quando for definir um processo, consulte as pessoas,
mostre o que será feito, tome opiniões, entenda as angustias e expectativas,
mostre os benefícios, conheça os funcionários que você tem na equipe, empresas
cometem um erro grande, “Santo de casa não faz milagre”, geralmente as idéias
de como resolver os problemas estão dentro da própria equipe. Hoje estou do
outro lado das linhas inimigas 
,
ou seja, ao invés de definir, estou dentro do processo e dou um parabéns para a
equipe que está definindo o processo onde trabalho. Constantemente estamos em
comunicação para fechar as práticas que sejam úteis e eficientes, a comunicação
flui de forma bidirecional, consigo ver que as idéias da minha equipe foram
absorvidas, isto trás estímulos e a idéia é comprada. Se os amigos permitirem,
coloco o nome deles aqui, são profissionais competentes. Uma vez disse e continuo
a repetir, só acho alguém bom quando vejo os resultados(isto vale para mim),
teoria é ótima, mas como o meu amigo Giggiome
disse uma vez, “os livros levam apenas até a metade” e neste ponto não tenho do que reclamar,
resultados estão aparecendo.
Neste post estou apenas colocando meu ponto de vista sobre minhas
experiências e troca de idéias com outros profissionais. A ciência
de desenvolver software não é fácil, e comparado com outras ciências, ainda
estamos engatinhando, resumindo, não há uma fórmula mágica. A excelência apenas
é adquirida através de provas e experimentações. Não devemos ser reticentes e achincalhar
um ou outro processo de software, cada um resolve um tipo de problema. O melhor
é entendê-los bem e utilizá-los de forma adequada. Tenha a mente aberta, veja
novos paradigmas, realize experimentações, busque outras opiniões e dê oportunidade a talentos.
Até a próxima
Quadro de Scrum na Prática
Navegando pelo Youtube, encontrei um vídeo bacana sobre a implentação de um quadro de SCRUM. A idéia empregada pela empresa BlueSoft foi bem criativa. Confira!