Tornando-se um líder Ágil - Parte 1

Colaboração, delegação de tarefas, feedback, prazos, orçamentos, planejamento estratégico: o que é necessário saber caso você queira se tornar um líder Ágil ?(assumindo que você sabe o que Ágil com A quer dizer)
Se você, como líder, acredita que para comandar uma equipe basta apenas ótimos conhecimentos técnicos, acho melhor você se atualizar um pouco pois os tempos mudaram... Vou tentar apresentar algumas informações importantes para que você possa entender onde Desenvolvimento Ágil pode ajudar a criar equipes mais produtivas e motivadas, empresas mais coesas e principalmente vantagens competitivas. O seu papel como líder é importantíssimo, auxiliando a todos no processo de mudança que está se tornando mais e mais evidente no mercado brasileiro.

Nem tudo são flores

É necessário dedicação, e muita força de vontade, se você quer tonar-se um líder realmente eficiente. O que muitos acreditam ao assumirem uma posição gerencial é que não existe a necessidade de estudo para realizarem sua atividade. Este engano pode levar uma equipe inteira ao desastre. A sensação de poder existente em um cargo de gerente pode torná-lo arrogante e cego às reais necessidades de sua função, portanto não se esqueça: aprenda sempre! com todos!
Um bom início a meu ver pode ser o livro de Paul Glen: Leading Geeks, por ser um livro simples e muito tranquilo de ler... (ah não sabe ler em inglês? desculpe, aprenda! Que tal começar por aki). O livro servirá como uma introdução ao mundo da liderança... aproveite! (alias, o programa de webinars gratuitos que o site do Paul Glen possui é uma ótima pedida! acesse!)
Respondendo à pergunta: pra que isso me serve?, vai um pequeno texto sobre as mudanças que nossa área está sofrendo: (fonte: ComputerWorld

A analista do Gartner disse que as companhias querem melhorar a habilidade em cuidar das informações, o que pode significar, por exemplo, ajudar os negócios a entender melhor a lucratividade de um determinado produto ou eliminar um passo desnecessário no supply chain via automatização.

Ken McGee apontou como evidência de que certas companhias estão se movendo nesse sentido o comportamento dos empregadores de buscar um CIO que não tenha necessariamente uma graduação em Engenharia da Computação ou em Ciência da Computação. “Elas procuram alguém que possa fazer outras coisas além de administrar o ambiente de TI”.

Em cinco anos, defende o analista, o CIO pode estar separado das responsabilidades de administrar a operação de TI. “Talvez a tecnologia tenha um melhor atendimento com a criação de um grupo de operações focado nisso, sendo submetido ao chefe das operações. Achamos que é um debate justo”, diz. É também um tema, ressalta McGee, sobre o qual o Gartner continua pensando.

Joe Montano, chefe de TI do departamento de Energia, Minerais e Recursos Naturais do estado norte-americano do Novo México, disse que o questionamento de McGee ressoou em seu pensamento. “Você pode notar isso acontecendo. Eu tenho ficado cada vez menos nas operações do dia-a-dia, portanto o foco está mais nos negócios”, completou.

Pois é, é necessário atualizar-se. Mas por onde começar?? Particularmente não acredito muito que fazer um curso de Administração em uma unibomba da vida não resolverá sua vida, mas que sabe por um custo muito menor você não consegue o mesmo resultado??
Já pensou em fazer um MBA? Caro? E se eu disser que ele pode sair de graça??!?!? Duvida? (Fonte: Personal MBA Manifesto)

The Personal MBA (PMBA) is a project designed to help you educate yourself about advanced business concepts. This manifesto will show you how to substantially increase your knowledge of business on your own time and with little cost, all without setting foot inside a classroom.

The PMBA is more flexible than a traditional MBA program, doesn’t involve going into massive debt, and won’t interrupt your income stream for two years. Just set aside some dedicated reading time, pick up one of these books, learn as much as you can, discuss what you learn with others, and go out into the real world and make great things happen.

If you’re interested in educating yourself about business, the Personal MBA is the best place to start.

Recomendo livros de Peter Drucker e Demin. Entenda de onde surgiu o conceito para poder aplicá-lo da melhor forma possível. É necessário aprender sobre qualidade total e administração moderna para saber onde quero chegar com esse negócio de Desenvolvimento Ágil

Leia meu amigo, leia muito! É necessário ter o conhecimento base durante a aplicação de práticas de Desenvolvimento Ágil

Onde TI e Businnes se encontram

Fonte: Business and IT – A Marriage Made in Heaven?

To most non-technical people, the mere mention of "IT" can be a real turn off, or result in a roll of the eyes. Although traditionally associated with geeks developing code in a back room, IT - in its very broadest sense - forms the backbone of organizations today, which begs the question: why is there still such a huge communication gap between the IT discipline and the business it powers? This article provides anecdotes and advice for businesses to help them resolve the issues between business and IT, and describes how using Agile methods might just save their relationship.

Talvez este seja o principal documento deste post de hoje... devore-o!

até o próximo...

10 Boas Razões para adotar Desenvolvimento Ágil

Saudações!!
Encontrei um site muito bom para referências! Uma série de artigos importante e pertinentes podem ser encontrados no blog All About Agile. Foi de lá que tirei minha última referência para falar a respeito do desenvolvimento Ágil.
Existe alguma razão para se largar um projeto aos moldes tradicionais?? Claro que sim!
Segue abaixo uma lista feita por Kelly Waters, e ao término algumas considerações minhas...

1. Rendimento
A característica iterativa do Desenvolvimento Ágil significa que funcionalidades são entregues incrementalmente, possibilitando o retorno de alguns benefícios à medida que o desenvolvimento do software prossegue.

2. Time-to-market
Acredita-se que 80% de todos os líderes de mercado foram os primeiros a criarem um nicho específico (melhor discutido no livro Estratégia do Mar Azul, e no Artigo The PDMA Handbook of New Product Development). Assim como o rendimento trazido através de entregas constantes e incrementais, a filosofia do Desenvolvimento Ágil permite aproveitar oportunidades mais rapidamente, seguindo tendências e apostando em mercados pouco explorados.

3. Qualidade
Um princípio chave do Desenvolvimento Ágil é a noção de que testes estão inseridos em todo o processo de desenvolvimento, permitindo inspeções regulares do produto em funcionamento à medida que ele está em desenvolvimento. Isto também permite que o dono do produto faça ajustes caso necessário, dando a visibilidade sobre questões de qualidade de software muito cedo no desenvolvimento.

4. Visbilidade
A participação efetiva do usuário ou cliente no ciclo de desenvolvimento do produto é um dos principais princípios descritos no Manifesto Ágil de uma forma colaborativa. Possibilidanto a real visibilidade do projeto para stakeholders importantes, através de um ambiente informativo que permite enxergar objetivamente "Onde estamos" e "Para onde Vamos" no projeto. Expectativas podem ser facilmente gerenciadas desta maneira, e o envolvimento de todos torna-se maior à medida que equipe, gerência e clientes possuem as mesmas informações para tomada de decisão.

5. Gerência de Risco
Pequenos incrementos no produto permitem à equipe e ao Produtc Owner identificar problemas mais cedo e mais facilmente fazer os ajustes necessários responsando à mudança. A visibilidade clara e objetiva no Desenvolvimento Ágil auxilia nas decisões de mudança o mais cedo possível, enquanto ainda da tempo de criar algum material para que o produto seja lançado.

6. Flexibilidade / Agilidade
No desenvolvimento de software tradicional, uma grande especificação inicial é criada com o intuíto de mostrar aos clientes o quão caro é fazer qualquer tipo de mudança no projeto, especialmente no momento em que ele já estiver em andamento. Em medo a alterações de escopo e projetos que nunca terminam, resiste-se a mudanças criando comitês para controlar qualquer item que possa sair da especificação inicial. Não funcionamos deste jeito. Embrace change!!
Seguimos um modelo onde mudanças são esperadas. Afinal, a única certeza que temos neste mundo é a mudança. Obviamente que para isto ocorrer de forma coerente, é necessário que um stakeholder entenda estes princípios fazendo ajustes necessários, modificando expectativas e requisitos iniciais do sistema.


7. Controle de Custos
Muitos projetos em desenvolvimento possuem o conceito de Custo Fixo - Escopo mutável, bastante importante para possibilitar os princípios acima.


8. Satisfação do Cliente
O envolvimento ativo do cliente ou usuário, a visibilidade dada sobre o progresso e ainda a flexibilidade à mundança quando mudanças são necessárias criam um vínculo muito maior entre empresa e cliente, ampliando ainda mais a satisfação dos stakeholders. Este efeito colateral é pode ser de suma importância para a perenidade da empresa e futuros contatos de negócio.


9. O produto correto
Incorporando a mudança aos projetos, permitindo que requisitos emerjam das necessidade e oportunidades de agregar valor ao cliente, a equipe termina por construir o produto mais próximo o possível ao que o cliente precisa. É comum encontrar casos em que um projeto mesmo sendo bem sucedido do ponto de vista do Desenvolvimento, acaba nem sendo utilizado pelo cliente devido à mudanças ocorridas nas necessidades dos usuário finais. Em Desenvolvimento Ágil a ênfase é absolutamente em construir o produto correto.

10. Mais agradável!
O ambiente de envolvimento, cooperação e colaboração criado num projeto Ágil permite uma experiência muito mais agradável para a maior parte das pessoas. Ao invés de grandes especificações, nós discutimos requisitos em workshops. Ao invés de relatórios gigantescos, nós colaboramos ao redor de um processo de discussão mais simples e informal. Ao invéis de longos e custosos planos de trabalho e comitês de controle de mudanças, nós discutimos o que é melhor para o produto e para o projeto, ampliando o poder de decisão da equipe.
Você espera que seu time torne-se altamente motivado? Deveria começar a prestar atenção no que estamos discutindo há anos...


Considerções:

Particularmente vi pouca ênfase do Mrs Waters no que diz respeito ao perfil auto-gerenciável das equipes no desenvolvimento Ágil. Um modelo que permita a interação contínua entre as pessoas faz com que todos na equipe cresçam de uma forma que ninguém espera, já que são obrigados a conversar, entrar em acordos, tomar decisões difíceis e entender a liguagem existênte na área de Desenvolvimento de Produtos, e não apenas de software.
Caso sua empresa queira que um profissional evolua no decorrer de sua carreira, e lembrando das 12 Competências para um bom profissional de TI, o caminho e deixá-lo crescer através das próprias pernas, possibilitando apenas um ambiente em que ele exerça faculdades além do simples desenvolvimento de software.
O poder colaborativo dos projetos Ágeis traz à empresa uma questão nova relacionada ao modelo de gerenciamento que existe há alguns anos. Dar aos desenvolvedores o poder de decisão e a capacidade de responder rapidamente a mudanças de mercado acarretará um demanda por modelos mais enxutos de gerenciamento e controle da instituição, para que se possa atender a velocidade com que os projetos serão entregues ao mercado. Será necessário que a empresa como um todo suporte o modelo Ágil: RH e planejamento estratégico devem estar alinhados para trabalharem em conjunto com as equipes. Acredite, o trabalho não é fácil, mas muito motivador.

Anti Padrões de motivação de equipes

Saudações!
Seguindo a linda Anti-Patterns (já escrito sobre Testes), e voltando ao post sobre a diferença entre times e equipes (lembram do video dos malucos do All Black?) vou tratar sobre os padrões de gerência e posturas que uma empresa pode tomar para minar completamente a formação de equipes auto-gerenciáveis.
Mais uma vez, influenciado por Paul Glen, escrevo uma lista:

• Exclusão do processo de tomada de decisão


• Inconsistência


• Monitoramento excessivo


• Foco na tarefa, e não em objetivos


• Motivadores externos desalinhados


• Deadlines artificiais


• Desinteresse organizacional


• Equipes sem habilidade

Exclusão do processo de tomada de decisão
Dada a própria característica de nosso trabalho, em que muitas vezes um desenvolvedor possui muito mais conhecimento sobre sua atividade que seu gerente, deixá-lo de lado durante a tomada de decisão é, antes de mais nada, a afirmação de que este profissional é dispensável, e que sua opinião pouco importa no progresso de um projeto.
Por favor entendam, não estou dizendo que numa equipe gigante todos tenham que ter voz ativa na tomada de decisão (e também nao acredito em equipes grandes dentro de um projeto...), mas a equipe técnica ou um representante deve ser consultado quando o assunto forem medidas que impactam diretamente no projeto.
Já passei por essa experiência, e realmente é incômodo não ser ouvido a respeito de decisões que influenciam diretamente em seu trabalho. O sentimento é realmente esse: dispensabilidade. E a reação é clara: tratando-me como um recurso substituível não existe necessidade de cumprimento de metas e prazos ou de comprometimento.

Inconsistência
"Mesmo peso, duas medidas"
Complicadíssimo lidar com situações em atitudes tomadas contradizem comportamente pré-determinados. Como líderes, ou como empresa, uma coisa deve ser clara: tenha corrones de assumir o que for determinado para a equipe, e evite ao máximo contradizer-se, pois assim conseguirá um apoio muito maior de todos.

Monitoramento Excessivo
Isso é claro e já bastante batido: microgerenciamento não é produtivo. Acreditar que manter os olhos sobre os ombros de seus empregados 24horas por dia vai torná-los mais produtivos é um conto de fadas. Além de sempre causar a impressão de que a empresa não confia na equipe, que precisa ser monitorada para que seja produtiva. Um conselho: a procrastinação sempre vence. A equipe vai encontrar um jeito de tornar-se improdutiva, nem que seja fingir estar trabalhando.
Já ouvi discussão na lista xpRio sobre a microgerência executada em scrum/xp/lean, mas é completamente diferente pelo princípio das Equipe Auto Gerenciáveis. Todos são responsáveis pela execução, decisões e controle do projeto. Microgerência do projeto e não das pessoas, esse é o ponto!

Foco na tarefa, não nos objetivos
Acredito que apenas os mais cabeças-duras ainda não entenderam isso. Para aqueles que ainda não entenderam, vai uma lista algumas coisas atuais (outras nem tanto) para estudar:

• Boletim Harvard Business Online


• Dr. Willian Edwards Demin: frases e videos


• Leading Geeks ou o livro


• Personal MBA

Se você, como um líder, direciona o desenvolvimento apenas através de tarefas, sem que a equipe tenha conhecimento dos objetivos do projeto, talvez após ler os links acima você acabe entendendo.
É necessário que a equipe tenha a visão de onde se pretende chegar com o projeto. Nisso o Desenvolvimento Ágil dá um salto na tentativa de aproximar a equipe do cliente, criando uma visão e metáforas do projeto.
Tarefas devem ser encaradas como passos para alcançar objetivos. Paul Glen faz uma ótima comparação:

Without any understanding of the goals for a task, geeks start to feel like technology vending machines, dispending solutions on demand. Under these circunstances, they engage in the creative work task with the same exciment as a soft drink vending machine dispensing a drik. It may work, but don´t expect anything more than you ask for, and you may not get anything at all

Motivadores externos desalinhados
Motivação é um assunto complicado, e pretendo tratar melhor em outros posts.
Mas é importante verificar de que maneira a equipe está sendo recompensada por sua produtividade, tomando muito cuidado para que este processo não perturbe a convivência do grupo. Valorizar recompensas individuais em detrimento dos objetivos do grupo é assinar o atestado de problemas internos, já que será criado um sentimento não coeso de disputa entre os membros da equipe, o que é péssimo para o projeto.

Deadlines Artificiais
Tudo precisa ter um fim. O sentimento de completude de uma tarefa deve ser real, para que possamos passar para uma nova etapa do projeto. Assim, de qualquer maneira, a idéia de prazos que não são cumpridos e datas limites que não são respeitadas fazem com que a equipe não se motive para alcançar um objetivo. Não existe nem o desafio de completar uma tarefa, já que caso ela não seja completada, os prazos serão extendidos.
Aqui existe forte influência do Desenvolvimento Ágil e as iterações curtas. Cria-se um microcosmo de uma iteração em que toda a equipe está focada em realizar os objetivos que ela se propôs a atingir. Insconscientemente a equipe estará comprometida pois os prazos não se alteram. "Done is done", segundo Ken Shwaber.

Desinteresse Organizacional
A falta de significado é a maior barreira para a equipe. Isto é, uma empresa que demonstra não ter interesse em um projeto, é o principal motivo para que ele vá de mal a pior.
IMPORTANTÍSSIMO: Nunca subestime o poder de observação de uma equipe. Mesmo não informando a equipe de que o projeto será descontinuado, cancelado ou deixado de lado, é simples de perceber quando um projeto não está mais nas graças da empresa. E pior ainda, não faça com que sua equipe trabalhe em um projeto já cancelado, apenas para deixa-los trabalhando. É a maneira mais fácil de perder todas as pessoas da equipe e eliminar qualquer respeito que a equipe tenha pela empresa ou qualquer outro projeto futuro.

Equipes sem habilidade
Quando um projeto é criado sem que a equipe tenha as capacidades técnicas e gerenciais de alcançar os objetivos é certo seu insucesso.
Um azarão com chance de vitória é excitante; uma derrota garantida não é.

12 Competências para Produtividade

Atualmente estou empenhado em terminar a leitura do livro Leading Geeks de Paul Glen, com a intenção de visualizar novos rumos em minha carreira, mais focado numa área gerencial.
Me deparei com esse livro que tem muito a dizer a respeito de nossa postura como profissionais de TI e de que maneira podemos trabalhar para atingir da melhor forma possível equipes de desenvolvimento.
E sabe do que mais?? Tem muito a ver com Desenvolvimento Ágil!

Paul Glen traça o perfil do profissional de TI (gerente ou não) como uma pessoa que deve ser encarada em sua individualidade e respeitada por seu conhecimento. Assim, pode-se criar um ambiente motivador e que possa retirar o máximo de cada pessoa da equipe. Um líder deve saber encontrar maneiras de dar a liberdade necessária para cada um, e atender necessidades básicas (técnicas, sociais, financeiras e ideológicas) para chegar a esse objetivo.

Mas como medir a produtividade de alguém?? Quando determinar se um profissional está ou não agregando valor à empresa?

No livro, são definidas 12 Competências que podem ser utilizadas para a formação de um bom (porque nao ótimo) profissional de TI. Quem de vocês se identifica nesse perfil?
Minha intenção, no primeiro momento, não é criticar, mas apresentar a constatação do autor.

As 12 Competências para a Produtividade

1. Qualificação Técnica
2. Produtividade Pessoal
3. Habilidade de gerenciar múltiplas tarefas simultaneamente
4. Habilidade de descrever o contexto de negócio em que o trabalho(técnico) está inserido
5. Habilidade de forjar compromissos entre negócio e varientes técnicas
6. Habilidade de gerenciar o relacionamento com clientes
7. Habilidade de gerenciar equipes técnicas
8. Habilidade de executar e manter políticas positivas de relacionamento
9. Habilidade em ampliar o relacionamento com clientes
10. Habilidade de influenciar outros para tornálos produtivos
11. Habilidade de gerenciar ambiguidades
12. Habilidade de gerenciar tempo e estimativas
    

Descreverei sucintamente todas elas:

1. Competência técnica
A mais simples de todas. E normalmente a única competência levada em consideração durante a contratação de um profissional. É a capacidade de utilizar o conhecimento técnico aplicado às necessidades de sistema. Importante também é a abrangência que este conhecimento possui. Ex: um DBA deve ter conhecimento técnico em mais de um banco de dados, senão ele pode estar fadado a um mundo bastante restrito de possibilidades.

2. Produtividade Pessoal
Dificilmente mensurável, mas muito importante. Não diz respeito à qualidade do trabalho produzido, mas à quantidade de esforço que se pode empenhar na realização de uma tarefa. O importante aqui é garantir que o profissional tenha a consciência de sua própria velocidade em realizar tarefas, isto é, qual o seu estilo de trabalho: rápido ou lento.

3. Habilidade de gerenciar múltiplas tarefas simultaneamente
Fato: não é novidade que projeto em produção geram demanda para desenvolvedores independentemente de prioridades (sim, se vc nao usa desenvolvimento ágil, isso é muito comum), o que exige do profissional a capacidade de deixar uma tarefa pela metade, resolver uma emergência e voltar do ponto em que havia parado (nota: difícil??)

4. Habilidade de descrever o contexto de negócio em que o trabalho(técnico) está inserido
Bom seria se todos os funcionários tivessem noção de regras de negócio. Esta competência diz respeito à capacidade de utilizar o conhecimento técnico para vislumbrar a agregação de valor ao negócio que a tecnologia pode trazer.

5. Habilidade de forjar compromissos entre negócio e varientes técnicas
Talvez a melhor definição desta capacidade esteja em comunicação. em todas as esferas, possibilitando que o profissional transite nos mais diversos ambientes do projeto: sejam áreas técnicas ou estratégicas, conseguindo assim garantir o entendimento de todos quando à solução proposta a um sistema

6. Habilidade de gerenciar o relacionamento com clientes
Aqui fica bem claro o papel do lider em mostrar a maneira que se deve tratar todos os clientes da equipe. Apesar da natureza individualista e instrospectiva dos profissionais de TI, é imprescindível ter desenvoltura e tato ao lidar com clientes.

7. Habilidade de gerenciar equipes ténicas
Somente poucos problemas técnicos e estratégicos podem ser resolvidos por apenas uma única pessoa. Isto quer dizer que, no ambiente de TI, o trabalho em equipe é extremamente necessário devido à complexidade da função. Assim, o papel de motivar e gerenciar equipes é importantíssimo (para gerentes, obviamente).

8. Habilidade de executar e manter políticas positivas de relacionamento
"Nenhum homem é uma ilha". Leve isso a sério!

9. Habilidade em ampliar o relacionamento com clientes
Capacidade de identificar necessidades e oportunidades para expandir a área de atuação com os clientes.

10. Habilidade de influenciar outros para tornálos produtivos
Inspiração e liderança estão muito ligadas a essa habilidade.

11. Habilidade de gerenciar ambiguidades
O quão facilmente o profissional consegue lidar no ambiente adverso que pode ser a Tecnologia? Como ele responde a interpéries durante o projeto?

12. Habilidade de gerenciar tempo e estimativas
(tradutor: aqui acredito que seja a capacidade de autoconhecimento que o profissional deve ter, e a maneira com que ele consegue gerir seus horários, compromissos e estimativas firmadas. Assim como a maneira dele portar-se ao descumprir uma delas.)


É isso... percebam que características técnicas são apenas uma pequena parte do complexo modelo de Paul Glen.