Três amigos se encontram, durante um almoço…

- O que você está fazendo na vida, João (ex-executivo da Pirelli)?
- Bem… eu montei uma recauchutadora de pneus. Não tem aquela estrutura e organização que havia quando eu trabalhava na Pirelli mas vai indo muito bem…

- E você, José (ex-gerente de vendas da Shell)?

- Eu montei um posto de gasolina. Evidentemente também não tenho a estrutura e a organização do tempo que eu trabalhava na Shell, mas estou progredindo…

- E você Orlando (ex-Gerente de Projetos Oracle)?

- Eu montei um puteiro.
- Um puteiro???
- É, um puteiro! É claro que não é aquela zona toda como os projetos em que trabalhei, mas já tá dando algum lucrinho…

Segue sua explicação de o que é trabalhar em projetos Oracle:

1 – Você trabalha em horários estranhos (que nem as putas);
2 – Te pagam para fazer o cliente feliz (que nem as putas);
3 – Seu trabalho vai sempre além do expediente (que nem as putas);
4 – Você é mais produtivo à noite (que nem as putas);
5 – Você é recompensado por realizar as idéias mais absurdas do cliente (que nem as putas);
6 – Seus amigos se distanciam de você e você só anda com outros iguais a você (que nem as putas);
7 – Quando você vai ao encontro do cliente você precisa estar apresentável (que nem as putas), mas quando você volta parece que saiu do inferno (que nem as putas);
8 – O cliente sempre quer pagar menos e quer que você faça maravilhas (que nem as putas);
9 – Quando te perguntam em que você trabalha você tem dificuldade para explicar (que nem as putas);
10 – Se as coisas dão errado é sempre culpa sua (que nem as putas);
11 – Todo dia você acorda e diz: NÃO VOU PASSAR O RESTO DOS MEUS DIAS FAZENDO ISSO (que nem as putas);

Hoje faz um ano que comecei o Blog. Foram 564 posts, na maioria de autoria de inúmeras pessoas. Nunca pensei em fazer um blog autoral, pois sabia que não duraria mais que 1 mês. O dia a dia me impediria de tocar o projeto.

Hoje o blog é voltado para gestão ágil de projetos de software, mas também publico posts sobre projetos em geral, carreira, arquitetura, linguagens, humor e tudo que acho pela web que seja interessante, sendo da área de TI ou não.

Tenho orgulho em apenas 1 ano, ter chegado a ter mais de 3.000 views mensais, além dos 672 assinantes de feeds RSS/Atom.

Agradeço a todos os amigos que continuam voltando aqui, para ler os posts que vou agregando ao blog. Obrigado pela força.

Grande Abraço a todos.

Aprenda a resposta certa para as perguntas mais complicadas dos recrutadores

Bruno Vieira Feijó (redacao.vocesa@abril.com.br) 12/08/2009

As entrevistas de emprego estão mais complicadas. Um estudo da consultoria Korn/Ferry, especializada em recrutar diretores e presidentes no mundo inteiro, concluiu o que, na prática, headhunters e candidatos já sentem na pele: as entrevistas de trabalho não são mais meras comprovações de competências técnicas e realizações passadas.

Elas caminham para se tornar avaliações comportamentais, em que o candidato é avaliado desde o primeiro contato telefônico. “Como o entrevistador está mais rigoroso, o candidato precisa estar muito bem preparado para ver, em poucos minutos, sua vida profissional ser detalhada minuciosamente”, diz Rodrigo Araújo, sócio-diretor da Korn/Ferry no Brasil. Se passar pelo contato telefônico, o profissional terá uma conversa pessoal, na qual serão recordadas as fases mais complicadas da carreira — aquelas que envolvem arrependimentos, pontos fracos e decisões equivocadas. “Não é para constranger, mas para conhecer quem está por trás daquele estereótipo de candidato ideal, que permeia quase todos os currículos recebidos atualmente”, diz Lucia Costa, sócia-diretora da Mariaca, consultoria em gestão de capital humano. O objetivo é descobrir se a inteligência emocional do candidato ou seu estilo social combinam com o da vaga e o da empresa pretendida.

