rafanoronha.speaking()

Ontem o dia de trabalho terminou com uma conversa entre o André, o Felipe e eu.
Na conversa entrou em pauta gestão de pessoas e coisas do tipo.

Quando o assunto é a responsabilidade sobre problemas existentes e erros cometidos, sou da seguinte opinião:

O único erro condenável é o de não errar.
Se você não erra, isto quer dizer que:

1. Você não se arriscou
2. Você errou mas não percebeu o erro
3. Você errou mas não assumiu a responsabilidade
4. Você nunca erra. Será mesmo?

Exceto pelo erro da omissão, todos os outros erros são bons.
Errar te dará oportunidade de aprender, corrigir e evoluir.
Não errar, por outro lado, significa deixar de aprender e consequentemente deixar de melhorar.

Um ponto importante a ser citado é o seguinte:
É muito importante que a sua equipe valorize a transparência sobre a responsabilidade de problemas e erros cometidos.
Assumir um erro ou um resultado ruim deve ser visto com bons olhos, pois isto só tem a agregar com o comprometimento, dedicação e união da equipe.
Aprendi isto com o André, que constantemente assume os erros dele, além de ter uma clara percepção dos erros cometidos pela equipe como um todo.

Meu último erro é bem recente: não garanti o nivelamento das expectativas de auto-organização e o senso de responsabilidade da minha atual equipe, sobre o projeto em que estamos atuando.
Percebi o erro, sinalizei, e já estamos trabalhando para corrigí-lo.
E o aprendizado decorrente deste erro será de grande valor.

E você, qual foi o seu último erro?

Este é o segundo post da série Agile na Cascata.

Outro dia li uma frase interessante no blog do Phillip Calçado:
Você pode ter de vestir uniforme de marinheiro, mas ainda é um pirata.

O objetivo deste post é chamar a atenção para o fato de que nem tudo é oito ou oitenta.
Enquadrar-se em um modelo não significa estar fadado a sofrer com as diculdades implicadas pelo modelo, ou limitar-se aos resultados normalmente alcançados sob este modelo.

O sucesso de um projeto depente diretamente de profissionais competentes.
Diversas outras variáveis podem interferir em seu resultado.
Mas nada é tão importante quanto a competência e os interesses das partes envolvidas.

Qualquer desenvolvedor de software competente terá arrepios ao ouvir falar do modelo de fábrica de software.
No entanto, nossa experiência tem mostrado que é possível sim atuar com sucesso sob este modelo.
Aqui a gente entra no escopo do primeiro valor do manifesto ágil:

Individuals and interactions over processes and tools

Se a sua equipe é formada por profissionais que conhecem os problemas existentes no modelo de fábrica, o fato é que estes profssionais possuem o discernimento necessário para interpretar e resolver problemas decorrentes do relacionamento entre cliente e fornecedor.

No dia-a-dia de projetos a equipe aprenderá as lições a serem aprendidas, e a tendência é que o relacionamento com o cliente melhore cada vez mais, a medida em que o fornecedor demonstra estar interessado em prestar um serviço diferenciado.

Resumindo: coloque bons profissionais para trabalhar, dê liberdade e autonomia a eles, amadureça o relacionamento com o cliente à medida em que algumas lições são aprendidas, e bons resultados tendem a aparecer.

Curiosidade:
Algo interessante na experiência de atuar em projetos de fábrica é o fato de que os clientes realmente acreditam que o modelo faz algum sentido.
É realmente divertido escutar e confrontar as opiniões dos gestores destes clientes.

Este é o primeiro post da série Agile na Cascata.

Aqui tentarei contextualizar o cenário que envolve as experiências que me levaram a escrever esta série de posts.

Nossa equipe

O SDC conta hoje com quase cem profissionais.

Somos um time multidisciplinar e que apóia o processo de desenvolvimento de modo iterativo e incremental.

O maior patrimônio de nossa equipe é a cultura:
Não possuímos níveis hieráriquicos rígidos, não tratamos nossos profissionais como recursos, não possuímos gerentes de projetos que micro-gerenciam atividades.
Isto porque valorizamos nossos profissionais e acreditamos que eles são completamente capazes de cuidar da organização de seus projetos.

Um de nossos maiores desafios tem sido escalar esta cultura, devido ao fato da equipe vir crescendo bastante para dar vazão às demandas de nossos clientes.

Nossos serviços

O cliente

Esta série de posts é um apanhado das minhas experiências dentro do SDC.
Venho atendendo a um único cliente desde minha chegada ao SDC.
Trata-se de uma instituição financeira de grande porte.

Como eu disse no post de inauguração da série, grandes corporações estruturaram-se de modo que área de negócios e área de TI se conflitem, baseando seu relacionamento em um processo rígido e burocrático.

Agile na Cascata?

A motivação para compartilhar a experiência de minha equipe vem do fato de atuarmos em um cenário ainda um tanto quanto estranho para os partidários da Agilidade.

Nós reconhecemos a dificuldade de implantar Agile no cenário de outsourcing, (des)amparados pelo modelo de fábrica de software.
No entanto, temos tido sucesso na adaptação da cultura e práticas de agilidade a este cenário, e é sobre algumas das lições aprendidas que estarei escrevendo nesta série de posts.

Nos próximos textos a serem publicados por aqui, estarei compartilhando algumas experiências vivenciadas por minha equipe, de algum tempo pra cá.

A idéia é mostrar como nós temos atendido demandas de projetos de software de um grande cliente do setor financeiro.

É de conhecimento da comunidade que grandes instituições financeiras tipicamente possuem uma área de TI burocratizada, que viciou-se em atender a área de negócios através de um modelo rígido e baseado em ciclos, também conhecido por waterfall.

O que estariam eu e minha equipe, agilistas ferrenhos, desempenhando dentro deste cenário?
Nos próximos posts!

Este texto está disponível apenas em Inglês.