Webcast dia 19 de Agosto - Kanban Explicado

Você está recebendo esse e-mail pois faz parte da nossa lista de clientes Caso não consiga visualizar clique aquii. Para não receber mais nossos e-mails clique aqui. Webcast dia 19 de Agosto - Kanban Explicado Kanban veio para ficar. A adaptação do kanban, base do modelo just in time da Toyota, à realidade  dos projetos de software começou em 2007 e cresce em adoção a cada dia. A dúvida hoje é até onde podemos ir criando visibilidade, limitando o trabalho em progresso e transformando ambientes do trabalho do conhecimento em verdadeiros sistemas puxados.   Data e Horário: 19 de agosto de 2011, às 10h00 (Horário de Brasília). O acesso à sala virtual estará disponível 15 minutos antes do início da palestra. Inscrição sala virtual: Para realizar sua inscrição basta clicar no link a seguir: https://www2.gotomeeting.com/register/287802962 Palestrante: ALISSON VALE Alisson Vale é um designer de produtos de software e empreendedor no Brasil. Com quase 20 anos de experiência desenvolvendo e liderando projetos de software, tem atuado há mais de 6 anos como praticante de métodos Ágeis, especialmente XP e Scrum. Em 2008, começou a trabalhar com conceitos Lean e Kanban em sua própria empresa, o que o levou a fazer apresentações em várias conferências nacionais e internacionais, e ganhar, em 2010, a primeira edição do Brickel Key Award, prêmio do Consórcio internacional Lean Software and Systems, LSSC.   Agenda Agosto - Ultima semana Evento Softwell Lançamento Maker Mobile São Paulo Treinamento Certified Scrum Master - Manuaus Treinamento Certified Scrum Master - Recife Treinamento Certified Scrum Master - São Paulo Agile Vale 2011   Setembro Treinamento Scrum ao Kanban - Recife Treinamento Certified Scrum Product Owner - Rio de Janeiro Treinamento Certified Scrum Master - Fortaleza Treinamento Certified Scrum Product Owner - São Paulo Notícias Case de SAP Agil da InfoGlobo é destaque na ASUG Conference 2011 Estivemos presentes na ExpoY Startando Startup Brasil iniciando um movimento   StartupFarm em São Paulo A primeira edição do StartupFarm acontece em São Paulo no mês de Agosto. O Startup Farm é uma iniciativa que busca potencializar o desenvolvimento dos novos negócios da Internet brasileira por meio da criação e aceleração de startups digitais em um programa intensivo com duração de um mês. Saber mais... Teamware do Brasil Tel +55 11 2638-9994 | e-mail info@teamware.com.br

Lean Startup na Agile Brazil 2011

No final de junho tivemos a Agile Brazil 2011, que é uma conferência nacional organizada por representantes das principais comunidades ágeis brasileiras. Este evento teve como objetivo promover a comunicação e a colaboração entre seus integrantes visando à disseminação coordenada da cultura Ágil por todo o país.

Nesta conferencia estivemos presentes, e foi talvez o marco onde Lean Startup deixou de ser um conceito conhecido por poucos e passou a ser conhecido pela comunidade mais ampla de Agile no Brasil.

Como sempre, gosto de fazer perguntas nas palestras dos outros e perguntei para o Joshua quais eram as implicações de Lean Startup para quem é Agil ou para a nossa industria, e ele respondeu muito animado que consideraba Lean Startup um movimento muito maior e muito mais profundo que Agile, ele metaforicamente falando comparou a primeira com uma onda e a ultima com um tsunami.

Neste video, disponibilizado pelo Luiz Parcianello, o Joshua Kerievsky da Industrial Logic, fala sobre "Priorizando a Felicidade" na sua jornada adotando conceitos e praticas de Lean Startup para o seu negocio de eLearning.



Também estão disponíveis os slides de esta apresentação que junto com o Henrique Bastos ajudamos a traduzir para o português. Eu não entendi porque todo mundo riu quando viu o meu nome nos agradecimentos pela tradução.... tiveram que me explicar que eu não era realmente uma referencia no bom uso do português, talvez do portunhol.

