Sejamos honestos um com o outro; Agile é ilógico. Não é a teoria, mas me refiro à prática ilógica do ágil. As fábricas de certificação nos deram estruturas, abordagens genéricas e exames com base em cenários incompletos ou específicos. Então, como profissionais, tentamos pegar essas estruturas e aplicá -las em todos os cenários ou situação. É o equivalente ágil das novas roupas do imperador, ilógicas!

Você não pode pegar, treinar e usar exclusivamente uma estrutura para produzir soluções de alta qualidade. Toda estrutura precisa de práticas adicionais. Tome estimativa, por exemplo. O que o Scrum ou o SAFE ensina sobre a estimativa? No entanto, toda equipe precisa calcular a capacidade e equilibrar a carga de trabalho usando a medição. A equipe auto-gerenciada é a base do Agile. Pergunte a si mesmo como essas estruturas populares apóiam a criação de equipes ou levando as pessoas a trabalharem juntas. Por mais de vinte e cinco anos, a estrutura mais usada. Infelizmente, porém, os profissionais ágeis trabalharam com uma estrutura "incompleta propositadamente" e imutável que define apenas as peças necessárias para implementar o Scrum, mas não o que uma equipe precisa para desenvolver soluções de alta qualidade. Soluções de alta qualidade exigem práticas de qualidade e teste que são mais do que simplesmente afirmar como melhoramos a qualidade na retrospectiva!

Look closely at Scrum; for over twenty-five years, the most widely used framework. But unfortunately, agile practitioners have worked with a “purposefully incomplete” and immutable framework that only defines the parts required to implement Scrum but not what a team needs to develop high-quality solutions. High-quality solutions demand quality and testing practices that are more than simply stating how we improve quality in the retrospective!

Veja a segunda estrutura mais usada, segura. O seguro fornece estrutura, governança e regras para mega e grandes equipes, e é essencialmente uma abordagem ágil de gerenciamento de programas. Estou dentro e ao redor dos departamentos de tecnologia há mais de quarenta anos e raramente encontrei funções que consistentemente e significativamente apenas entregam mega programas. A realidade na maioria das lojas de desenvolvimento técnico é que há um número pequeno, um ou dois programas grandes a qualquer momento, além de vários desenvolvimentos de tamanho menor usando equipes únicas. O processo de portfólio Lean garante que os investimentos sejam equilibrados e ninguém aposte na fazenda por uma única iniciativa. Então, por que os profissionais ágeis incentivariam as organizações a adotar uma estrutura e uma estrutura adequadas para programas, não equipes únicas? Infelizmente, o Safe também não fornece orientações sobre as práticas de entrega necessárias para produzir soluções de alta qualidade. Por exemplo, como; Comece, trabalhe juntos, explore e defina o escopo, inspecione o progresso, controla seu trabalho e melhore continuamente. Esses elementos estão no centro de uma nova estrutura, a Lineout ágil, projetada para atividades de mudança de negócios.

Surely to be valuable, a framework should address the basic needs of teams. For example, how to; get started, work together, explore and define scope, inspect progress, control their work and continuously improve. These elements are at the core of a new framework, Agile Lineout, designed for business change activities.

Lineout Agile também está incompleto, mas projetado para mudanças de negócios ou equipes iniciantes de engenharia de software. Ele fornece ponteiros para os três elementos do desenvolvimento de uma solução. Ou seja, as estratégias necessárias para criar o resultado de alto valor necessário, a necessidade de criar um processo de entrega eficiente e os comportamentos da equipe necessários para otimizar o desempenho da entrega e fornecer satisfação dos funcionários. A Agile Lineout mistura orientação de Lean e XP com ciência comportamental de Amy Edmondson (segurança psicológica) e Richard Hackman (liderando equipes, preparando o cenário para ótimas performances). Voltando a teorias fundamentais, como o sistema de conhecimento profundo do Dr. Deming, a pesquisa de Robert Dunbar sobre o tamanho da equipe e a planalise de Tom Gilb para obter definições de requisitos mais apertadas, o Lineout Agile abrange as lacunas da estrutura que mencionei anteriormente neste artigo e apresenta conselhos pragmáticos para as equipes que entregam as mudanças de negócios e as soluções de software. Finalmente, o Lineout ágil suporta dimensionamento e treinamento de equipes ágeis com orientação específica. Ward:

Agile Lineout is not Scrum or SAFe but a freshly defined alternative. Going back to foundational theories such as Dr Deming’s System of Profound Knowledge, Robert Dunbar’s research on team size, and Tom Gilb’s PLanalysis to get tighter requirements definitions, Agile Lineout covers the framework gaps I have mentioned previously in this paper, and it presents pragmatic advice for teams delivering business change and software solutions. Finally, Agile Lineout supports scaling and coaching agile teams with specific guidance.

The Agile Lineout guide can be found at www.agilelineout.com

For further information and training regarding Agile Lineout, don’t hesitate to contact us at [email protected]

About the author, Jon Ward:

Jon Ward vive com sua esposa, Tatiana, em Westward Ho!, Inglaterra. Atualmente, Jon está pilotando formas modernas de trabalhar em um provedor de soluções de software no setor global de serviços financeiros. Jon é reconhecido como um líder de pensamento pelo corpo profissional do praticante ágil, o consórcio de negócios ágil. Administrador

Jon has experience in agile transformations in large organisations, coaching lean-agile adoption in a six-thousand-employee division of a tier-one global bank, and being responsible for agile business transformation in a four thousand eight hundred employee infrastructure division of an international telecoms firm.