quarta-feira, junho 25, 2008

Scrum Master e sua importância - "Antes de construir software, construir pessoas!"

Pretendo aqui ajudar a esclarecer a importância do Scrum Master, qual seu papel em uma organização de desenvolvimento de software que aprende e como devem ser suas características de liderança.

Resolvi escrever esse artigo baseado em duas inspirações: A primeira é a série de livros fenomenais que descrevem em detalhes o Sistema Toyota de Produção (ou Produção Lean), sua filosofia e cultura(os livros são: The Toyota Way, The Toyota Way Fieldbook, Toyota Talent e Toyota Culture). A segunda inspiração teve como base os debates ocorridos nas listas sobre desenvolvimento ágil, tratando sobre se o scrum master é necessário e se o scrum master é uma função única.

Quando falamos do Scrum Master não estamos falando de uma função meramente técnica. Ela é uma função de liderança. Porém, uma liderança diferente daquela encontrada ainda em muitas empresas: o estilo de gestão comando e controle. Estamos falando de uma liderança servidora. Podemos fazer uma analogia com outras organizações, como por exemplo as religiões judaica e cristã protestante. Nessas organizações, uma premissa fundamental é que os fiéis podem ter um contato direto com o Divino, sem necessidade de intermediários. Porém, mesmo assim encontramos as figuras dos rabinos e pastores. Para que eles servem? Eles são o que considero um modelo da liderança servidora. O papel deles não é dizer que só através deles se chega à salvação. Seu principal objetivo é ajudar e servir à sua comunidade, da melhor maneira possível. Ser um guia espiritual e um visionário, que busca compreender e vivenciar a cada dia que passa um pouco mais sobre sua filosofia e transmiti-la àqueles aos quais servem.

O Scrum Master também é um líder nesse sentido. E o capítulo 15 do livro "The Toyota Way", de Jeffrey Liker, me ajudou a compreender a diferença profunda entre os vários tipos de líderes que encontramos e qual é o líder esperado em empresas que buscam o pensamento ágil, enxuto e de uma "Learning Organization". O capítulo explica o Princípio número 9 do Modelo Toyota: "Crie líderes que entendem em profundidade o trabalho, vivam a filosofia e a ensinem para os outros".

Liker descreveu as diferentes formas de liderança através de uma matriz com duas dimensões e que definem quatro possíveis tipos de líderes. A figura abaixo ajuda a entendê-la.

A primeira dimensão define que o líder pode dirigir de cima para baixo através de regras ou então de baixo para cima em um estilo mais participativo para desenvolver as pessoas de modo que elas pensem e tomem as decisões sozinhas.

A segunda dimensão diz que um líder pode ter um entendimento profundo do trabalho ou conhecimento gerencial genérico. Em muitos lugares, de acordo com Liker, existe ainda a noção de que o gerente bem sucedido típico é aquele que tem um MBA e que pode ir para qualquer negócio e instantaneamente trabalhar nele olhando para números e usando princípios de gestão genéricos. (Nenhum gerente da Toyota aceita essa noção. Todos conhecem e inclusive já trabalharam nas organizações de engenharia e no chão de fábrica).

Vamos então entender os quatro tipos possíveis de gerentes:

Gerente burocrata (Top-down e com conhecimento genérico de gestão): é o menos eficaz de todos. Segundo Liker caracteriza a maioria dos gerentes americanos atuais(será que o Brasil é igual?). Como uma pessoa pode ser eficaz tentando gerenciar uma organização de cima para baixo sem ter um conhecimento íntimo e profundo do que está acontecendo e de como esse trabalho é realizado? Eles só possuem uma chance e a usam: criam toneladas de regras e políticas e medem a performance com base nessas regras e políticas. Isso leva a um gerenciamento dirigido por métricas que tira o foco da satisfação dos clientes ou em construir uma organização que aprende.

