Ultimamente, a Agile está a receber muita imprensa, uma vez que vemos empresas como a Amazon a prosperar, alavancando os conceitos. Mas também vemos o recuo de outros líderes empresariais sobre o porquê de Agile não trabalhar para eles, ou empresas que tentaram tornar-se Ágeis mas não estão a ver as melhorias esperadas. Em vez de realizarmos Agile como uma ideia do tudo ou nada, deveríamos analisar cada um dos princípios Agile, adoptando uma abordagem pragmática para alavancar Agile dentro das nossas próprias organizações.
Esta segmentação focalizada em cada princípio Ágil é fundamental, uma vez que nenhuma prática individual irá proporcionar uma vantagem competitiva. Se algo for fácil de replicar, todos o farão. Além disso, o que as organizações fazem não é simples - cada uma delas está a completar uma combinação complexa de diferentes tarefas para criar valor para o cliente.
Isso leva-me a isto - O molho secreto de Agile é: É uma estrutura construída sobre princípios fortes que se ajustam à sua organização. O objectivo é fazer os ajustamentos certos, sem perder as forças subjacentes que Agile traz.
Para o fazer com sucesso, é necessário compreender cada um dos princípios em profundidade. Os quatro princípios Agile chave que identificámos são:
QUEBRAR PROJECTOS EM PICADAS MAIS PEQUENAS
LIGAÇÃO COM OS CLIENTES
ALAVANCAR O PODER DAS EQUIPAS
CONSTRUÇÃO EM APRENDIZAGEM CONTÍNUA
Junte-se a mim nos próximos posts enquanto aprofundamos cada um dos princípios ao longo desta série de blogues Agile. Hoje, começamos com: Quebrar Projectos em Pequenas Mordidas.
Picadas mais pequenas
O primeiro princípio é quebrar projectos e iniciativas em picadas menores, seguindo o velho adágio de que a forma de comer um elefante é uma picada de cada vez. À medida que pensamos em como quebrar projectos, precisamos também de responder:
- Como é que este projecto irá trazer valor ao cliente?
- Como é que irá trazer valor à organização?
- Como o fazemos, incluindo quanto tempo vai demorar, ou quanto vai custar?
Se pensarmos na construção, de onde vem a gestão tradicional de projectos, estas perguntas são bastante fáceis de responder. Se estiver a pensar em construir uma nova ponte, por exemplo, para ver se existe valor, é fácil ver o que aqueles que usariam a ponte estão a fazer hoje, e se estão dispostos a pagar por uma substituição. Isto responde às duas primeiras perguntas, portanto, o verdadeiro foco é a forma como o fazemos. Como esta não é a primeira ponte que foi construída, podemos obter uma ideia razoável e estimativas de projectos anteriores para nos ajudar a responder à última pergunta. Se nos encontrássemos sem informação prévia, precisaríamos de fazer experiências. Isso é muito mais difícil neste tipo de projectos, uma vez que pode não haver uma forma fácil de quebrar o projecto em picadas mais pequenas. Poderíamos começar com uma ponte de corda, mas é provável que não vá acrescentar qualquer valor até termos uma auto-estrada de quatro faixas pronta a utilizar, falhando assim a primeira pergunta.
Os projectos de construção não são os únicos que podem proporcionar esta complicação. Os projectos de infra-estruturas TI ou de actualização de software são muitas vezes semelhantes e são bastante diferentes dos projectos de software - que é de onde veio o Agile. Os projectos de software são muito mais únicos e têm as suas próprias condições a serem considerados. Vêem-se questões semelhantes em marketing, design educacional, alterações de processos empresariais, ou qualquer projecto em que não temos uma boa solução anterior para copiar.
O problema com estes tipos de projectos é:
- Podemos saber o que as pessoas estão a fazer hoje, mas não sabemos necessariamente qual a melhor abordagem para resolver os seus problemas ou quanto valor o cliente terá.
- Sem conhecer o valor do cliente, não conhecemos o valor organizacional.
- Sem conhecer a solução, não sabemos se a podemos construir, e se o fizermos, o que seria necessário.
Mesmo com esta complexidade, há algumas boas notícias. Ao contrário dos projectos de construção, estes projectos são mais fáceis de dividir em experiências onde podemos testar os nossos pressupostos e reduzir o risco para a organização. A chave é concentrarmo-nos em dividir o projecto nas peças certas, o que ajudará a responder a estas questões o mais rapidamente possível.
Como quebrar projectos em peças pequenas
Vamos falar sobre como quebrar esse elefante com um exemplo da vida real. Uma empresa com quem trabalhei tinha a hipótese de estar a pagar benefícios generosos, mas os empregados não viam esse valor, uma vez que não sabiam quanto custavam esses benefícios. Para as três perguntas, a hipótese era:
Como é que este projecto irá trazer valor ao cliente?
Se os empregados soubessem o custo dos seus benefícios, ficariam mais satisfeitos
Como é que irá trazer valor à organização?
Empregados satisfeitos darão mais valor à organização (neste caso, redução do volume de negócios)
Como o fazemos, incluindo quanto tempo vai demorar, ou quanto vai custar?
Temos acesso à informação sobre os benefícios e podemos apresentá-la no formato certo para facilitar a sua compreensão por parte dos empregados.
Olhando para a forma de romper com este projecto, gostaríamos de o fazer:
- Apresentar aos empregados um exemplo de um benefício actual para ver se este aumenta a satisfação. Se possível, provavelmente queremos começar com o maior benefício.
- Não temos tempo para esperar pela rotatividade, mas ainda precisamos de medir a satisfação, talvez com um questionário, visando um grupo de empregados que tenha a maior rotatividade.
- Precisamos de testar se podemos ter acesso aos dados e testar diferentes formas de mostrar a informação para garantir que é fácil de compreender
À medida que se expõe o que se quer aprender, torna-se mais fácil compreender como dividir o projecto nas peças certas.
Valor dos Projectos de Quebra em Peças Menores
Portanto, quer seja ágil ou não, vamos falar sobre os benefícios desta abordagem:
Como uma organização - testar cedo o valor das ideias permite-lhe concentrar-se nas boas ideias. Também ajuda a descobrir rapidamente grandes riscos técnicos, para que se tenha uma imagem do verdadeiro esforço que os projectos vão fazer. Finalmente, entregar os projectos rapidamente, e em pequenos incrementos permite-lhe entregar valor mais rapidamente, acelerando o retorno do investimento.
Como cliente - equipas já estão hoje a testar em clientes reais; todos eles quando são libertados. Testes mais pequenos significam que se pode ver qual a abordagem que uma equipa está a considerar mais cedo, fornecer contributos significativos para encontrar a melhor abordagem, e apenas um pequeno grupo de clientes é impactado.
Como uma equipa - testar cedo significa que se perde menos tempo com más ideias. É desmoralizante colocar o seu coração num projecto e depois não descobrir até ao fim que não lhe tenha sido atribuído o valor que esperava.
Ao adoptar esta abordagem, Agile está a empurrar uma táctica empírica, pressionando-o a pensar como um cientista, a compreender que ideias são realmente teorias, e a encontrar formas de testar as teorias cedo.
À medida que procura obter este mesmo valor com os seus próprios projectos, pense nas três questões em torno do valor organizacional, do valor do cliente, e da abordagem. Se tiver boas provas para apoiar as suas ideias, poderá ser mais semelhante ao exemplo do projecto de construção, e concentrar-se em como pôr o projecto em prática de forma eficiente poderá ser a melhor abordagem. Mas, se houver muitas suposições como as que descrevemos acima, vale a pena o tempo necessário para estabelecer uma experiência rápida e validá-las.
No nosso próximo post, irei rever o segundo princípio, Ligar com os Clientes.
Don’t forget to view our Agile Transformation Services to learn more about how Kolme Group can help!