De acordo com os especialistas, ainda são poucos os executivos que ficam a vontade para falar sobre si mesmo ou sobre experiências adquiridas em situações delicadas. Por isso, a VOCÊ S/A separou algumas perguntas que exigem raciocínio complexo e mostra como você deve se portar em cada uma delas para ter sucesso numa entrevista de emprego.

QUANDO O HEADHUNTER DIZ: “Quais foram as críticas profissionais que você já recebeu que mais lhe surpreenderam?”
> ELE QUER TESTAR: Autenticidade, sinceridade e humildade em reconhecer falhas.
> COMO AGIR: “Escolha episódios que lhe chamaram atenção, mas nada que coloque em dúvida seu desempenho para a vaga em questão. Acrescente o que aprendeu e como você encara cada falha como uma oportunidade para se aperfeiçoar”, diz Marcelo Abrileri, presidente do site Curriculum.com.br.
> ATENÇÃO: Evite respostas que disfarçam um ponto positivo como se fosse negativo (por exemplo: “Era exigente demais, perfeccionista ou workaholic”). Elas passam a ideia de artificialidade.

QUANDO O HEADHUNTER DIZ: “Como você descreveria a cultura corporativa das últimas empresas por onde passou?”
> ELE QUER TESTAR: Lealdade e capacidade de se adaptar a diferentes tipos de gestão.
> COMO AGIR: “Faça um paralelo sobre o jeito de cada empresa trabalhar. Ao falar do que gostava e não gostava, seja honesto, mas apele para dados de conhecimento geral”, diz Lucia Costa, da Mariaca. “Diga, por exemplo: ‘Empresas alemãs são mais rígidas e burocráticas hierarquicamente, e eu me ressentia por mais agilidade. Por outro lado, gostava da estabilidade’.”
> ATENÇÃO: Não seja crítico e sarcástico em relação a chefes e empresas. Quem está sendo avaliado é você, não seus antigos patrões.

QUANDO O HEADHUNTER DIZ: “Conte algumas histórias sobre você em ‘ação’”
> ELE QUER TESTAR: Como você se vira na adversidade (sob pressão e prazos curtos).
> COMO AGIR: “Em qualquer entrevista, seu objetivo é convencer o recrutador de que você dá conta do recado”, diz Rodrigo Araújo, da Korn/Ferry. Conte iniciativas em que você foi o responsável, quais os desafios que esperava e o que realmente encontrou. E depois mostre os resultados: como esses obstáculos foram superados e de que forma isso o deixa pronto para futuros obstáculos.
> ATENÇÃO: Seja objetivo. Contar “um pouco” significa contar em três minutos no máximo.

QUANDO O HEADHUNTER DIZ: “Como você gerencia pessoas com pontos de vista diferentes dos seus”
> ELE QUER TESTAR: Talento para liderar um time.
> COMO AGIR: Cite projetos em que houve divergências de opinião e como você conseguiu ajudar todos a chegar a um consenso. “Por trás da pergunta, o examinador quer saber se você é sensível ao ponto de captar o que cada funcionário tem para oferecer de melhor”, diz Marcelo Abrileri, do Curriculum.com.br.
> ATENÇÃO: Aqui está sendo medido seu eventual grau de autoritarismo e como você impõe suas ideias.

QUANDO O HEADHUNTER DIZ: “Que opinião seus subordinados têm de você? E seus chefes?”
> ELE QUER TESTAR: Aptidão para ouvir e transmitir feedback.
> COMO AGIR: “Se você já passou por avaliações do tipo 360o, fica mais fácil saber o que chefes e colegas pensam”, diz Lucia, da Mariaca. “Senão, prove que você se preocupa em obter a opinião da equipe.”
> ATENÇÃO: Ninguém vence sozinho. Exalte a importância de todos que trabalham com você.