Facilitador de grupos (Bottom-up e com conhecimento genérico de gestão): Este tipo de gerente é aquele que se baseia na crença de que se um líder possui fortes habilidades de facilitação, ele pode motivas os empregados a trabalhar em conjunto rumo a um objetivo em comum. Facilitadores são catalisadores, porém não conseguem ensinar ou guiar as pessoas em relação ao que devem fazer no dia a dia. Esses líderes podem ser ótimos para motivar equipes e ajudá-las a se desenvolver. Mas eles realmente podem fazer coaching e mentorizar outros naquilo que eles não entendem? Eles nem mesmo possuem a experiência para julgar as contribuições e o trabalho dos seus subordinados.

Mestre de Tarefas (Top-down e com conhecimento profundo do trabalho): Esse tipo de gerente trata os subordinados como marionetes, puxando todas as cordas. Isso se torna um grande fardo, pois uma corda puxada de forma errada pode fazer o processo de trabalho entrar em colapso. Esse líder costuma desconfiar de outros com menos experiência. Como o gerente burocrata, ele dará ordens, mas ordens para fazer tarefas específicas exatamente como ordenado. Essa é a definição de micro-gerenciamento.

Construtor de Organizações que aprendem (Bottom-up e com conhecimento profundo do trabalho): Por terem uma combinação de entendimento profundo do trabalho e a habilidade para desenvolver, mentorizar e liderar pessoas são respeitados por seu conhecimento técnico e são seguidos por suas qualidades de liderança. Esses líderes raramente dão ordens. De fato, esses líderes frequentemente lideram e mentorizam através de questionamentos. Esse líder fará perguntas sobre uma situação e sobre a estratégia da pessoa ou da equipe para resolvê-la, mas não darão nenhuma resposta a essas questões apesar de terem o conhecimento.

Os grandes líderes da história da Toyota possuem as seguintes características:

- Focados numa visão de longo prazo
- Nunca desviavam dos princípios do "Toyota Way" e se modelavam em torno desses princípios para todos verem. Adotavam uma postura de professores e mentores diariamente.
- Cresceram na hierarquia através do trabalho de chão de fábrica e/ou de engenharia e sempre continuaram indo ao local atual onde o trabalho de valor agregado é feito.
- Viam problemas como oportunidades para ensinar e mentorizar as pessoas.

Uma frase comum ouvida na Toyota é: "Antes de contruirmos carros, construímos pessoas". O objetivo dos líderes na Toyota é desenvolver as pessoas para que estas sejam fortes contribuidores para a empresa e que estejam imbuídas dos princípios de auto-gestão e de melhoria contínua realizada por todos os membros de uma equipe.

O grande desafio do líder é ter as três seguintes características: a visão de longo prazo de saber o que fazer, o conhecimento de como fazer e a habilidade de desenvolver pessoas para que possam entender e fazer seu trabalho de forma excelente. O benefício dessa dedicação é mais profunda e duradoura para a competitividade de uma empresa do que usar um líder apenas para resolver problemas financeiros imediatos ou tomar uma decisão para um situação determinada de curto prazo.

É interessante notar que outro conceito usado na Toyota é o de "não fazer compromissos". Isso significa que eles questionam continuamente o "ou". Discussões - como, por exemplo, o que é melhor... um scrum master com habilidades para lidar com pessoas "OU" um scrum master técnico? - são respondidas com: o melhor é ter um gerente de pessoas "E" um gerente técnico. Ou então: o Scrum Master deve fazer só atividades de facilitação e remoção de impedimentos "OU" fazer atividades técnicas? A resposta Toyota seria: deve fazer ambos :-) . Muitas vezes criamos dicotomias que podem ser implodidas com uma análise mais "lean".

A conclusão então é: o Scrum Master é um papel essencial. Precisamos de figuras de liderança servidora nas organizações criadas por seres humanos. O melhor tipo de líder para se tornar um Scrum Master é o construtor de organizações que aprendem (lideram bottom-up e têm conhecimento profundo sobre desenvolvimento de software, isto é, são líderes servidores/professores que respiram e amam o que fazem).

