Por Maria Angélica Castellani
Recentemente li este artigo de James Carilli e me pareceu muito interessante como orientação inicial para quem está pensando em mudar. É um guia breve de como poder alcançar os benefícios do Agile seguindo certa disciplina. Espero que seja útil para todos vocês.
Ele sugere sete estratégias executivas para fazer a transição para o Agile. Elas são:
- Estratégia 1: Garantir / fornecer suporte de gestão
- Estratégia 2: Empoderar o negócio para dirigirir o trabalho
- Estratégia 3: Abraçar métodos ágeis
- Estratégia 4: Desenvolver planos multiníveis
- Estratégia 5: Considerar um coach Agile e treinar todo mundo
- Estratégia 6: Começar pequeno e obter sucesso mais cedo
- Estratégia 7: Criar contratos Agile
A chamada para a ação é clara: projetos ágeis são bem sucedidos três vezes mais frequentemente do que os projetos não Ágeis (Cohn, 2012).
Mas onde um executivo deverá focar sua atenção para facilitar um arranque e um final bem sucedido de um programa Agile?
Para ajudar a responder a essa pergunta, James Carilli realizou uma pesquisa através de discussões informais e de entrevistas com diversos gerentes de programas de projetos ágeis em todo o mundo. Completou sua pesquisa com informações de empresas de produtos e serviços, leitura de livros, pesquisas na Internet, entre outros.
Com base nesta pesquisa e experiência do autor, é altamente recomendável que as organizações considerem a aplicação dessas estratégias para realizar projetos ágeis com maior sucesso.
Como característica comum, além da disciplina, James encontrou que a transição para Agile precisa de uma mudança cultural e de um comprometimento com a organização. Considera que a gerência deve confiar e dar poder as pessoas para tomar decisões e colaborar em toda a organização. Selecionando as estratégias adequadas pode definir o ritmo para um programa Agile bem sucedido. As sete estratégias abaixo surgiram em quase todas as entrevistas realizadas, e poderão ajudar você para que a transição para o Agile seja bem sucedida.
Estratégia 1: Garantir / fornecer suporte de gestão
Um patrocinador executivo deve ocupar seu lugar antes de iniciar um programa. Isto é verdade para um programa Agile ou para qualquer empreendimento organizacional importante. O executivo nomeado fornece supervisão para o projeto, garante as finanças, e é, em última instância, responsável da entrega dos benefícios do programa (PMI, 2013). O Escritório Nacional de Auditoria do Reino Unido (UK National Audit Office) cita a “falta de uma clara apropriação da alta gestão e da liderança”, como uma das principais causas de fracasso de um projeto (Ryder, 2009).
Patrocinadores executivos geralmente têm várias responsabilidades concorrentes; portanto, eles podem não estar disponíveis, no momento necessário. Agile requer decisões oportunas (muitas vezes no mesmo dia), recomenda-se definir um representante que trabalhe junto com o patrocinador principal. Este representante deve ter a autoridade para agir em nome do patrocinador ou ter acesso rápido ao patrocinador para que as necessidades sejam facilitadas em tempo hábil. Embora o apoio executivo é fundamental para o sucesso de um programa, também é importante reconhecer a necessidade de uma base de apoio. Pessoas de todos os níveis da organização podem servir como agentes de mudança e devem estar comprometidos para ajudar a inclinar a balança de sucesso na direção certa.
Estratégia 2: Empoderar o negócio para conduzir o trabalho
A tecnologia da informação é um recurso de negócios, e não vice-versa. Os representantes das áreas de negócio precisam conduzir programas ágeis; sua participação é uma pedra angular da abordagem Agile. A falta de envolvimento das empresas se manifesta de muitas maneiras. Em 2013 o Pulse of the Profession do PMI, citou a falta de alinhamento estratégico como a principal fonte de fracasso do projeto – mais de 44 por cento dos projetos falharam por causa da falta de alinhamento (PMI, 2014). Essa falta de alinhamento estratégico é em grande parte devido a que os profissionais de negócios e de TI não trabalham em forma colaborativa.
No Agile, o Product Owner é o líder de negócios que traz a perspectiva do cliente e do negócio. Esta pessoa deve ter a autoridade para a tomada de decisão para as prioridades e para o conteúdo dos releases de software. Ao fazer a transição para o Agile, as organizações geralmente subestimam o impacto desta consideração. Usar um método Agile requer que os líderes do negócio e de TI estejam igualmente capacitados para tomar decisões e colaborar para manter o alinhamento estratégico e manter os projetos no caminho certo. Se a estrutura da governança organizacional não suporta essa consideração, a ameaça de fracasso do projeto aumentará significativamente.
Estratégia 3: Abraçar métodos ágeis
Muitas organizações têm experimentado com Agile, têm tomado algumas das melhores práticas e as aplicaram para as abordagens tradicionais, e, depois, documentaram essa tarefa, adequando para Waterfall (Cascata) SDLC (Software Development Life Cycle), resultando em um método híbrido Waterfall / Agile. Embora essa abordagem é mais eficaz do que somente Waterfall, a documentação necessária é criada para mapear os métodos, retardando o processo e inibindo a capacidade da equipe para realizar plenamente os benefícios potenciais (Salinas e Boyne, 2012). O verdadeiro valor do Agile é melhor realizado por ir “all in”.
Diferentes métodos ágeis funcionam melhor em situações diferentes. Ao selecionar um método Agile, o melhor é escolher um método mais popular. Isto tornará mais fácil encontrar os profissionais requeridos, resultando em menores custos de treinamento e facilitando um rápido início. O 8˚ relatório Annual State of Agile Survey patrocinado pela VersionOne, informa que mais de 73% das organizações utiliza o método Scrum ou uma variante (VersionOne, 2014). Enquanto Scrum é um método muito popular para um novo desenvolvimento, não pode ser o melhor método para a manutenção e para o desenvolvimento do tipo break/fix. Muitas organizações estão usando uma variante Scrum como ScrumBan, unindo o melhor dos métodos Scrum e Kanban para o break/fix. Independentemente do método escolhido, certifique-se que todas as pessoas estão a bordo e treinados e que a estrutura adequada existe para apoiar o processo.
Estratégia 4: Desenvolver planos multiníveis
É importante entender que o Agile é um método de desenvolvimento de software e não substitui a estratégia e o planejamento organizacional. Tal como acontece com as abordagens tradicionais de desenvolvimento de software, Agile é um componente do processo de planejamento global. Hubert Smits (2006) do Rally Software Development Corp. autor do white paper intitulado “5 Levels of Agile Planning.” Os cinco níveis são apresentados a seguir:
- Nível 1: Product Vision – Comunica a visão do estado final
- Nível 2: Product Roadmap – apresenta um resumo do plano geral do produto
- Nível 3: Release Plan- Aproveita o roteiro para o planejamento das entregas
- Nível 4: Sprint/Iteration Plan- Sessão de Planejamento realizada para aplicar os itens do backlog priorizados para as próximas iterações
- Nível 5: Daily Plan – ScrumMaster facilita uma reunião diária de stand-up (Scrum)
Cada um dos níveis apresentados acima são importantes para o sucesso global das iniciativas da organização, independentemente do método de desenvolvimento de software que foi escolhido.
Estratégia 5: Considerar um treinador Agile e treinar todo mundo
Desenvolvimento Ágil de software representa uma grande mudança na forma como as organizações gerenciam iniciativas de negócios e de TI. Como em toda mudança, o caminho é difícil; tentar fazê-lo com pessoas sem experiência afetará bastante a sua capacidade de ser bem sucedido. Começando minimamente com um experimentado Agile coach e um ScrumMaster com experiência Agile melhorará em muito as oportunidades de sucesso.
Em uma abordagem Waterfall muitas vezes os líderes de garantia de qualidade ou os engenheiros de processo gerenciam e monitoram que os processos sejam seguidos corretamente. Em uma abordagem Agile, um Agile coach gerencia e monitora os processos. Experimentados Agile coach trazem conhecimento profundo de Agile, ampla experiência, perspectiva imparcial, como agentes de mudança, habilidades de coaching, e reforço da aprendizagem (Brown, 2009). Um Agile coach experiente por si só não é suficiente; a equipe precisa de uma infusão de experiência em diferentes níveis e formação para todos – incluindo os principais stakeholders e de gestão. Coaching Agile é uma profissão estabelecida, e é altamente recomendável que todas as organizações considerarem a contratação de um coach Agile experiente para ajudar na sua transição.
Estratégia 6: Começar pequeno e obter sucesso mais cedo
O pensamento convencional para qualquer mudança organizacional é começar pequeno com projetos piloto, aprender com eles, e, em seguida, introduzir progressivamente a mudança no resto da organização. Apresentando Agile em sua organização não deve ser diferente. Nada poderia ajudar a um programa Agile ganhar mais impulso do que mostrar sucessos iniciais tangíveis. E, inversamente, nada poderá fazer fracassar um novo processo mais rápido que desafiando ele antes que seja maduro. Mike Cohn, em seu artigo “Choosing to Start Small or Go All In when Adopting Agile”, definiu os seguintes benefícios no fato de começar pequeno (2010):
- É menos dispendioso, comprometer menos recursos inicialmente ajuda a controlar custos.
- O sucesso inicial é quase garantido, pela seleção dos membros da equipe do projeto de confiança e se mantendo um escopo pequeno.
- Diminuir o risco; se você começar a fazer a transição na organização como um todo muito cedo, e errar, poderá aumentar a oportunidade para as resistências.
- Começar pequeno pode ser feito sem reorganizar. Tendo apenas algumas pessoas participando de uma equipe piloto é menos prejudicial para uma organização.
Começar pequeno também pode revelar novos desafios. Por exemplo: Se um time ágil precisa do apoio de equipes não-ágeis, o ritmo das entregas tal vez não esteja alinhado. Sessões de planejamento conjunto são necessárias no início do processo. Os relacionamentos antecessor /sucessor e os requisitos de cada uma das equipes (Agile / não Agile) devem ser bem entendidos, alinhados e planejados a fim de alcançar o sucesso.
Estratégia 7: Criar contratos Agile
Aquisição de serviços ágeis é diferente que dos serviços tradicionais (Waterfall). Devido a que o escopo detalhado evolui ao longo de um projeto Agile, é necessário colocar especial atenção em descrever a maneira pela qual a solução será definida e entregue. Então, ao invés de se concentrar em “o que” vai ser entregue, descrever de uma forma clara e inequívoca quanto possível sobre “como” a solução será definida e entregue. Semelhante a codificação de regras de negócios fora do foco do software, especificar a relação de requisitos a entregar (por exemplo, entregas, produtos de trabalho, artefatos, etc.) e outros componentes que poderão ser melhor gerenciados desde fora do contrato principal. O desenvolvimento ágil produz uma série de artefatos que podem ser mais valiosos em um repositório que não seja um documento formal MS Word. A chave será adotar tecnologias que deem suporte aos processos e as informações, concentrando-se sobre o conteúdo necessário e proporcionado, em vez do recipiente. Isso resultará no aproveitamento mais eficiente das pessoas que estão desenvolvendo ao invés de preparar documentos. O controle de versionamento, a reutilização e o tempo de administração também devem ser considerados antes de exigir o produto a ser produzido como um único documento, estando a informação disponível será melhor acessada e usada de uma outra forma.
Fonte: https://www.scrumalliance.org/community/articles/2014/march/transitioning-to-agile-seven-strategies-for-busine de Jim Carilli, PfMP, PgMP, PMP, CSM
Desafio AGILE:
A Resposta correta do Desafio Agile do post O modelo 3S de Maturidade é a opção 2 – Continuouns Improvement. Pois é a única que NÃO está mencionada no Agile Manifesto.
Vamos testar novamente seus conhecimentos Agile?
Novo Desafio Agile:
What type of report provides a bird’s-eye view of the project. It may be produced when the teams updates their release plan, and will allow them to show their progress and predict a completion date:
- A Time Usage Chart
- A Burn-Up Chart
- An Iteration Plan
- A Management Report
Publicaremos a resposta em nosso próximo post Agile.
Lembre que a prova é em inglês, portanto, você deverá estudar e fazer os simulados em inglês para estar melhor preparado e familiarizado com a terminologia.
Gostou?? Compartilhe!!