QUANDO O HEADHUNTER DIZ: “Como você se vê daqui a cinco anos?”
> ELE QUER TESTAR: Capacidade de enxergar e se planejar no longo prazo.
> COMO AGIR: “Não há problema em abrir suas aspirações para o futuro, mas evite citar nomes de empresas (principalmente das concorrentes) e cargos específicos”, diz Lucia, da Mariaca.
> ATENÇÃO: Passe a noção de que você está à procura de uma empresa com a qual possa estabelecer uma ligação duradoura.

QUANDO O HEADHUNTER DIZ: “Qual é seu maior arrependimento na carreira?”
> ELE QUER TESTAR: Capacidade de compartilhar aprendizados de experiências, até mesmo as decepcionantes.
> COMO AGIR: “Diga a verdade, mas também o que você teria feito de forma diferente se pudesse voltar no tempo e como tem aplicado esse aprendizado em outras situações”, diz Rodrigo Araújo, da Korn/Ferry.
> ATENÇÃO: Não se faça de vítima, alegando que as circunstâncias da época eram injustas, por mais que fossem.

Fonte: Você S.A.

Leia Também: Como responder às perguntas mais comuns em entrevistas de emprego

Postado por André Pantalião em 25 Ago 2009 10:03 AM
Para o InfoQ

Estava acompanhando a lista de e-mails leandevelopment e surgiu uma discussão sobre como definir o que seria Lean em 30 segundos. Algumas definições interessantes surgiram e tentarei listar algumas neste post.

Alan Shalloway disse:

"Lean é uma abordagem para entregar valor mais rapidamente para seus clientes focando em melhorar o workflow dos produtos sendo entregues. Em particular, times devem sempre reduzir atrasos, que estão ligados a desperdício e baixa qualidade."

Mary Poppendieck complementou citando a opinião de John Shook sobre o assunto:

“Como sabemos, muito e se não a maior parte, se não quase tudo do "Lean" é essencialmente procurarmos meios de executar o P-D-C-A em tudo que fazemos.”

