4. O estado futuro do Scrum

4.1 Sim, fazemos Scrum. E...

O Scrum surgiu na década de 1990 do trabalho e descoberta de Ken Schwaber e Jeff Sutherland. Eles analisaram e refletiram criticamente sobre práticas que na época eram consideradas comuns no desenvolvimento de software, sua própria experiência profissional, estratégias bem-sucedidas de desenvolvimento de produtos [Takeuchi & Nonaka, 1986] e teoria de controle de processos. A soma de suas descobertas se tornou Scrum [Schwaber, 1995] e foi formalmente apresentada ao público em 1995 [Sutherland, 1995]. Nos anos que se passaram desde a publicação do ‘Manifesto para o Desenvolvimento Ágil de Software’ [Beck, et. Al., 2001] em 2001, o Scrum se tornou o framework Ágil mais aplicado em todo o mundo.

No entanto, o Scrum continua sendo uma maneira leve e simples de organizar um trabalho complexo e abordar desafios complexos baseados nos princípios e ideias Ágeis. A combinação única entre a definição clara e a natureza pouco prescritiva do Scrum é primordial para o seu sucesso, agora e no futuro previsível. O Scrum, como um framework organizacional, pode envolver várias práticas de desenvolvimento de produtos existentes ou pode tornar as práticas existentes supérfluas. O Scrum provavelmente revela a necessidade de novas práticas. Os benefícios do Scrum serão maiores quando complementados por desenvolvimento, gerenciamento de produtos, pessoas e práticas organizacionais aprimoradas ou revisadas. Quando bem feito, a soma ainda será Scrum.

Nas duas primeiras décadas de sua existência, as organizações utilizaram o Scrum principalmente para os aspectos de TI e tecnologia do desenvolvimento de software. Para muitas pessoas de TI em todo o mundo, o framework Scrum se tornou uma solução comprovada. Apesar dos ótimos resultados, como o Ágil ultrapassando o Cascata (desenvolvimento em cascata) e a posição de gorila do Scrum, há espaço para melhorias. Há necessidade de ir mais longe.

Desafiar o status quo do paradigma industrial melhorou o aprendizado contínuo ao lidar com muitas incertezas tecnológicas no domínio de TI e ajudou muitas organizações a deixar de organizar o trabalho em projetos e recuperar o foco nos produtos. Em muitas organizações, o entendimento foi restaurado de que o desenvolvimento de software e produtos é uma atividade criativa e complexa. Mas o foco muitas vezes ainda é ‘como’ os produtos são construídos. É hora de elaborar os resultados alcançados e levar seu Scrum ao próximo nível.

Existe uma infinidade de possibilidades para ‘rodar’ Scrum, uma miríade de práticas que podem ser envolvidas pelo Scrum, e os resultados e desempenho do trabalho gerenciado com o Scrum são influenciados por muitos fatores. A co-localização das pessoas influencia isso. A energia, dedicação e alegria dos membros-jogadores influenciam isso. O nível de auto-organização influencia isso. O fato de as pessoas trabalharem em multitarefa influencia isso. A disponibilidade de automação de desenvolvimento e teste, ferramentas, plataformas e práticas influenciam isso.

Um aspecto crucial é o pensamento multifuncional que vai além das paredes do departamento de TI, através de toda a empresa. Lembre-se de que o Ágil é impulsionado por oportunidades de negócios. Em ter implementado o Scrum para o ‘como’ da entrega do produto, adicionar mais foco agora ao ‘o que’ precisa ser construído, é crucial. Essa mudança ajudará as organizações a descobrir o poder do produto possível, sobre as restrições do produto previsto, reduzir a quantidade de produto a ser desenvolvido, em vez de simplesmente otimizar a maneira como o produto está sendo desenvolvido. Veja o capítulo 4.2.

Existe uma infinidade de técnicas e práticas para “rodar” Scrum e que o Scrum pode envolver. Mas mais do que processos e técnicas, passando do antigo paradigma industrial para o novo paradigma Ágil, trata-se de uma atualização organizacional. O entusiasmo comum que surge nas equipes ao adotar Scrum provavelmente não será suficiente para uma profunda transformação organizacional. Para um efeito duradouro, o entusiasmo bottom-up comum precisa ser apoiado e facilitado pela adoção upstream. Veja o capítulo 4.3.

OceanofPDF.com