Caros(a),
O motivo de nosso contato é informar que o número do telefone do escritório central da Teamware mudou.
Estamos atendendo nos contatos abaixo:
Telefone: + 55 11 4063 7819
E-mail: info@teamware.com.br
Equipe Teamware
Porque continuar a dar a mesma palestra por 200 vezes?
A palestra mais famosa do Brasil chegou a 200 apresentações e com isso, podemos calcular que cerca de 12.000 pessoas de todo o Brasil já assistiram palestra "Desmistificando Scrum e Agile".
Porque dar-la tantas vezes? Porque existe um processo de mudança de paradigma que é quase impossível fazer a traves da mensagem escrita, e parece perder força se filmado, realmente estar la acaba fazendo toda a diferença.
Porque continuar a faze-la? Porque ainda tem muita gente que precisa mudar os conceitos sobre o que realmente é essa mudança de paradigma que as metodológias ágeis pregam.
Quando começamos nos colocamos a meta de "Fazer das Metodológias Ágeis as preferidas para desenvolver software no Brasil" e continuamos a crer a traves do resultados obtidos pelos nossos clientes e amigos que muita coisa tem melhorado, e por isso estamos iniciando a campanha Brasil Mais Ágil com o lema "Vamos Tornar o Brasil Mais Ágil", e ajudar a popularização das mesmas e ao mesmo tempo ajudar a corrigir as distorções que são introduzidas quando uma idéia é passada de boca em boca e sua essência vai se diluindo.
Esta palestra foi projetada para desmistificar algumas idéias necessárias para entender Scrum e Agilidade que são contrarias ao que temos aprendido como "Melhores Praticas" em Gestão de Projetos, Melhoria de Processos e Engenharia de Software, que impedem de realmente poder obter os melhores resultados deste novo paradigma para desenvolvimento de software.
Alguns mitos:
- Os papeis e responsabilidades na Gestão 1.0 e na Gestão 2.0
- Planejar muito no inicio ou Planejar e replanejar continuamente?
- Sucesso = Escopo no prazo e no custo ou Sucesso = Mais valor mais rápido?
- Responsabilidade e controle Individual ou Grupal?
- Progresso = Esforço / Atividade ou Progresso = Resultados?
Confira os slides da apresentação:
Para aqueles que ainda não assistiram a palestra, vale a pena se inscrever e aproveitar, é grátis! e para quem pode colaborar com a campanha e pode patrocinar esta palestra em sua cidade tambem podem nos ajudar é so se informar no site da campanha.
Como fracassar tentando adotar Scrum?
por Juan Bernabó
Algumas perguntas exemplificam bem o tipo de problemas que estamos vendo no mercado ultimamente:
- Quantas oportunidades vou precisar fracassar na adoção de Scrum na minha organização?
- O que a minha organização e eu vou deixar de ganhar ou podemos perder caso a adoção de Scrum fracasse?
- Caso uma tentativa de adotar Scrum na minha empresa falhar, como as pessoas irão se comportar quando tentarmos novamente?
São estas as perguntas que os early adopters normalmente se faziam, já que eles estabam assumindo o risco de estar indo na contramão do mercado, estar totalmente sozinhos e entender que tinham o status quo contra, isto deixava eles um pouco mais atentos e focados em resultados.
Eles estavam sozinhos, sabiam que era uma mudança radical da forma de trabalhar, e tinham muitos motivos para mudar mais ao mesmo tempo era uma movida política arriscada na sua organização e precisavam ser cautelosos, mesmo sendo inovadores.
Porem conforme mais e mais Scrum esta sendo falado, menos pessoas estão se fazendo estas perguntas. Conforme menos e menos pessoas estão se fazendo estas perguntas elas tem menor conciencia do perigo e maiores são as chances de deixar de estar atento aos detalhes que podem fazer a sua adoção Scrum fracassar.
Na minha opinião creio que nem todo medo é ruim, por exemplo medo que inhiba a ação é ruim, porem falsa confiança, ou falta de medo, que nos deixe tranquilos quando deveriamos estar atentos também é ruim.
Esse medo era fundamental para justificar ser cautelosos, e andarem com pes de chumbo, e etenderem o tipo de mudança que eles estabam propondo.
Como estamos desde o inicio de Scrum aqui no Brasil, temos acompanhado varias ondas no mercado e uma das coisas que estamos vendo agora é uma demanda de empresas que tentaram engolir Scrum, mais ficaram com ele atragantado no pescoço e não conseguiram digerir.
Porem nem todo fracasso é um fracasso, uma frasse que acho otima é: "Sucesso é o resultado de experiência e a experiência é o resultado do fracasso."
Porem o nesta frasse não esta claro o fracasso de quem, e isto faz toda a diferença para o negocio da Teamware.
Certa vez o CEO de um possível cliente nos perguntou qual seria a unica razão pela qual ele deveria contratar a gente, naquele momento não sabia qual seria, e nem lembro o que devo ter contestado. Porem hoje sei, ele deveria contratar a gente porque a gente já fracassou o suficiente, e vai custar muito caro para ele passar pelo mesmo tipo de experiencia.
A Teamware esta no negocio por conta dos nossos fracassos, o que agrega valor aos nossos clientes são os nosso fracassos e não os sucessos, já que os ultimos são simplesmente conseqüência dos primeiros.
Temos o conjunto de crenças certas?
"Não é o que não sabemos o que nos coloca em problemas mais aquilo que sabemos porem esta errado"Mark Twain
Resultados são causados por ações, ações por pensamentos, pensamentos são limitados por formas de ver o mundo, formas de ver o mundo por crenças.
São algumas destas crenças que podem nos por em problemas serios tentando adotar Scrum:
- Achar que não é neccessaria uma razão estratégica da empresa para adotar Scrum, e que simplesmente
- Achar que é possivel "Implantar" Scrum.
- Achar que Scrum é só mais um conjunto de praticas a ser seguidas e que seguir as praticas é suficiente e que não requer uma mudança organizacional profunda.
- Não estar conciente do nível de mudança que a tentativa de adotar ira gerar
- Achar que se tem competência sobre como fazer uma mudança de paradigma, sem ter fracassado pelo menos três vezes tentando.
- Achar que Scrum é a solução de todos os problemas.
- Achar que a culpa de não fazer direito são as pessoas, e normalmente as "outras" pessoas.
Não ter o conjunto de crenças certo para encarar uma adoção de Scrum pode ser o pior dos pecados, porem reconhecer que não se tem o conjunto certo de crenças é um ato de humildade difícil de encontrar no mundo corporativo, sobre tudo na gestão media que por conta do papel, pareceria precisar estar certa sempre.
Existe dor real de negocio suficiente?
Existe um motivo maior para mudar do que para evitar a dor da mudança?
Digamos que você foi escolhido para "implantar" uma nova metodologia de desenvolvimento, esse tal de Scrum. Tanto faz se você já conhecia ou não, ou se você era da turma do CMMI, do PMBOK ou do RUP, ou você é um moderninho Ágil, uma coisa é certa, parece que as metodologias ágeis estão chamando muito a atenção nos últimos anos.
Porem porque e para que vamos procurar mais uma nova metodologia anyway? Será que existe algum problema a ser resolvido? Ou simplesmente ha interesse porque os concorrentes estão adotando? Ou virou moda entre os colegas ou algum executivo? Ou parece ser cool falar que a gente também faz Scrum?
Se não ouver dor de negocio maior que a dor da mudança necessária a organização não poderá suportar a dor da mudança e voltara atras ou resistira as mudanças.
Porque esta se adotando Scrum?
Uma frasse deixa claro se se esta tentando adotar Scrum por adotar Scrum. Imagine você indo num medico e ele perguntando para você, qual o seu problema? Ai você responde "Falta de aspirina". Falta de visibilidade, falta de organização, falta de comunicação não são problemas, são faltas de soluções. Quando se começa a adotar Scrum porque o problema é "Falta de Scrum" ou quando em outra época era "Falta de Processo" ou "Falta de Planejamento", já se tem 50% de chances de isso não dar certo.
Fazer a coisa certa pelos motivos errados não traz os mesmos resultados que fazer a coisa certa pelos motivos certos.
Na Teamware nosso objetivo não é e nunca será adotar Scrum, nosso objetivo sempre será melhorar os seus resultados para todos os stakeholders de forma sustentável, esse é o fim, Scrum é so um medio.
Existe suporte por parte da base e da alta gestão?
Scrum faz todo sentido para os altos gestores, quando se explica para eles o que acontece com os riscos quando você pode desligar um projeto da tomada assim que suficientes requisitos foram implementados, ou que se gerenciam resultados e não atividades, assim fica mais dificil ouvir desculpas de porque algo não esta pronto ou fica a bola no ar sobre de quem é a responsabilidade.
Também faz todo sentido para a base, já que eles sofrem com os problemas causados pela gestão tradicional.
Quem se sente um pouco deslocado é a gestão media, e é essa mesma que normalmente deveria contratar alguem para auxiliar a mudar a organização, mais talvez não exista muito interesse em mudar.
Assim se não houver suporte estratégico e operacional a mudança será muito difícil.
Scrum é um processo, não basta só implanta-lo?
As melhorias significativas que se encontram em empresas que de fato adotaram, não vieram grátis nem fácil, ouve uma necessidade de mudança no paradigma na cabeça das pessoas.
Processos não geram resultados, resultados significativos vem de hábitos, grande parte da adoção é desenvolver os hábitos corretos nas pessoas, e corrigir velhos hábitos contraproducentes.
Transformar o tipo de dinâmica organizacional que causa e mantem o baixo desempenho em trabalho do conhecimento ainda é uma arte que se aprende atraves da experiência e ela custa caro de adquirir.
Scrum não da para ser implantado, ele é adotado ou rejeitado.
Negligenciar os aspectos sociais, comportamentais, da dinâmica organizacional e políticos da mudança é talvez os outros 50% das causas de fracasso.
Estou pronto para liderar o tipo de mudança organizaçional que Scrum causa?
O pior que pode te acontecer, é achar que Scrum é facil de "implantar", já que ele é simples, achar que instalando um software, ou criando um template, ou alguem fazendo um treinamento alguem esta pronto para conduzir a mudança necessária na organização para adotar Scrum.
Mesmo que se tenha a compentecia, dizem que "Santo de casa não faz milagres", e parece que com Scrum é a mesma coisa. Uma "opinião" de um funcionário da empresa não consegue competir com uma "recomendação" dada por um "especialista no assunto" que nos custou muito, mais muito caro para nos dar essas palavras.
Se você recebeu a incumbencia de "implantar Scrum" talvez trazer a noticia de que você precisaria a ajuda ou auxilio de um consultor pode ser como mostrar uma fraqueza da sua parte.
Sabemos que coisas serão nescessarias?
Em nossos últimos cinco anos auxiliando organizações a adotar abordagens ágeis, aprendemos como fracassar, e é esse know how que agrega valor aos nossos clientes. Já que eles podem capitalizar os nossos fracassos evitando assim trilhar o mesmo caminho.
- Qual o tipo de mudanças organizaçionais que deveremos fazer?
- Qual o tipo de conflitos politicos que esta mudança ira trazer?
- Qual o tipo de resistências que enfrentaremos?
- De onde essas resistências virão?
- Como identificar quem é promotor, neutro e detrator de esta mudança?
- Como bloquear e evaporar resistências?
- Scrum vai resolver todos nossos problemas?
Estamos prontos para melhorar?
Para melhorar é necessário assumir erros, para assumir erros é necessário humildade e coragem, para ter demonstrar coragem e humildade em um ambiente corporativo são necessários o exemplo de quem lidera e incentivos na mesma direção.
Algumas coisas que não se dizem por ai é que Scrum é um pesadelo para quem foje dos problemas, se você adotar Scrum ira ter mais problemas que endereçar e não menos, mais situações desconfortaveis, mais seguido e caso, somente se os problemas levantados por Scrum forem resolvidos, ai sim você ira ter cada vez mais controle, qualidade, previsibilidade, transparência, moral e resultados.
Já imaginou Scrum mostrando problemas na cara dos clientes, usuários, executivos e gestores da tua empresa, será que a cultura esta pronta para lidar com aprendizagem e as inevitáveis fracassos para obter conhecimento e melhorar habilidades? Será que quando algo sai fora do esperado o clima vira uma caça as bruxas para encontrar e punir os culpados, ou vira um exercício de pesquisa e reflexão, onde se tentam encontrar as causas fundamentais dos resultados obtidos?
Conclusão
Scrum é mais do que uma metodologia, uma forma, que envolve uma filosofia diferente de encarar o desafio da gestão de trabalho e projetos baseados em conhecimento. A chave para o destravar os recursos ocultos não capitalizados nos trabalhadores do conhecimento é adotar um paradigma diferente, ou continuar a suportar os efeitos da gestão tradicional neste tipo de trabalho.
Temos muita experiência em trabalhar os aspectos que falamos neste texto já que consideramos os aspectos chave para o sucesso. Fale com a gente para entender como podemos ajuda-lo a ter sucesso em sua adoção de Scrum na sua empresa.
O DNA dos padrões de gestão
por Jorge DizO ciclo PDCA (plan-do-check-act) é frequentemente citado quando se fala de gestão da qualidade: é um modelo para a melhoria contínua que inclui uma fase de planejamento (P), outra de execução do que foi planejado (D), outra de análise do que foi feito (C) e outra de ações corretivas (A). Entende-se que esse padrão é cíclico: ou seja, na linha do tempo, teriamos P,D,C,A,P,D,C,A,P,D,C,A,...Como nota curiosa, o ciclo PDCA costuma ser atribuído a W.E. Deming. De fato, ele utilizou e ajudou a popularizar esta abordagem, só que não utilizava precisamente essa sigla: o ciclo era chamado "ciclo de Shewhart", o professor dele que propôs este modelo, e os passos eram P,D,S,A (plan-do-*study*-act). Deming fazia questão de alinhar este modelo com o método científico, enfatizava a fase "do" como um experimento controlado e, em minha humilde opinião, "estudar" é um termo muito mais feliz que "checar" para descrever esta etapa num ciclo de melhoria: sugere a utilização de massa cinzenta para avaliar o que foi feito, em vez de uma verificação mecânica.Algumas semanas atrás, durante uma pausa numa reunião de planejamento aqui na TeamWare (acho que logo depois de apitar o pomodoro) começamos a divagar sobre padrões e antipadrões que surgem na gestão e como eles poderiam ser expressos dentro deste vocabulário. Algo como um DNA para padrões de gestão cujos aminoácidos seriam P, D, C e A.Antes de seguir com a divagação, encontrei na web uma interpretação interessante: alguns propõem usar a sigla CAPDo em vez de PDCA, sinalizando que um ciclo de melhoria normalmente é iniciado a partir de uma constatação (check), da qual se deriva uma ação corretiva (act), que precisa ser planejada (plan) e executada (do).Outros padrões observados:O padrão Nike ("just do it"): DDDDDDDDDDDDDDDDD...O padrão waterfall: PPPPPPPPPPPPPPDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDc(RIP)O padrão waterfall com fase de estabilização estendida: PPPPPPPPPPPPPPPPPDDDDDDDDDDDDDDDDDDDDDDDDDDDDDcdcdcdcdcdcdcdcdcdc...O padrão "analysis paralysis": PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP...O padrão "por quê erramos ?": pdCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCaO padrão "precisamos nos manter ocupados": pDpDpDpDpDpDpD...O padrão "modelo de negócios para investidores de risco": PPPPPPPPPPPPPPPPPPPPPPPPdO padrão "PMI": PPPPPPPPPPPPPPPPPdCdCdCdCdCdC...Ao contrário do guru Deming, esta coleção de padrões não tem nenhuma pretensão científica. Provavelmente os leitores observaram outros padrões na natureza selvagem do mundo corporativo. Assim como nas florestas tropicais, a biodiversidade nas empresas fornece muitas espécies vivas cujo código genético ainda precisa ser sequenciado. Peço aos leitores que contribuam com o DNA das espécies observadas nos biomas que costumam frequentar: transgênicos e mutantes são especialmente bem-vindos. Gostaria de compartilhar alguns espécimes com a gente ?(imagem de Maria Keays sob licença Creative Commons)
A Arte Perdida de Testar o Software
por Jorge Diz
Recentemente, assisti na USP a apresentação de Fred Brooks sobre teletrabalho, como parte do lançamento da primeira edição em português do seu livro "O mítico homem mês", lançado originalmente em inglês no longínquo ano de 1975.
Na capa, uma chamada: "Leitura obrigatória para todos os gerentes de projeto de software". Depois de 34 anos, finalmente os gerentes de projeto de software não têm mais a desculpa da falta de domínio da língua inglesa para deixar de ler uma obra relevante para todos os que já implantaram em produção algo mais que um "Hello, world". Comprei uma cópia da versão traduzida, devidamente autografada.
Fred Brooks foi gestor do projeto do System/360 da IBM (o primeiro sistema operacional digno desse nome) no início da década de 1960, e o livro é em grande parte fruto das lições aprendidas naquele projeto, que provavelmente consumiu mais tempo e dinheiro que qualquer outro projeto de software até então. Para a IBM, foi uma aposta arriscada em cima de tecnologia nova, que deu certo.
Como testes são a minha praia, perguntei ao autor como foram feitos os testes daquele projeto. Fiquei surpreso quando ele me disse que utilizavam uma área de 1 acre (~40000 m2) exclusivamente
para testes, cheia de computadores e dispositivos (carísssimos na época). Havia centenas de roteiros de teste que eram executados em diferentes configurações de equipamentos, o tempo todo.
A pergunta que me faço é: como se perdeu essa arte ? Testes de software foram negligenciados durante muito tempo: o primeiro livro relevante foi publicado em 1979. A revelação de Fred Brooks me fez sentir como um renascentista recuperando um manuscrito árabe contendo algum tratado grego clássico, sumido nas trevas da Europa medieval.
Em 2009, mais de 4 décadas depois do System/360 ter sido lançado, estamos começando a acordar para a importância dos testes de software. Por que em todos esses anos em que o software invadiu todas as áreas do nosso dia a dia não se deu a devida importância a esta disciplina ?
A esmagadora maioria dos cursos de graduação na área de TI não inclui uma disciplina de teste de software. A ALATS-SP (Associação Latinoamericana de Teste de Software - filial São Paulo) iniciou uma campanha para concientizar a comunidade academica sobre a importancia dos testes. É uma iniciativa muito positiva, com a qual pretendo colaborar, mas o que chama a atenção é a necessidade dela. Fazendo uma analogia, seria como o Conselho Regional de Medicina ter que fazer palestras explicando que é necessário lavar as mãos antes de entrar ao centro cirúrgico.
Fica a semente para o debate. Alguém pode contribuir uma explicação ?
PMI e Scrum Gap de Paradigmas
Depois de ouvir o podcast de Ricardo Vargas, Chairman do PMI, sobre Agile Project Management ficou claro que será necessario um trabalho grande para continuar desmistificando Scrum e Agile, agora não porque não exista interesse ou demanda para adopção o que acontecia a muitos anos quando tivemos a coragem de começar fazer os primeiros treinamentos de scrum no pais, justamente pelo contrario.
Como o interesse esta crescendo um dos aspectos que podem ser banalizados mais rapidamente é de que para poder usufruir dos benefícios de Scrum e Agile é necessário uma mudança de paradigma, e é esse nosso principal desafio.
Eu vejo com muito bons olhos que aqueles que de alguma forma tem pautado suas carreiras a gestão de projetos (os gestores de projetos) e são associados do PMI, e tem um objetivo de avançar a ciência da gestão de projetos, possam começar a ser expostos a métodos inovadores de gestão como Scrum, que tenho certeza vai aumentar muito o valor da sua caixa de ferramentas, porem minha experiencia me diz que temos que tomar cuidado com um aspecto fundamental.
Alguns desafios pela frente
Gestores de projetos sobre tudo que passam numa certificação onde existem perguntas extremamentes claras sobre qual deveria ser a forma de pensar correta sobre um assunto vão provavelmente manifestar uma elevada taxa de concordância sobre algumas premissas fundamentais, certamente entre elas existira diferente capacidade ou habilidade porem algumas crenças, verdades e premissas fundamentais serão similares.
Muitos dos gestores que tenho feito coaching, e tinham recebido treinamento formal em gestão tradicional de projetos, apresentavam mais o menos a mesma forma de pensar sobre ser possível ou não detalhar todas as atividades de um plano de projeto para desenvolvimento de software.
O que tenho visto é que existe um gap entre o discurso e a pratica, ou seja as teorias esboçadas e as teorias em uso tem divergencias muito grandes e isso pode ser a causa de muitos problemas, como a falta de reflexão sobre alguma premissa fundamental, e assim a falta de aprendizado.
Peter Senge, autor do livro A Quinta Disciplina, fala que o problema das organizações não é que não conseguem resolver os seus problemas, o problema é que não conseguir "enxergar" seus problemas, o seu paradigma os cega.
Como as teorias aprendidas acabam sendo reforçadas já que são as respostas certas para exames de certificação, elas passam a ser tratadas como "verdades" e como Scrum e Agile partem de premissas em alguns casos opostas da gestão tradicional é necessário quebrar a ilusão que foi criada, para permitir o aprendizado de uma ferramenta que tem como premissa outras "verdades" que conflitam com aquelas adquiridas anteriormente.
O nosso trabalho tem sido basicamente nos últimos anos criar duvida suficiente das "verdades" aprendidas porem que estão criando problemas não deixando as pessoas conseguirem olhar para a realidade e refletir sobre os problemas que estão tendo realmente.
Conceitos para complementar o podcast do Ricardo
Aqui vão alguns comentários sobre o podcast que creio que podem ajudar a entender melhor e complementar o que Ricardo disse.
Ser ágil não se trata de velocidade, se trata sobre ser enxuto. Ou seja imaginem algo que tem muita massa, pode ganhar extrema velocidade e ser muito rápido, porem terá muita inercia e terá dificuldade de mudar de direção rapidamente sem muito esforço.
Então a rapidez na verdade não é o objetivo de Scrum e sim reduzir a massa.
Para poder ser ágil e flexível será necessário reduzir a massa, ficar mais enxuto, e isto a gente faz em Scrum usando o conceito de One Piece Flow (criar um fluxo de produção de uma única peça) por exemplo se faz fluir um único requisito funcional desde o detalhamento ate o teste funcional no menor tempo possível, fazendo que toda a equipe se concentre na menor quantidade possível para abaixar o estoque de trabalho em progresso (um conceito de Lean - Toyota - Just in Time) para poder responder a mudanças sem stresse.
O desafio para quem passou por treinamento formal em gestão tradicional de projetos será poder re-avaliar as premissas e crenças fundamentais, digo isto depois de ter reciclado centenas de pessoas formalmente treinadas em gestão de projetos tradicionais, não como uma hipótese e sim como um fato, nosso maior desafio é como o que tive com orientação a objetos a uns 22 anos atras, mudar o meu paradigma (o sistema de verdades, credenças e premissas) que lamentavelmente nos humanos não fomos projetados para mudar muito frequentemente na nossa vida.
Existem milhares de implementações meia boca de Lean, existem milhões de analistas e desenvolvedores OO que programam em linguagens OO porem continuam pensando de forma estruturada, como eu já vi esta historia varias vezes o desafio maior é que não tenhamos milhares de PMPs usando Scrum sem mudar o seu paradigma, sem realmente conseguir retirar todo o valor da ferramenta já que para poder retirar a maior quantidade de valor é necessário pensar diferente.
Uma pergunta para develar uma premissa
No Scrum Gathering apos a palestra do Ricardo Vargas, eu Juan Bernabó, acabei fazendo uma pergunta chave, conhecendo as premissas dos gestores tradicionais eu fiz só uma pergunta para tentar entender melhor se o discurso era um discurso de quem tinha passado por um entendimento profundo, mudança de paradigma, ou simplesmente de quem ainda so conhece os artefatos mais não as premissas fundamentais de Scrum.
A pergunta foi "O PMI parece ser muito centrado no papel do gestor de projetos, certo? Porem o PMI esta preparado para um mundo de equipes auto-geridas?"
O Ricardo contesto de forma totalmente transparente uma "verdade" que ele tem "experimentado" e que se eu não tivesse tido tanta experiencias reais com Scrum também teria, ele disse que a idéia de equipes auto-geridas é romântica, mais nunca viu uma funcionando direito, logico sem Scrum e Ágil eu vi uma porem era uma raridade.
Eu já transicionei mais de 80 equipes auto-geridas, por isso tenho plena convicção, porem sem essa experiencia seria difícil ter tanta certeza, sobre todo quando usamos processos que não estão ajustados para a auto-gestão, e que os ciclos de controle são muito grandes.
Pela primeira vez com Scrum tenho a oportunidade de criar em larga escala equipes auto geridas, que se comportam relativamente dentro de parâmetros, e que tem um resultado muito superior a qualquer outra forma de organização que eu já tinha visto.
Pela resposta do Ricardo deu para entender que ainda não foi exposto e ainda precisara passar por uma mudança de paradigma.
Por exemplo da para entender claramente o que um gestor tradicional acredita sobre times auto gerenciados, como ele nunca viu funcionando de forma eficaz então deve ser porque é necessário um time extremamente maduro.
Porem a auto gestão só é possível não porque as pessoas são muito maduras, mais porque usamos de alguns mecanismos que permitem que um grupo de pessoas normais (na media) tenham comportamentos emergentes (do sistema) inteligentes, isso se chamam gestão empírica com ciclos curtos (2 a 4 semanas), equipe holística sem papeis que permite que os pares possam se auto-regular, e feedback binário e concreto através da demonstração de produto pronto que é facilmente verificável, que passa nos testes de aceitação automatizados por exemplo.
Scrum nada mais é do que o nosso velho amigo o PDCA levado extremamente a serio por exemplo, 1 dia de Sprint "Planning" (Plan), 8 dias de "Sprint" (DO), 4 hrs. de Sprint "Review" (Check), e 2 hrs. de Sprint "Retrospective" (ACT).
O controle na gestão empírica não esta no processo e sim em definir claramente a entrada (item do backlog) e verificar rigorosamente a saída (features prontas testadas), e não mexer no processo durante o momento onde o processo esta executando (Sprint), só ajustar o processo depois de verificar a saída (ou seja no Sprint Retrospective).
A outra diferencia é que o papel das equipes mudou de co-adjudantes para papeis principais, elas planejam taticamente no Sprint Planning, e melhoram seu processo no Sprint Retrospective ao invés de simplesmente executar planos planejados por algum gestor, e ver seus processos melhorados por alguma área ou responsável por processos.
Como vemos Scrum esta sendo bem aceito inclusive na comunidade de gestão de projetos tradicional, logico não sem algumas preocupações, o papel do gestor de projetos como o conhecemos em Scrum muda de forma radical, PM irão precisar adquirir novos skills, novas formas de pensar, é muito mais legal e interessante do que assustador, porem precisa se ter consciência que para termos resultados no mundo ágil uma transição será necessária.
Já hoje e mais no futuro o que ira agregar valor é ser aquele facilitador que saberá criar o ambiente certo e os processos certos para que equipes possam se auto-gerir, um profissional com estas habilidades nunca deixara de ter valor no mercado.
Boa noticia
Donella Meadows fala em seus 12 pontos de alavanca para intervir num sistema
que o paradigma é um dos mais fortes, porem mais forte do que o paradigma é o poder de transcender a paradigmas, como a física clássica não deixou de ser útil nem perdeu validade com o advento da física quântica, a gestão tradicional e muito do seu corpo de conhecimento não perdeu relevância o problema é tentar usar uma única ferramenta (paradigma) para tentar resolver todos os problemas.
Teamware Vaga de Estagio em Design Gráfico / Web 2.0
Estamos montando equipes de desenvolvimento de produtos Web 2.0 e temos oportunidades para designers gráficos que sejam flexíveis, adorem aprender, resolver problemas e gostem de desafios.
O candidato selecionado terá oportunidade de criar a cara de produtos e serviços que poderão ser usados por milhões de pessoas, por isso precisa ter consciência do seu papel de tornar o mundo mais simples, mais legal e mais fácil de usar. Como somos uma empresa pequena e não cremos que o melhor seja especializar as pessoas num trabalho restrito preferimos contratar pessoas que não gostem de fazer todo dia as mesmas coisas.
A nossa empresa é pioneira na adopção de abordagens ágeis no Brasil (Scrum / XP) e por isso temos uma filosofia muito ligada a ter processos muito enxutos, trabalho muito pragmático voltado para a ação e simplicidade.
Não importa se a única experiencia que o candidato tem é de fazer coisas por hobby, nos também começamos assim. Nos acreditamos em treinamento no trabalho, puxado por projetos, ou seja acreditamos que as pessoas aprendem e melhoram conforme são expostas a problemas e desafios e elas procuram soluções e no caminho aprendem, melhoram e realizam.
Estamos buscando designers que gostem de trabalhar em equipe, que tenham disciplina e autocontrole para trabalhar em equipes autogeridas, tenham facilidade de aprender novas técnicas, ferramentas e tecnologias, gostamos de estar na crista da onda, não tenha medo do desconhecido e curtam desafios.
Valorizamos algumas características nas pessoas que trabalham com a gente: sejam flexíveis, que não tenham medo de aprender e de ser desafiados, multidisciplinares, curiosas, que possam lidar com a interteça e a ambigüidade e possam se apaixonar pelo que fazem.
- Design de Interfaces de usuário Web 2.0
- Design de Logos / Material Gráfico / Didático
- Desenvolvimento de vídeos e vinhetas para Internet
- Design de Camisetas / Materiais Promocionais
Obrigado,
Equipe Teamware