Definição retirada de [http://www.lean.org/shook/2009/07/managing-to-pitch-with-pdca-pitch.html. É preciso se registrar para visualizar.]

Além disso Mary complementou que Lean é tudo sobre aprendizado constante. Fácil de dizer, difícil de fazer, especialmente em uma grande organização.

Robin Dymond contribui com uma explicação de 5 segundos que ele usa:

"Lean é um termo do Sistema de Produção Toyota (Toyota Production System – TPS). TPS é a razão da Toyota ser o fabricante dominador no setor automotivo atualmente."

Ele argumenta que isto atrai a atenção das pessoas e exibe os benefícios que eles podem ser obtidos. Mas no fim das contas, ele acredita que a melhor forma não é explicar o que Lean é, mas sim, mostrar os benefícios que podem ser obtidos.

Na sequência, Luiz Parzianello citou o workshop que desenvolveu para mostrar os benefícios que podem ser obtidos com Lean. Este workshop foi desenvolvido para desafiar mentes pragmáticas e analíticas que estão acostumadas a trabalhar sob o paradigma de produção em massa. Ele chamou este workshop de "Jogos Estatísticos para Adoção de Agile" e serão apresentados na Agile 2009 (Chicago). Quem quiser pode verificar a sua apresentação em: http://www.agile2009.org/node/1587.

Kent Beck resumiu muito bem sua opinião assim:

"Ao aplicar o desenvolvimento lean eliminamos tempo e esforço desperdiçado. O que sobra é produtividade. Exceto que uma vez que você fez isto, você está pronto para ver o próximo nível de esforço e tempo desperdiçado. Desta forma, o ciclo de melhoria nunca termina."

Mary Poppendieck comenta novamente e faz algumas observações na mesma linha de Kent Beck. Ela estava pensando sobre o que John Shook queria dizer e conclui:

"Lean é sobre sempre melhorar o que você é agora através de testes e métricas dos resultados. Então é sobre nunca estar confortável com o status quo, e sempre aprender como melhorar utilizando o método científico."

Ela ainda complementa: 

"Lean pode ser sobre fornecer mais valor ao cliente – mas como você sabe o que é valor para o cliente e como você sabe o que fazer para entregar mais valor para ele? Lean pode ser sobre aumentar o lucro – mas como você sabe que estes lucros estão contribuindo para o sucesso a longo prazo?

Em dez segundos, teremos só parte da mensagem. E isto pode ser perigoso, porque estas definições não o fazem pensar. Ela pensando sobre a frase de John Shook sobre Lean como : lean é fundamentalmente sobre entender o que é importante e usar uma abordagem disciplinada para constantemente melhorar nas coisas que foram definidas como importante. Uma definição bem genérica. Talvez é só parte da mensagem. Talvez seja algo para o pessoal pensar."

Siga o conselho de Mary, pense sobre o assunto, saiba mais e tire suas próprias conclusões.

Fonte: InfoQ

O novo vídeo promocional da tecnologia Java: “Java + You”

Lembram do antigo: “Java is Everywhere”

Fonte: Twitter do Odlaniger

Postado por Amr Elssamadisy, traduzido por Rodrigo Piovezan em 18 Ago 2009 01:01 PM

Em uma discussão recente no Yahoo! Grupo de test driven development Carlos Ble compartilhou seu entendimento de categorias de testes decorrente de sua pesquisa:

Acabei tendo a seguinte imagem:
Testes do desenvolvedor:
Testes unitários : Isolados, atômicos, inócuos: exercitados com xUnit
Testes de integração:
Testes isolados que podem mudar o estado do sistema, por exemplo: salvar em banco, escrever em arquivo… Um teste de integração não representa por si um requisito funcional. Podem ser escritos para xUnit. Eles verificam a integração do nosso código com uma ferramenta de terceiros ou com diferentes camadas de nosso próprio código, por exemplo: a camada de lógica de negócio requer a camada de acesso a dados

Testes funcionais: (também conhecidos como Testes de Sistema)
Um teste que exercita uma parte completa do sistema, algum requisito funcional. Ele pode mudar o status do sistema.
Testes do Product Owner:
Testes de aceitação: Testes funcionais cuja entrada e saída podem ser validadas por uma pessoa não-técnica, o product owner.

John Donaldson forneceu um modelo multidimensional para testes que foca em papéis de teste e tipos de teste:

Eu gosto da visão de testes que você propõe. Mas acho que é uma instância de um modelo maior, onde você tem (pelo menos) papéis de atuação e tipos de teste.

Papéis de atuação: desenvolvedor, testador, QA, usuário, sponsor, etc.

Tipos de teste: unitários, de integração, funcionais, sistêmicos, de aceitação, de carga prolongados (soak), preliminares (smoke), etc.

Em qualquer situação dada você provavelmente sabe qual papel se encarrega de qual teste – mas no próximo projeto isso pode ser diferente.

Dale Emery sugeriu que não saber qual tipo de teste você está escrevendo é um sintoma de código ruim e indica falta de clareza. Um teste pode cair em diversas categorias ao mesmo tempo e o que importa é o seu ponto de vista atual:

O desafio, penso eu, é que qualquer teste pode ser classificado razoavelmente de várias formas diferentes, dependendo de quais dimensões você está focando. E existem diversas dimensões que as pessoas usam para classificar testes. Eu identifiquei algumas aqui: http://cwd.dhemery.com/2004/04/dimensions/

Por isso estou menos interessado em saber "qual tipo" de teste é, e mais interessado em saber onde um teste se encaixa nas dimensões que são mais importantes para mim, dependendo do meu objetivo em determinado momento. Aquelas em que penso com mais frequência são:

• Qual "unidade" esse teste define e valida? (Qual sistema, subsistema, objeto, colaboração…) – Qual funcionalidade o teste define e valida?
• Quem está primariamente envolvido com esse teste? Quem se preocupa mais com os resultados da execução desse teste?
• Quais decisões serão tomadas a partir dos resultados da execução desse teste?

Charlie Poole fornece uma análise detalhada da categorização de Carlos e sugere:

Na minha opinião, a distinção mais importante é entre os testes de objetivos do desenvolvedor e os testes de objetivos do cliente.

Essa discussão evidencia o fato de que classificar testes pode ser bastante confuso – especialmente para o iniciante.  O consenso é que a forma mais indicada para classificar testes é uma abordagem dimensional e que o tipo de classificação que é relevante depende dos objetivos do usuário naquele momento e do contexto.

Fonte: InfoQ

“The Pen Story” é um curta em Stop-motion, que mostra a trajetória da vida de um homem, em fotos. Mostra na verdade a linha de evolução de uma câmera fotográfica (Olympus PEN) que dá nome ao filminho.

O filme foi criado pela agência alemã DSG para os 50 anos da câmera Olympus E-PEN. Para produção desse filme foram tiradas 60.000 fotos, das quais foram impressas 9.600. Após isso ainda foram tiradas mais 1.800, tudo isso sem pós produção.

O filme: “The Pen Story”

Making of do vídeo em alemão.

Se você gostou da musiquinha. A letra e música forma escritas por Johannes Stankowski e pode ser baixada de graça em mp3 e ringtone pelo site da Olimpus: http://www.olympus.eu/penstory/

Proposta do senador Expedito Júnior (PR-RO) passa pela Comissão de Constituição, Justiça e Cidadania (CCJ).

Por Redação da Computerworld *
21 de agosto de 2009 – 12h45

Projeto (PLS 607/07), de autoria do senador Expedito Júnior (PR-RO), que regulamenta o exercício da profissão de analista de sistemas foi aprovado na última quarta-feira (19/08) pela Comissão de Constituição, Justiça e Cidadania (CCJ). Agora, segue para análise da Comissão de Assuntos Sociais (CAS), em decisão terminativa – tomada por uma comissão, com valor de uma decisão do Senado.

Pelo substitutivo, aprovado anteriormente pela Comissão de Ciência, Tecnologia, Inovação, Comunicação e Informática (CCT) e acolhido pelo relator na CCJ, senador Marconi Perillo (PSDB-GO), apenas profissionais com diploma superior em Análise de Sistemas, Ciência da Computação ou Processamento de Dados poderão exercer a profissão de analista de sistemas.

Já a profissão de Técnico de Informática poderá ser exercida por portadores de diploma de ensino médio ou equivalente com curso técnico de Informática ou de Programação de Computadores, expedido por escolas oficiais ou reconhecidas.

A proposta torna privativa do analista de sistemas “a responsabilidade técnica por projetos e sistemas para processamento de dados, informática e automação, assim como a emissão de laudos, relatórios ou pareceres técnicos”.

* com informações da Agência Senado

Fonte: ComputerWorld

Não deixe de Ler também: profissões, regulamentação: flanelinha, capoeirista…

Por Guilherme Chapiewski para o Blog Guilherme Chapiewski
em 17/08/2009

Esses dias numa conferência alguém veio me contar a sua história, que era de uma empresa que nos últimos anos vinha desenvolvendo seus projetos de forma tradicional, em cascata, e que tinha gostado do que tinha visto sobre metodologias ágeis e estava pensando em tentar. Ele gostou principalmente da idéia de trabalhar com desenvolvimento iterativo e decidiu que iria tentar usar Scrum na sua empresa.

Passadas algumas semanas encontrei denovo com essa pessoa em um outro evento. Para a minha surpresa, ela me disse que sua vida estava um inferno! Os clientes não estavam dispostos a fechar contratos de escopo negociável, eles queriam saber exatamente o que e quando os projetos seriam entregues. Eles definitivamente não quiseram trabalhar com desenvolvimento iterativo, até porque os projetos já eram bem curtos (menos de 1 mês). Pra terminar, por ser uma agência pequena a equipe é de menos de 10 pessoas fazendo com que uma pessoa precise trabalhar em 3 ou 4 projetos ao mesmo tempo. E por aí vai…

Então eu perguntei: Quantos projetos davam errado antes de você começar com Agile?

E ele respondeu: Todos os nossos projetos sempre foram bem sucedidos.
E eu perguntei denovo: Então qual é o problema que você está tentando resolver usando Scrum e desenvolvimento iterativo?
(silêncio…)
Eu novamente: Ok, já entendí. Faça o seguinte, volte para o seu processo de trabalho antigo. Não sei como é mas me parece ótimo.

Muita gente se surpreende quando eu falo isso. Só porque eu falo sobre desenvolvimento ágil não significa que eu acho que isso é a solução para todos os problemas. Se todos os seus clientes estão satisfeitos do jeito que você está trabalhando, seus projetos não falham, você faz ótimas entregas e tudo está ótimo, você não tem um problema. E se você não tem um problema, você não precisa resolver nada. E nesse caso eu recomendo: não use uma metodologia de desenvolvimento ágil só porque está na moda.

Metodologias ágeis partem do princípio de que os requisitos de um projeto de software vão mudar. Geralmente em projetos de software grandes é muito difícil de planejar todos os requisitos de uma vez no início do projeto. Não seria impossível fazer isso mas o custo é tão alto que vale mais a pena planejar menos e ir adaptando o software e os requisitos ao longo do tempo até que ele esteja pronto. No cenário dessa pessoa, como os projetos são muito pequenos é perfeitamente possível planejar tudo antes em pouco tempo e desenvolver em seguida.

Em alguns outros casos onde os requisitos não mudam waterfall também pode fazer sentido. Por exemplo, quando você desenvolve software para o governo, toda a especificação do projeto normalmente é produzida e informada antes em um edital. Algumas vezes até o prazo de entrega já está definido. Eu pessoalmente já trabalhei em vários projetos desse tipo que deram certo, que foram entregues dentro do prazo, atendendo a especificação e sem maiores problemas. Como tudo estava funcionando, não havia motivo para pensar em outra forma de desenvolvimento que eventualmente poderia trazer mais problemas do que soluções, como no caso dessa pessoa que conversou comigo.

O que eu quero dizer com isso tudo é que não existe uma metodologia que funciona para todos os casos e todos os projetos do mundo. Assim como você deve usar a melhor ferramenta para cada problema, você deve usar a melhor metodologia para cada projeto.

No projeto que eu estou atualmente estamos quebrando vários paradigmas de desenvolvimento ágil. Estamos com times gigantes, usando quadros de Lean totalmente customizados misturados com Scrum e por aí vai. Estamos sempre analisando os resultados das iterações e replanejando nosso processo. Apesar de todos os livros dizerem que os times têm que ser pequenos, estamos trabalhando com um time de 20 pessoas que dá certo e está super produtivo. Esse é o espírito: faça o que for melhor para o projeto e o que te fizer ter os melhores resultados, não o que alguém diz que é certo ou é errado ou o que está na moda.

É perfeitamente possível desenvolver projetos bons em qualquer metodologia. Entenda qual é o seu cenário, quais são os seus problemas, limitações e aí sim decida qual é a melhor forma de trabalhar nos seus projetos.

Fonte: Blog do Guilherme Chapiewski

Postado por Mark Levison, traduzido por Marcelo Andrade em 18 Ago 2009 09:27 AM

Mark Balabanian, recém-designado COO da Accunote, perguntou-se como um gerente pode ajudar uma equipe Scrum. De seus contatos anteriores com equipes Scrum ele pensava que Scrum era apenas uma ferramenta para proteger os desenvolvedores da gerência, forçando os gerentes a interagir com os desenvolvedores em seus termos. Agora ele está lendo “Agile Software Development with Scrum” por Ken Schwaber e Mike Beedle para melhorar seu entendimento sobre Scrum. Entretanto, o livro não cobre em grandes detalhes o papel do gerenciamento e então Mark questionou sobre o que ele deveria fazer.

Cory Foy sugere que há duas coisas principais que a gerência pode oferecer: Visão e Apoio Organizacional (ex. remoção de impedimentos). Para a primeira, ele sugere seguir o exemplo da Toyota com seu papel de Chief Engineer (descrito em detalhes no: The Toyota Product Development System). Para Cory, um Engenheiro Chefe deve ter “visão e estratégia, com conhecimento suficiente para ser capaz de traduzir aquilo em conceitos do dia-a-dia”. Alguém capaz de dirigir visão e objetivo comum ao longo de todos os produtos e projetos da empresa. Um modelo que ele tem visto isso é o Process/Purpose Model:

O conceito aqui é que cada característica do sistema seja pontuado de acordo com criticalidade e sua diferenciação no mercado. O ponto chave é que muito poucas coisas deveriam acabar indo parar no quadrante superior esquerdo – basicamente aquelas coisas que você poria em um quadro de avisos. E de um ponto de v ista executivo, alguém precisa garantir que a organização esteja trabalhando nas coisas certas e entregando o valor certo no tempo certo.

Peter Stevens sumariza a visão de Cory com três principais pontos para o gerenciamento e em seguida acrescenta seu próprio:

• Prover Visão, Foco & Direcionamento para toda a empresa ou para todo o setor
• Criar um Ambiente Produtivo e Remover Impedimentos
• Criar uma Cultura da Excelência – extendida para incluir Honestidade, Franqueza, Coragem, Confiança e Responsabilidade Fiscal.
• Autoconhecimento (imagino que isto esteja relacionado à honestidade).

Alguns dos maiores gerentes são senhores respeitados com larga experiência e compreensão sobre seus campos de atuação. Eu imagino que era isso que a Toyota tinha em mente com sua visão de Engenheiro Chefe. Mas existem outros gerentes que não têm lá tanta competência, talvez porque tenham sido promovidos prematuramente, e estão mais propensos a criar perturbação do que intervenção verdadeiramente útil.

John Galvin dá algumas sugestões:

• Agilidade não é apenas uma questão do desenvolvimento, mas algo que se aplica a toda a organização. Se a equipe de desenvolvimento se torna ágil, mas a Gerência de Produto não, então eles certamente irão atravancar a equipe de desenvolvimento.
• Agilidade necessita de uma grande mudança cultural ao longo da organização em termos de abertura e honestidade. Não subestime a quantidade de trabalho envolvida.
• Cada departamento será afetado. O RH vai precisar de novas maneiras de lidar com revisões de desempenho, planos de carreira, etc.

Por último, em seu artigo, “The Manager’s Role in Agile”, Lyssa Adkins e Michael apresentam uma saudável lista de verificação para Gerentes Ágeis:

• Você está catalizando mudanças na organização para suportar os valores ágeis e começando uma triagem na cultura da organização sobre entrega de valor?
• Você remove dificuldades e impedimentos de forma significativa para as equipes ágeis? A equipe reconhece você como um facilitador e um líder mais do que como um gerente?
• Você é capaz de distribuir recursos com eficiência pelas equipes para maximizar a entrega de valor, ao invés de gerar batalhas pela utilização de recursos?
• Seu sistema de gerenciamento de desempenho auxilia as equipes a atingir seu melhor desempenho ao avaliar suficientemente tanto as contribuições individuais quanto das equipes?
• Você utiliza métricas para ajudar as equipes a aprimorar sua performance e para ajudar os líderes seniores a tomar decisões para otimizar a entrega de valor?
• Sua organização toma decisões frequentes sobre portifólio de projeto baseadas em valor e não apenas de acordo com prazo e orçamento?
• Você tem ajudando seus colaboradores internos a criar processos enxutos para ficar em sintonia com as equipes ágeis, ao invés de tolerar ver a velocidade de sua equipe se arrastar?
• Como seus fornecedores são encorajados a trabalhar de forma ágil? Seu outsorcing ajuda ou atrapalha suas equipes ágeis?

O que você sugeriria para o Mark?

Fonte: InfoQ