Espero que essas dicas vindas da precursora do pensamento enxuto (Lean Thinking) possam ajudar a entender melhor o papel e a importância do Scrum Master ou de um líder de projetos numa organização de TI.

Vamos então seguir o mesmo caminho: "Antes de construir software, devemos construir pessoas!"

Marcadores:

quinta-feira, junho 12, 2008

Considerações sobre o RSDC 2008 em Orlando, EUA

Agora que estou de volta ao Brasil, vou compartilhar importantes informações e insights que tive ao assistir a dezenas de palestras na Rational Software Development Conference 2008 realizada em Orlando - Flórida - Estados Unidos.

Começando pelas palestras dos keynote speakers Danny Sabah, Gerente Geral da IBM Rational; Colleen Arnold, Gerente Geral da IBM Global Services; Steve Mills, executivo do IBM Software Group e Grady Booch, um dos três amigos. O que podemos tirar de ponto mais importante, especialmente para a comunidade de desenvolvimento ágil é: a IBM globalmente está adotando processos ágeis de desenvolvimento. Iniciou e já está em pleno vapor o seu uso nas equipes que desenvolvem os produtos da IBM como o WebSphere, produtos Rational, etc.

As palestras sobre Jazz mostraram claramente que o próprio produto Rational Team Concert foi desenvolvido com base em técnicas ágeis de desenvolvimento (e o Jazz foi construído usando o Jazz!). Colleen Arnold da IBM Services também declarou que já está em andamento o processo de transformação cultural para adoção de agile nas divisões de serviços. Scott Ambler, Erich Gamma, entre outros são líderes nesse processo de transformação dentro da IBM. Eles estão mentorizando equipes IBM ao redor do mundo no uso de desenvolvimento ágil com escala.

Creio que esse é mais um dos exemplos de uma gigante de software e de serviços ligados a Tecnologia da Informação que estão embarcando no uso global dos processos ágeis.

O segundo ponto importante, relacionado ao novo produto Rational Team Concert, é que agora temos uma forma ainda mais simples de obter agilidade com governança. Há muita gente que ainda acredita que existe uma dicotomia entre agilidade e governança, o que é um mito. Já tratei desse assunto em um artigo no meu blog.

Com a ferramenta Rational Team Concert podemos dizer que essa realidade da agilidade com governança se tornou ainda mais simples de atingir. Sua idéia é de ser uma robusta ferramenta de ALM (Application Lifecycle Management) colaborativa. A palavra colaboração aí é a grande novidade dentro desse novo produto. Além disso, o RTC possui um fantástico recurso que, feita a configuração e customização do processo, faz com que a equipe tenha (isso mesmo, seja obrigada!) que realizar atividades (work items) do processo que foram definidas como obrigatórias para poder continuar o seu trabalho. A ferramenta não só lembra as tarefas, como também obriga o time a realizar aquelas fundamentais. Mas é importante reforçar: a ferramenta pode ser configurada para apenas lembrar quais são as tarefas e não obrigar os times a fazê-las. Esse recurso é útil para empresas que precisam seguir padrões de governança como SOX, Cobit, etc e desejam definir atividades de compliance como obrigatórias dentro do processo. Mas todas as atividades podem ser opcionais, se assim for o desejo da equipe e/ou empresa!

O RTC também conta com um sistema de controle de incidências integrado com controle de versões, wiki, sistema de integração contínua e um servidor portal que gera as mais diversas métricas, relatórios e informações executivas sobre os projetos. É o nirvana dos desenvolvedores e gerentes de projeto!

E, se não bastasse, mais uma outra ótima informação para a comunidade ágil. O Rational Team Concert já vêm com dois processos pré-definidos na "caixinha": são eles o Scrum e o OpenUP. Além é claro da flexibilidade que o RTC fornece para a equipe configurar seu próprio processo.

Posso resumir então os principais toques e insights dessa conferência em:

1 - A IBM, como todas as outras gigantes produtoras de software, já embarcaram e entraram de cabeça no mundo do desenvolvimento ágil... só falta você :-) .

