Agilidade e inovação como requisitos no desenvolvimento de software
Antes de falarmos o que agilidade e inovação representam no processo de desenvolvimento de software, precisamos dar um passo para trás e trazer alguns conceitos.
A definição de agilidade pode ser descrita como a habilidade de mudar a posição de maneira eficaz. E mudar para onde, como e os processos envolvidos é um pouco do que será abordado neste artigo.
Já inovação, não é somente criar um produto ou serviço novo, às vezes é atender a um novo mercado com um produto já existente.
Este segundo conceito reduz e muito o fator intimidador do termo inovação ligado a alguma ruptura ou criação de algo completamente novo.
Inovação é olhar para outros lugares e resolver seu problema como ninguém está fazendo. (Silva, Fellipe)
Um exemplo claro deste conceito do Fellipe é o que a Tesco fez para os coreanos:
Ao terminar a leitura, perceberá que todos os conceitos, são apenas ferramentas de apoio pertencentes à parte mais importante e fundamental de qualquer time.
Um pouco de história
No contexto de desenvolvimento de software, o nome ágil surgiu na década de 90, como uma alternativa aos métodos de gerenciamento de desenvolvimento de software que predominavam na época.
O modelo cascata ou também conhecido como waterfall, muito utilizado até então, era um modelo baseado em fases bem definidas, onde cada fase somente era iniciada quando a anterior se encerrava, recebendo como entrada de informação o resultado produzido na fase anterior.
Em 1970, W. W. Royce abordava esse modelo em seu artigo como "um risco e convite para falha". O modelo era bastante eficiente quando o escopo do projeto estava muito bem definido e detalhado, como em licitações e serviços específicos para órgãos públicos. Contudo, ele apresenta muita fragilidade nos dias de hoje em virtude da pouca ou quase nenhuma flexibilidade, daí então surgem os modelos lineares e iterativos.
Eis que em 2001 surge o Manifesto Ágil, liderado por grandes nomes do desenvolvimento de software como Kent Beck, Martin Fowler, Robert C. Martin e muitos outros.
O manifesto prioriza e valoriza:
- Indivíduos e interações mais que processos e ferramentas;
- Software em funcionamento mais que documentação abrangente;
- Colaboração com o cliente mais que negociação de contratos;
- Responder a mudanças mais que seguir um plano;
Após a definição do manifesto, foram criados doze princípios que definem o novo modelo:
- Nossa maior prioridade é satisfazer o cliente por meio da entrega cedo e frequente de software com valor.
- Mudanças de requisitos são bem-vindas, mesmo em fases tardias do desenvolvimento. Os processos ágeis utilizam a mudança em favor da vantagem competitiva para o cliente.
- Entregar software em funcionamento com frequência, desde a cada duas semanas até a cada dois meses, com uma preferência por prazos mais curtos.
- As pessoas do negócio e os desenvolvedores devem trabalhar em conjunto diariamente ao longo do projeto.
- Construa projetos em torno de indivíduos motivados. Dê-lhes o ambiente e o suporte que precisam e confie neles para realizarem o trabalho.
- O método mais eficiente e efetivo de se transmitir informação para e entre uma equipe de desenvolvimento é a conversa face a face.
- Software em funcionamento é a principal medida de progresso.
- Os processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter indefinidamente um ritmo constante.
- A atenção contínua à excelência técnica e a um bom projeto aumentam a agilidade.
- Simplicidade — a arte de se maximizar a quantidade de trabalho não feito — é essencial.
- As melhores arquiteturas, requisitos e projetos emergem de equipes que se auto-organizam.
- Em intervalos de tempo regulares, a equipe reflete sobre como se tornar mais efetiva e então refina e ajusta seu comportamento de acordo.
E como ficou o fluxo de desenvolvimento depois do Agile?
A principal mudança foi a criação de ciclos iterativos e contínuos, comparado a o modelo de cascata podemos ver claramente a diferença de fluxo:
Este modelo trouxe várias vantagens para o fluxo de desenvolvimento:
As entregas são mais rápidas
É mais vantajoso entregar uma parte do software funcionando ao cliente e validar diretamente com ele as mudanças ou alterações necessárias, ao invés de gastar muito tempo fazendo um processo rigoroso de especificação de requisitos para validação posterior.
Outro ganho com as entregas rápidas é o custo. Caso a primeira validação, feita em um curto período de tempo já exija alterações, é muito mais produtivo e menos custoso mudá-la imediatamente com o ajustes necessários para obtenção do valor desejado junto ao cliente, do que esperar o processo todo de desenvolvimento finalizar e depois ter que mudar um fluxo muito maior, como acontecia no cascata.
Flexibilidade
Com a possiblidade de mudanças a qualquer momento, o produto final entregue ao cliente é muito mais flexível e ajustável as reais necessidades, entregando de fato valor ao mesmo. No modelo anterior, as mudanças tinham uma etapa limite para ocorrerem e após esta, se tornavam inviáveis até a conclusão do processo.
Ganho em qualidade
Com iterações menores e continuas, é possível executar testes e validações junto com o próprio cliente.
Isso faz com que a qualidade do software final venha sendo assegurada a cada etapa do projeto, baseando-se nas partes do produto que já foram entregues anteriormente, testadas e validadas.
Stakeholders próximos
A proximidade entre o cliente e os desenvolvedores ajuda a evitar problemas de comunicação e ainda facilita à equipe entender o que o cliente realmente deseja. Além de deixar todos mais satisfeitos, evita-se o risco de gastar muitas horas de trabalho em algo que o cliente não está gostando.
Riscos reduzidos
Com a constante comunicação entre a equipe de desenvolvimento e o cliente, além de receber as versões do software, o cliente é capaz de identificar possíveis problemas e reportá-los diretamente aos desenvolvedores para que os mesmos sejam solucionados o mais rápido possível.
Além disso, a possibilidade de ter essa visão do software final ajuda no processo de tomadas de decisões que podem impactar no seu desempenho.
Mas como tudo, não existe almoço grátis, há também desvantagens no modelo ágil:
Exige uma equipe dedicada a melhoria constante
Uma equipe para trabalhar com o Agile não precisa obrigatoriamente dominar todos os métodos, mas requer que seus membros estejam interessados em aprender e otimizar suas performances, tanto individual quanto coletiva.
Também é necessário muita tolerância à mudanças, dado que a cada etapa, as necessidades das demandas podem sofrer alterações.
Como adotar o agile no seu time
Um ponto muito importante que precisa ser mencionado é que ao adotar o Agile, é recomendado que primeiro o time experimente o fluxo. Muitas pessoas já tentam implantá-lo com mudanças para contornar possíveis desvios que existem no processo atual, e em muitos casos, não sabem ao certo o que de fato tem que ser adaptado.
Quando não há a experimentação, os processos criados não são tão ágeis assim e em muitos casos, acabam falhando em atingir o que era esperado, frustando assim não somente o time como também a gestão.
Na iClinic, adotamos um modelo no passado e viemos sentindo os pontos de dores frequentes no time. Tínhamos um quadro físico no modelo Kanban, que iniciou-se de uma maneira simples, com as raias de atividades em andamento e os bloqueios, divididos entre colunas TODO, DOING e DONE.
Com o passar tempo, fomos adaptando esse modelo, inserindo novas colunas como Code Review por exemplo. O WIP também era ajustado até chegarmos em um número ideal, o que gerou muito aprendizado.
Hoje, depois de muitos aprendizados, temos adotado o modelo de Scrum para escopos fechados de desenvolvimento e o Kanban para demandas com uma taxa de mudança maior. Para ambos modelos, usamos o Jira como ferramenta de apoio, e mais detalhes de como funcionam essas metodologias, será abordado mais abaixo neste mesmo artigo.
Se realmente pensa em adotar o modelo ágil no seu time, as dicas que deixo são:
- experimente durante um tempo;
- colha dados para descobrir não só o que adaptar ao seu fluxo, mas também o como fazê-lo;
E na prática, quais as principais metodologias e ferramentas que podem ajudar com agilidade e como elas funcionam?
Existem hoje disponíveis no mercado várias metodologias para o modelo Agile, duas das mais utilizadas são o Scrum e o Kanban.
SCRUM
O Scrum é uma estrutura que ajuda as equipes a trabalharem juntas. Semelhante a uma equipe de rugby, de onde herdou o nome, treinando para o grande jogo, o Scrum estimula as equipes a aprenderem com as experiências, a se organizarem enquanto resolvem um problema e a refletirem sobre os êxitos e fracassos para melhorarem sempre.
Essa metodologia é bem simples e dinâmica.
Tudo começa com a visão inicial do produto e um planejamento realizado pelo Product Manager. Na etapa de visão inicial, considere todo o ciclo de pesquisa, validação e prototipação de pesquisa que é feito antes de qualquer planejamento.
O Product Manager é o profissional responsável pela entrega de um produto de alta qualidade e relevância para os seus usuários. Dessa forma, ele une a parte tecnológica, a experiência do usuário e a estratégia de marketing para que elas possam atuar em sinergia em prol do sucesso da empresa.
Aqui na iClinic, acontece ainda uma etapa de ideação, onde reunimos um grupo multidisciplinar composto por membros dos mais diversos times para discutir e enriquecer ainda mais o que será desenvolvido. Com a composição das melhores ideias e feedbacks, o projeto segue para refinamento em pesquisa.
Quando os insumos chegam para o Product Manager, são definidas prioridades para implementar as funcionalidades ao longo do projeto.
Depois de definido, o projeto é dividido em ciclos, chamados de Sprints, que geralmente têm de duas a quatro semanas de duração. O Sprint é o período de tempo em que o conjunto de atividades definidas no Product Backlog devem ser colocadas em prática.
Antes de iniciar o Sprint, a equipe se reúne para planejar e refinar as tarefas a serem implementadas, ter uma visão clara das prioridades e do que se espera do ciclo.
As tarefas designadas para cada Sprint são deslocadas do Product Backlog para o Sprint Backlog.
Durante a execução do Sprint, a equipe deve fazer um Daily Scrum: uma reunião diária em que cada colaborador deve pontuar o que fez no dia anterior, o que irá fazer hoje e quais impedimentos existem. Os impedimentos são a parte mais rica desta cerimônia, que quanto antes apontados, antes podem ser resolvidos e as vezes até chegar a serem pivotados para outra abordagem.
E assim o processo segue até o fim do Sprint, momento em que é realizada uma reunião de revisão das funcionalidades implementadas, a fim de validar o produto. Aqui na iClinic, sempre há pessoas de outros times participando das reviews, de forma a tomarem ciência das melhorias implementadas, darem feedback e até sugerirem algumas coisas que, dependendo da priorização, entram no Backlog e o ciclo recomeça.
Também é nesse momento que se faz uma retrospectiva do Sprint, em que a equipe avalia o processo, identifica necessidades de adaptação e começa o planejamento do novo Sprint.
Esse ciclo se repete até a entrega do produto final ao cliente.
KANBAN
Kanban é um termo japonês que significa “cartão”. O sistema recebeu esse nome pela própria empresa que o desenvolveu, a Toyota.
Ele nada mais é do que um sistema ágil e visual para controle de produção ou gestão de tarefas, e não apresenta um escopo fechado como nas Sprints do Scrum.
Os cartões representam o que precisa ser feito e correm em colunas, normalmente vistas como TO DO, DOING, DONE nos modelos mais simples. Essas colunas podem ser ajustadas de acordo com o o fluxo do processo da equipe, como por exemplo incluir uma coluna de Code Review ou até mesmo Next to Deploy, o que ajuda a medir o tempo que um card passa em cada uma destas etapas e identificar possíveis gargalos.
Um paralelo com o Backlog do Scrum é o TO DO do Kanban. As tarefas nascem aqui, e são puxadas pelos responsáveis para Doing, Done e assim por diante.
De uma forma bem visual, o Kanban também ajuda a evidenciar os gargalos e garantir que o processo seja seguido. É importante que ele reflita o seu processo de desenvolvimento, do contrário terá um quadro que os cards não serão movidos. Se estiver tendo problemas de Code Review por exemplo, basta adicionar uma coluna só pra ele no quadro, que ficará bem evidente este gargalo.
Em desenvolvimento ágil, os limites de trabalho em andamento (WIP) definem a quantidade máxima de trabalho que pode existir em cada status de um fluxo de trabalho. Limitar a quantidade de trabalho em andamento facilita a identificação da ineficiência no fluxo de trabalho de uma equipe.
E qual deve ser utilizado?
A resposta certa para essa questão é: Depende.
Varia muito de organização para organização e como é definido o fluxo de trabalho. Em alguns casos até um modelo híbrido faz mais sentido do que engessar em um ou em outro.
As principais diferenças que os métodos apresentam são:
- Ritmo: Enquanto no Kanban o fluxo é contínuo, no Scrum temos Sprints regulares definidas;
- Funções: No Scrum há uma separação mais clara de funções e responsabilidades, como Scrum Master, equipe de desenvolvimento, etc.
- Entregas: Kanban oferece entregas contínuas enquanto no Scrum as entregas de cada Sprint devem ser aprovadas no final da mesma. Caso não seja, a mesma tarefa volta para a próxima Sprint e o ciclo recomeça.
- Mudanças: O Kanban permite que ocorram mudanças a qualquer momento, enquanto no Scrum as equipes devem se esforçar para não fazer alterações na previsão da sprint durante a mesma, pois a estimativa fica comprometida.
De todas, o principal fator que gera bastante impacto e muitas vezes acaba sendo decisivo para a escolha de um ou outro são as mudanças. Então antes de escolher pelo favorito, avalie os pontos fortes e fracos de cada um em sintonia com o seu time e o seu fluxo de trabalho. Isto com certeza facilitará a escolha e deixará a equipe mais produtiva.
Métricas
Para ambas as metodologias, descarte qualquer oportunidade de "achismo" ou "advinhação", ao invés disto, meça!
Medir é necessário para o gerenciamento e esta prática apoia a tomada de decisões oferecendo previsibilidade. Mas nem tudo deve ser medido. As métricas tóxicas mais comuns ocorrem quando medimos pessoas, linhas de código ou até mesmo funcionalidades.
Meça o time a faça ajustes no processo de acordo com seu objetivo. Um outro ponto importante é: não compare os times entre si. Uma analogia sensacional que ouvi no nosso Agile Coach aqui na iClinic foi:
Uma equipe de desenvolvimento pode ser comparada à uma equipe esportiva. Tome o futebol por exemplo. O time é composto por pessoas que não só trabalham junto, mas se conhecem e suas capacidades se complementam. Você dentro do time já conhece todos os pontos fortes e fracos de cada um, como quem chuta melhor, quem corre mais, quem marca melhor, etc.
Qualquer substituição gera uma falta de entrosamento o que compromete a capacidade produtiva. Acontece no esporte e no desenvolvimento também. Imagine agora que troque meio time. É um time completamente novo, e as métricas do passado não servirão para comparação com o novo time.
(Carvalho, Gabriel)
As métricas ágeis
Não adianta começar medir tudo. Nenhum aprendizado sadio virá de uma revolução. Ao invés disso, evolua gradualmente.
Comece simples e monitore três muito importantes:
- Tempo de entrega (Lead time): O número de dias entre o início e o fim do processo de entrega de um item de trabalho (por exemplo: histórias do usuário, bugs, etc).
- Taxa de entrega (Throughput): Quantidade de itens de trabalho entregues por período de tempo;
- Trabalho em andamento (WIP do inglês: Work in progress): Quantidade de trabalho em progresso;
Estas três já trarão uma boa visão do seu fluxo e apontarão com clareza os pontos de melhoria.
Mas lembre-se: não é para julgar a pessoa ou achar culpados, o objetivo está em entender o que aconteceu e colocar em ação melhorias na maneira da equipe trabalhar.
Depois evolua gradualmente de acordo com a necessidade, como por exemplo, analise o Lead Time sobre óticas diferentes, como:
- Customer lead time (tempo para entrega ao cliente/mercado);
- Discovery lead time (tempo para entendimento/refinamento) ;
- System lead time (tempo de desenvolvimento);
Apenas quando o time estiver confortável com as métricas, inclua melhorias e novas análises para a evolução natural e conseguir ser mais assertivo com a previsibilidade.
Outras métricas que refletem diretamente em qualidade que podem ser analisadas:
- Quantidade de bugs;
- Severidade;
- Retrabalho;
- Dívida técnica;
Para acompanhamento também são muito úteis métricas como:
CFD
Acrônimo para Cumulative Flow Diagram, que em tradução livre seria Diagrama de fluxo cumulativo. Ele é um dos gráficos que oferece rápida visão geral do que está acontecendo num projeto ou produto.
A estrutura do gráfico é muito simples. O eixo horizontal representa um período de tempo (semanas, sprints, etc) e o vertical indica, de forma acumulada, o número de itens no processo (total de tarefas, total de histórias, etc.). Cada área pintada no gráfico está relacionada a uma etapa do fluxo de trabalho (backlog, em progresso, finalizado, etc) e as curvas são basicamente o número de itens acumulados em tais etapas.
A grande vantagem proporcionada pelo CFD é deixar visualmente expostas todas as disfunções do fluxo de trabalho. Com ele é possível melhorar a visualização de gargalos, desbalanceamento entre as etapas do fluxo e prever se o time está no caminho para a entrega dos itens do backlog.
No exemplo acima, vemos claramente que todos os status crescem quase que de maneira constante, mas imagine por exemplo se a revisão final(vermelha) não acompanhasse a tendência.
O que teríamos seria quase que a completa omissão desta cor no gráfico em algum intervalo de data, o que impactaria no volume movimentado para concluído.
Esse gráfico ajuda muito a apontar esses gargalos, e qualquer divergência pode rapidamente ser endereçada para fazer com que o time performe melhor.
BurnDown
Um gráfico de burndown é uma representação gráfica do trabalho a ser feito versus tempo. O trabalho restante é geralmente no eixo vertical, com o tempo no eixo horizontal. É útil para prever quando todo o trabalho será concluído.
Esse gráfico é muito útil para ajudar a ter uma previsibilidade melhor. No exemplo acima, temos uma sprint de 21 dias (eixo horizontal) versus uma quantidade de pontos a serem entregues (aproximadamente 250).
Para que a entrega ocorra na data prevista, é preciso seguir o cronograma e ficar o mais próximo possível da linha verde, que representa a conclusão ideal das tarefas.
Note também, que em alguns momentos da linha azul clara, não há qualquer entrega, representada por um platô. Isso irá exigir do time que faça um esforço maior, representado pela linha azul escura, para atingir o planejamento na data prevista.
Particularmente é um dos gráficos que mais gosto. Com meu background em backend, e conhecendo uma característica bem comum no perfil de desenvolvedor, o que eles mais curtem (e me incluo nessa), é ver algo sendo completo, e esse gráfico trás claramente a performance do time e os resultados das entregas ao longo do tempo.
BurnUp
O gráfico de burnup apresenta, assim como o gráfico de burndown, o ponto do cronograma com o prazo de entrega planejada (representado no eixo X, horizontal). A diferença é que o eixo Y, vertical (que representa as entregas), exibe em que ponto a equipe está ao longo da sprint, revelando o quanto de progresso já houve enquanto a linha sobe (queimando para cima) em direção ao ponto final.
O gráfico de Burnup é muito parecido com o de Burndown, pois, ambos compartilham o mesmo objetivo: apresentar o trabalho estimado e o progresso do seu desenvolvimento ao longo do sprint. Existe uma diferença simples entre os dois:
- O gráfico de Burndown parte do total de trabalho a ser feito e mostra a redução deste valor conforme tarefas são concluídas;
- O gráfico de Burnup parte do zero (no eixo X), e cresce conforme tarefas são concluídas em direção ao total de trabalho necessário para concluir o sprint.
Ou seja, ambos apresentam a mesma informação, de forma invertida.
Esta diferença existe apenas para se ajustar a sua preferência de visualização da informação. Você prefere ver o trabalho total sendo concluído e seu gráfico representando isto em direção ao objetivo zero, onde não há mais trabalho a ser feito, ou prefere ver seu trabalho sendo representado como uma linha crescente, que mostra tudo o que já foi concluído em direção ao objetivo final do sprint? Fica por sua escolha.
O exemplo da imagem acima traz outro ponto interessante de se discutir. Temos uma sprint de 15 pontos a serem entregues, e no meio do caminho houve uma alteração para 18 e em seguida para 16.
Esse pico representa algo não planejado ou que sofreu alguma mudança após o planejamento. Logo, o esforço da sprint foi acrescido com uma ou mais tarefas que posteriormente devem ter sido negociadas junto ao PM para voltarem para backlog, reduzindo o esforço para 16, o que ainda assim representa uma alteração de escopo daquela sprint.
E onde a inovação entra nessa história toda?
A inovação é um processo definido por meio da implementação de novas ideias capazes de agregar valor a uma organização. Isso está relacionado com a criação de um novo serviço, sistema ou processo, ou com o aprimoramento dos existentes. Ela também pode assumir a forma de dar continuidade a um serviço, sistema ou processo ineficiente ou desatualizado.
A inovação também pode ser um empreendimento de grande escala onde um novo produto ou serviço, como o Google, mudou fundamentalmente como fazemos negócios. Além disso, ela pode ser uma iniciativa interna de baixo custo, como melhorar um processo em seu negócio que vai levar a economias nos esforços.
Outros exemplos clássicos incluem desde a lâmpada elétrica, até os mais conhecidos nesta nossa era digital: Netflix, Spotify e Airbnb e por quê não citar iClinic?
Além de introduzirem opções com mais novidades para os clientes (que rapidamente se tornaram amplamente exigentes no mercado), eles geraram lucros significativos.
A lâmpada elétrica
Segundo a história, foram mais de 1000 tentativas até chegar em um resultado de sucesso, e foi a partir daí que Thomas Edison inspirou diversas pessoas a persistirem em seus objetivos, já que para ele as tentativas não haviam sido falhas e sim descobertas de fazer uma lâmpada de mil maneiras diferentes.
Edison alcançou o seu tão buscado sucesso quando utilizou um filamento fino de carvão a alto vácuo. Antes disso ele já havia testado cerca de 6.000 materiais diferentes, desde liga metálicas até bambu, além de ter realizado 1200 testes.
Utilizando uma linha de costura de algodão carbonizada, para o filamento, foi possível manter a lâmpada incandescida por 48h. Com o êxito do seu experimento, o grande cientista registrou seu produto e iniciou a comercialização até alcançar uma grande escala.
A sua invenção foi um dos grandes avanços para a industrialização, medicina e indústria cinematográfica.
Serviços digitais: Netflix, Spotify, Airbnb e iClinic
Para os mais novos, que já nasceram e vivem nesta era digital que estamos, chega a ser difícil explicar o que era querer ver um filme no início da década de 90.
Basicamente envolvia alguns passos:
- Se deslocar até a locadora;
- Procurar o filme nas prateleiras físicas, e torcer para que não estivesse alugado;
- Levar pra casa;
- Assistir;
- Rebobinar. Sim sou do tempo do VSH, e havia uma taxa extra no aluguel caso a fita não estivesse no começo para o próximo cliente;
- Voltar a locadora para devolver;
Você que leu tudo isso, ainda preciso explicar como o Netflix inovou provendo esse tipo de serviço? Quais das etapas acima, além de assistir, você assinante deste ou de qualquer outro streaming, faz hoje? Nenhuma.
O Spotify seguiu na mesma linha com a música. Confesso que também tinha conta em uma locadora de CDs, e apesar de atualmente ser assinante do Spotify, ainda os compro.
O Airbnb uniu os inquilinos e locatários globalmente. Não só para viagens, mas também para aluguéis por temporada. Você lembra como era viajar antes dele? Hotéis caros, translados diários dependendo da localização do mesmo e com limitação de espaço na maioria dos casos (quarto e banheiro)?
Hoje com esse serviço, é possível alugar somente um sofá, somente um quarto ou até uma casa inteira a preços muito mais acessíveis do que algumas redes de hotéis. Um ponto que recomendo fortemente para viagens internacionais: alugue um quarto e conviva com os locais. Terá um banho de cultura regional que nenhum hotel é capaz de oferecer.
Em meados de 2012, eis que surge o iClinic com o objetivo de descomplicar a saúde no Brasil e cada vez mais empoderar os profissionais de saúde.
Nosso produto visa cada vez mais oferecer um software de qualidade a ponto de tal qualidade transcender para o atendimento dos pacientes.
Nosso sistema conta com diversos recursos, desde prontuário customizado, gestão completa da clínica, assinatura digital, teleconsulta e muitos outros. Nossa visão de futuro é sermos o One Stop Shop da medicina no país, oferecendo todos os recursos necessários para os profissionais de saúde.
A inovação trata de resolver os problemas das pessoas, e não só produzir produtos, por isso está diretamente relacionada ao Agile durante todo o processo e ao sucesso ou fracasso de um time ou companhia.
Uma entrega mais rápida leva a um feedback mais rápido para o aprendizado; e um aprendizado mais rápido leva a soluções de qualidade mais rápida.
O desafio de estar sempre inovando é o que mantém líderes de mercado na ponta com um market share maior, e também o que impulsiona quem almeja uma fatia maior do mercado buscando crescimento.
Pode-se falar em inovação em algumas etapas:
- Em Busca de Soluções: os métodos que usamos para “testar” o caminho para o sucesso;
- Inovação de startups: o método “push” usado para procurar clientes de uma nova ideia;
- Inovação de produto: o método “pull” usado para extrair necessidades e soluções de mergulho para maior envolvimento do cliente
- Inovação de processo: o método “contínuo” usado para encontrar e liberar a receita por meio de seus gargalos organizacionais.
Inovação = informação + imaginação + iniciativa
E por quê os projetos falham?
Basicamente há três fatores que comprometem os projetos que podem culminar em seu fracasso:
- Mudança de prioridades;
- Mudança de objetivos do projeto;
- Falta de requisitos precisos;
E onde inovação entra?
- Alinha os objetivos do projetos;
- Aumenta a precisão de requisitos;
- Gerencia a dúvidas;
A inovação em produto nos permite sermos mais ágeis. Como engenheiros não podemos nos permitir ficarmos paralizados em analisar demais o problema, isto é para cientistas! Temos que criar uma solução e em seguida testá-la para ver se funciona.
Agilidade é sobre pessoas!
Até aqui o artigo abordou muitos termos técnicos, fluxos, metodologias e ferramentas, o que deixa uma pergunta bem clara: Agilidade é conhecer e aplicar tudo isso? E a resposta é bem simples: Não.
Tudo que foi abordado aqui obviamente compõe o conceito de uma equipe ágil, mas apenas em uma pequena porcentagem, contudo a maior parte não é qual framework usar ou métricas escolher, mas sim sobre pessoas.
Quando o time está engajado com os objetivos e principalmente quando é de fato um time, e não só um grupo de pessoas que trabalham juntos, é possível perceber a agilidade em todo o processo.
Para isso, é necessário retroceder muito antes de qualquer etapa de execução e falarmos da construção do time. Um time funciona como time quando se conhecem, confiam uns nos outros e se ajudam em prol do objetivo, seja da sprint, seja da entrega, do trimestre ou da companhia.
É necessário prover recursos e executar algumas ações para que exista um time, como técnicas de Team Building e Team Bonding. Também muito importante é que o time se sinta acima de tudo seguro em compartilhar dores e dificuldades, não só nas retrospectivas, mas a qualquer momento que acharem necessário e principalmente, sem julgamentos.
Antes de fazer todas as análises de métricas, garanta que seu time está saudável, unido e comprometido. Isso refletirá diretamente em performance.
A segurança psicológica é outro ponto muito importante e deve sofrer melhorias constantes. É necessário proporcionar a todos do time uma segurança tamanha que não os deixem com medo de errar. Ao errarmos, não falhamos. Só de fato falhamos quando erramos e não aprendemos nada com o erro. Dê essa liberdade para seu time de experimentar e ao errarem, aprenderão ainda mais rápido, trazendo resultados mais eficientes e duradouros.
Trabalhamos esse ponto em um dos nossos principais valores aqui na iClinic: Acerte Junto. Ao errarmos, erramos como time, ao acertamos acertamos como um time. Não há nenhuma caça às bruxas para apontar culpados ou momentos de glória individuais.
Ofereça ao time também autonomia e autoria. Podemos até ter planejamentos e visão de futuro que são ótimos para dar um norte, mas é o time quem deve decidir o caminho ou ao menos qual veículo usar para fazer a viagem. Essa autonomia e no fim das contas dá um senso de pertencimento enorme a todos os envolvidos e tem grandes chances de gerar grande engajamento e performance.
Não existem entregas ou quiçá métricas sem um time, e não há times sem pessoas. Invista no seu time. Dedique um tempo para entender suas reais necessidades, e isso não serve apenas para líderes, os próprios membros do time podem exercer essa função, pois quando alguém estiver mais "fraco" e/ou precisar de algum apoio seja pessoal ou profissional, deve haver no time não uma, mas muitas pontas firmes que impeçam a corda de romper e consigam se ajudar de forma colaborativa.
Mais importante que estar em um time é ser parte dele.
Aqui na iClinic, estamos aprendendo e construindo muitas coisas juntos, como um time. Até mesmo criando novos times, no real conceito da palavra, e caso tenha gostado a leitura, mas tenha ficado com um gostinho de querer experimentar tudo isso, venha ser parte do nosso.
Referências
- Knowledge21
- Curso "Agile Innovation and Problem Solving Skills" — University of Maryland
- Manifesto Ágil
Agradecimentos especiais
Ao Fellipe Silva, nosso Lead Designer, que dedicou seu tempo à leitura deste artigo e trouxe inúmeros feedbacks interessantes que completaram bastante o objetivo deste material.
Fê, muito obrigado pela contribuição, foi de grande valia. Espero que tenha visto algo novo e principalmente aprendido algo da mesma forma que aprendi com sua revisão e aprendo com seus insights no dia a dia. Valeu demais!
Ao Gabriel Carvalho, nosso Agile Coach recém chegado, que mesmo com pouco tempo de casa, compartilhou inúmeros conceitos, exemplos e experiências com o time.
Gabs, sei que prefere evolução à revolução, mas sinto-lhe dizer que já revolucionou minha mente com que já compartilhou conosco e por isso agradeço.