Priorizando a Felicidade  

Outra apresentação sobre o assunto de Lean Startup esteve a cargo pelo Alexandre Gomes e o Matheus Haddad que juntos fizeram um show sobre este assunto.

Lean startup - Agile Brazil 2011  

Outra apresentação interesante foi a do Henrique Imberti Jr. da Yahoo onde falou sobre Lean Startup sendo usado no projeto Meme e como se manter uma Startup dentro de uma grande empresa.

Startup em uma grande empresa: a evolução de um processo  

Finalmente tivemos um Open Space sobre Lean Startup organizado por mim (Juan Bernabó) que foi super concorrido e participaram amigos como Henrique Bastos, Renato Willi, Alexandre Gomes, Sylvestre Mergulhão, Manuel Pimentel, Rodrigo Toledo, Joshua Kerievsky, Flavio Ianagui Diniz entre muitos outros que não vou conseguir nomear aqui.

Estivemos presentes na ExpoY

Fonte: www.cabecadagua.com

Na terça feira 19 de julho, em São Paulo,  estivemos na Expo Y, “festival de negócios da geração Y”, nas palavras do criador do evento, Bob Wollheim, sócio da produtora SixPix.

Estivemos presentes no espaço curado pelo Diego Remus da Startupi, para falar um pouco sobre "Porque a tua Startup vai fracassar?", Lean Startup, uma metodologia que acreditamos que pode aumentar a probabilidade de sucesso nas Startups e a Germinadora, um micro-ecosistema para Startups que é uma novidade no mundo e do qual a Teamware faz parte.

Após mostrar o video do BulletBall, do Mark Griffing, um inventor americano que não desiste, apesar de continuar acreditando em sua invenção por mais de 26 anos, tivemos uma pequena conversa com a platéia sobre este assunto e como o conceito de Lean Startups pode nos ajudar.

Este é o tipico problema que empreendedores enfrentam quando o seu campo de realidade é alterado, o que é fundamental para alguém conseguir vencer os obstáculos, porem ao mesmo tempo é o seu pior inimigo já que impede o empreendedor de se conectar com a realidade e evite perder tempo, dinheiro e sanidade em idéias que não levarão a bons resultados. Mais de 80% das Startups fracassam não porque aceitaram risco de mais, ou tiveram dificuldade na implementação do produto, mais porque foram eficientes em "atingir fracasso", perseveraram em desenvolver um produto que ninguém queria.

Case de SAP Agil da InfoGlobo é destaque na ASUG Conference 2011

No dia 19 de julho ocorreu um dos mais significantes eventos de TI da América Latina, promovido pela ASUG (Associação de Usuários SAP do Brasil), reunindo profissionais envolvidos na implementação de suas soluções de tecnologia.

Foram mais de 2000 profissionais, aproximadamente 130 CIOs e Diretores de TI presentes neste evento, que teve como tema “A TI Como Diferencial na Estratégia Corporativa”.

A Teamware esteve presente junto com a InfoGlobo apresentando um case de sucesso do uso de praticas e metodologias que permitiram melhorar o desempenho do grupo responsável por suportar, manter e evoluir o sistema SAP na InfoGlobo.

Agilizando o SAP na InfoGlobo com Kanban

Esta apresentação foi realizada no ASUG Conference 2011 em 19 de Julho por Wagner de Menezes, Fabio Fontão da InfoGlobo junto com o Juan Bernabó da Teamware do Brasil.

Foi apresentado como conseguimos melhorar a Gestão da Capacidade do CCS (Centro Compartilhado de Serviços) SAP da InfoGlobo melhorando o lead time das demandas, melhorando o tanto o desempenho quanto a satisfação de todos os envolvidos.

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:

Um trecho da palestra ministrada in-company

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 Diz

O 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 ?": pdCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCa

O padrão "precisamos nos manter ocupados": pDpDpDpDpDpDpD...

O padrão "modelo de negócios para investidores de risco": PPPPPPPPPPPPPPPPPPPPPPPPd

O 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)