2 - O lançamento oficial do Rational Team Concert eleva a um novo patamar a necessária integração entre Agilidade e Governança. A governança agora pode existir sem muitos empecilhos e burocracia, graças à automação proporcionada pela ferramenta.

Com certeza, duas grandes notícias para a indústria de Tecnologia da Informação do Brasil e do mundo!

Futuramente escreverei artigos descrevendo em mais detalhes as mais importantes funcionalidades do Rational Team Concert e como estas auxiliam na adoção de processos ágeis no desenvolvimento de software.

Marcadores:

sexta-feira, junho 06, 2008

Fotos com líderes e visionários do desenvolvimento de software - RSDC 2008 Orlando EUA - Parte 2

Continuando a série de fotos tiradas com os líderes e autores importantes no mundo de desenvolvimento de software. Temos também algumas fotos com amigos da IBM Rational Brasil.


Foto com Terry Quatrani (autora dos livros "Visual Modeling with Rational Rose and UML" e "Visual Modeling with Rational Software Architect and UML"):



Foto com Erich Gamma (um dos membros da GoF - Gang of Four - co-autor do livro "DEsign PAtterns" e líder do projeto Jazz e Rational Team Concert da IBM Rational):




Foto com Peter Eeles (co-autor do livro "Building J2EE Applications with the RUP"):






Foto com Kurt Bittner (co-autor dos livros "Use Case Modeling" e "Managing Iterative Software Development Projects"):






Foto com Per Kroll (co-autor do livro "Agility and Discipline Made Easy: Practices from OpenUP and RUP" e "RUP Made Easy"):





Foto com Joe Marasco (autor do livro "The Software Development Edge"):







Foto com Wagner Arnaut (IBM Rational Brasil):




Foto com Paulo Henrique Cruz nos Estúdios da Universal(IBM Rational Brasil):




Foto com Callado (IBM Rational Brasil):


Marcadores: ,

terça-feira, junho 03, 2008

Fotos com líderes e visionários do desenvolvimento de software - RSDC 2008 Orlando EUA

Caros,


No primeiro dia assisti a palestras de grandes nomes do desenvolvimento de software. Nesse post vou apenas colocar algumas das fotos minhas com os grandes papas da engenharia de software atual. Mais tarde, quando eu tiver mais tempo(pois já está tarde e preciso acordar cedo para o segundo dia de evento... he, he!), vou postar sobre os temas que assisti. Amanhã e quarta vou assistir a palestras de Erich Gamma, Per Kroll, Terry Quatrani, Kurt Bittner, Joe Marasco e Peter Eeles. Aguardem mais fotos!!!

Creio que principalmente quem trabalha, como eu, durante 8 a 10 horas por dia tendo como base a idéia desses mestres ( e ainda estuda, prepara aulas, leciona e discute esses conceitos com os alunos por mais 4 a 6 horas por dia podendo totalizar facilmente umas 16 horas por dia!!!) é que terá a noção da grande honra, emoção e alegria que é poder ouvir de perto, conversar e trocar idéias com esses gigantes do mundo de desenvolvimento de software.

Agora chega de devaneios... vamos às fotos :-) !!!


Foto com Grady Booch (um dos Três Amigos, co-criador da UML e autor dos livros "Object-Oriented Analisys and Design with Applications" e "UML Users Guide"):





Foto com Ivar Jacobson (Outro dos três amigos. Co-autor da UML, autor de livros como "UML Users Guide" e criador do conceito de casos de uso):




Foto com Scott Ambler (Autor de livros como "Agile Modeling", "Object Primer" e "Refactoring Databases"):





Foto com Murray Cantor (Autor do livro "Software Leadership" e líder do plugin RUP para System Engineering):




Foto com Ian Spence (co-autor com Kurt Bittner dos excelentes e fundamentais livros "Use Case Modeling" e "Managing Iterative Software Development Projects"):




Marcadores: ,


Veja as Estatísticas