Article :: Scrum vs ScrumAnd vs ScrumBut: Which one are you doing?

The 2015 State of Scrum Report tells us that Scrum is currently the most adopted agile practice.

In-spite of the massive popularity of this framework we see that organizations rarely use vanilla Scrum… using instead ScrumAnd or even ScrumBut.

ScrumAnd is basically everything that you put on top of the framework… and this is perfectly natural and shows the (agile) maturity of the organization.

ScrumBut is all that you supposedly should do… but in fact you aren’t doing: Retrospectives, Reviews, etc.

When you learn Scrum you have three different stages towards mastery: Shu Ha Ri.

Shu is when you learn the basics. In this stage you’ll learn “Vanilla” Scrum staying strictly in the Scrum Framework.

You get to the Ha stage is when you feel confident enough to start to make changes to the process. It’s in this stage that you make a very important decision:

Follow the path of ScrumAnd;

Or choose the path of ScrumBut.

If you go for ScrumAnd (choosing to put add-ons on top of the scrum framework) you’ll probably reach (someday) the Ri stage: Going beyond Scrum

On the other hand, if you choose ScrumBut (modifying the framework) you’ll almost for sure never reach the Ri stage… and probably get to the (wrong) idea that scrum doesn’t work.

Although add-ons and modifications seem quite similar… they are very different. An add-on is keeping everything you have and simply add more stuff on top. Modifications is changing what you already have… ending up with something completely different from what you had.

ScrumAnd usually goes like this: “We do Scrum… And…”

Here you have some examples of what ScrumAnd can be:

• Estimations in points… or maybe #NoEstimates at all;
• Sprint zero;
• Grooming / Refinement sessions;
• Prioritization sessions;
• XP Practices;
• We limit WIP (Work in Progress);
• We do swarming (Hyperproductivity pattern);
• We develop and test story by story (instead of having mini waterfalls inside the sprint);
• We have all the team testing when needed (usually by the end of the sprint);
• Our team members have t-shaped skills (cross-functional);
• Our sprints start on Mondays and finish on Fridays (except for Bank Holidays);
• All our teams are aligned (sprint wise)… so we all start and finish at the same days;
• Our team size is 7+-2;
• We invite everyone in the department to assist to our sprint reviews;
• We release often and during the sprint without (a lot of) effort;
• The Scrum Master is trying to be unnecessary (putting himself out of his job) coaching the team to be autonomous and self-organized;
• We have 80% test / code coverage (unit tests wise);
• We do code reviews (or we work with pull requests).

ScrumBut typically goes like this: “We do Scrum… But…”

Here are a few examples of what ScrumBut can be:

• Our team members think of “my” sprint / tasks / user stories / story points instead of “our” sprint / tasks / user stories / story points;
• We have a waterfall inside the sprint (testing only start after all the coding is “done”);
• We have QAs / testers working outside the team / sprint;
• QAs don’t speak to developers whenever they find bugs (processes and tools over individuals and interactions);
• The team works for the KPIs and not for the (potential) value delivered;
• The team can’t implement (technically) a user story without the dev lead or architect;
• The Product Owner is a “chicken” (isn’t allowed to speak on dailies and can’t attend retrospectives);
• We use 6 to 12 weeks sprints to “avoid pain” / “disguise problems” (e.g. releases, manual regression testing, deploys to test environments, etc.);
• After a sprint we “stop” for 1 week of acceptance tests / bugfixing / stabilization (nonconsecutive sprints);
• Team members arrive late to scrum ceremonies;
• We have daily scrums away from the physical / virtual board;
• We do BDUF (big design up front) instead of favoring emerging architectures and the lean and XP concepts of LRM (Last responsible moment), YAGNI (You aren’t gonna need it) and JIT (Just in time);
• We have only one person on our development team;
• In groomings / refinement sessions the Scrum Master assigns user stories to developers (command & control vs self-organization);
• In sprint plannings we focus more in having everybody busy (due to specializations) instead of focusing on the maximum value we can deliver (output)… so we cherry pick / choose the user stories that go in the sprint taking (mostly) in consideration the favorite skills / comfort zone of each developer;
• We don’t have a Scrum Master… and not even a Product Owner;
• We stopped doing important things (e.g. visiting customers) because “that’s not scrum”;
• Our team is not cross functional;
• We have partially allocated team members (e.g. developers);
• We have horizontal and not vertical user stories so we can’t deliver working software (increments) by the end of the sprint;
• We split user stories between development and testing;
• Each user story has an estimate for backend, frontend, integration and testing.

For final remarks, I believe that you shouldn’t aim for effectiveness (ScrumBut) but for efficiency (ScrumAnd).

There is nothing “wrong” in modifying the scrum framework… you just shouldn’t (probably) call it scrum! And (at least) make sure that you are doing it for the right reasons!

For what it matters… don’t forget that your goal is to make (awesome) software… and not to (just) do scrum.

 

Será o Product Owner uma galinha?

Foi hoje publicado, na Scrum Alliance, mais um artigo meu. 🙂

O artigo explora a posição do Product Owner (PO) dentro da equipa de Scrum tendo em conta duas escolas de pensamento: a escola de pensamento que acredita que o Product Owner é uma “galinha” e a outra escola de pensamento que defende que o PO é um “porco”.

Para quem não sabe / não se recorda da história do porco e da galinha pode ver aqui.

No artigo faço também referência ao modelo de Tuckman e às suas etapas: Forming, Storming, Norming,  Performing.

Até para a semana.

 

Spoiler: Na minha opinião todos os papéis / roles prescritos no guia do Scrum são porcos… e não galinhas.

 

Story Points Explained: The What, Why, and How

Voltei a escrever um artigo na Scrum Alliance a explicar, da forma mais simples possível, story points.

Usei exemplos práticos (bem Portugueses) para as pessoas relacionarem os pontos com o esforço… que em ultimo caso se traduz em tempo.

Expliquei que os pontos representam esforço e não complexidade…. algo que tipicamente é confundido e assumido como sendo a mesma coisa.

Começo a pensar se não estou a fugir ao propósito original deste blog… de criar conteúdos em Português sobre Agile. É algo que merece uma reflexão. 🙂

Até para a semana.

continuous delivery vs continuous deployment

Para mim é muito clara a diferença entre continuous delivery e continuous deployment.

Como depois do evento de Bilbau (CAS 2013) apercebi-me que estes dois conceitos são facilmente confundidos e até passados (erradamente) pela mesma coisa… aqui está uma imagem que explica perfeitamente a diferença entre ambos:

Obrigado à Yassal Sundman pela excelente imagem. 🙂

Até para a semana.

Scrum vs Kanban vs Lean

Em 2009 Henrik Kniberg ao escrever um artigo no seu blog sobre Scrum e Kanban nunca pensou que iria cunhar um conceito (na minha opinião) completamente errado e que após 4 anos continua para durar.

Acho interessante como ele começa por escrever o seu post a dizer que havia muito “buzz” sobre Kanban (em 2009) e se olharmos para Portugal a verdade é que (infelizmente) ainda pouco se fala. Em Portugal, temos realmente uma comunidade bastante forte de Scrum. Temos também uma comunidade crescente de Agile (a tentar de certa forma abraçar a comunidade de Scrum). Agora comunidade de Kanban ainda não sei de nenhuma.

Voltando ao Henrik e ao titulo deste post… o que o Henrik escreveu no post dele (e que depois deu origem a um livro) com o titulo “Scrum vs Kanban” era que o Scrum e o Kanban poderiam ser usados em conjunto (suprimindo as suas lacunas / best of both worlds). Ora se olharmos para o titulo do post dele, o que é sugerido (à primeira vista) é que o Scrum esta contra o Kanban (e vice-versa) e que apenas poderíamos usar um ou o outro.

Como o ser humano é preguiçoso, muitas pessoas na comunidade Agile olhando apenas para o titulo trataram logo de separar as aguas e dar origem a uma certa rivalidade entre os “seguidores” de Scrum e os “crentes” em Kanban e Lean. A rivalidade cresceu de tal forma que inclusivamente o autor sentiu-se na “obrigação” de vir a terreiro dizer que o titulo tinha sido mal interpretado e que ambos os “métodos” podiam (e em alguns casos deviam) ser usados em conjunto.

A verdade é que depois do Scrum, do Kanban e do Lean se darem a conhecer ao mundo e de já terem sido bastante explorados, a rivalidade mantém-se e pelo que percebo está para durar.

Inclusivamente, Ron Jeffries, co-autor do eXtreme programming, manifestou este mês a sua desilusão por ter testemunhado que no maior evento Agile do mundo, #Agile2013 em Nashville (EUA), organizado pela Agile Alliance, os participantes estavam mais preocupados em demonstrar que a sua metodologia fetiche (Scrum, Kanban, Lean, etc.) era melhor do que as outras do que propriamente trabalhar em conjunto para tirar proveito do melhor de cada uma delas.

Tal como Henrik teve oportunidade de dizer em 2009 e agora Ron em 2013, o Scrum, o eXtreme Programming, o Kanban e o Lean não são incompatíveis. Inclusivamente existe a forte convicção de que combinando um pouco de cada uma destas “ideologias” podemos atingir um alto nível de eficiência.

O que eu penso sobre este assunto (e apesar de simpatizar mais com Scrum e eXtreme Programming do que com o Kanban e o Lean) é que a comunidade Agile é pequena de mais para este tipo de rivalidades e clivagens. Tal como qualquer grupo, separados pouco valemos mas juntos valemos muito.

Não entendo o interesse que existe por de trás destas separações ou se é apenas um fenómeno humano ficarmos “cegos” com algo que (realmente) apreciamos ignorando tudo o que está à nossa volta.

Sinceramente não sei… agora que é uma pena a malta de Scrum não se dar com a de Kanban (e vice-versa) e passarem mais tempo a discutirem uns com os outros em vez de trabalhar em conjunto… lá isso é.

Pode ser que isto mude no futuro mas já nisto há tempo suficiente para saber que é pouco provável. 😦

Até para a semana.

retro games

Existem muitas formas de conduzir uma retrospectiva.

Apesar de não ser dos temas mais discutidos na comunidade Agile existe muito material disponível na internet e existe um livro muito bom que se chama: “Agile Retrospectives:​ Making Good Teams Great” da Esther Derby e da Diana Larsen.

Alguns Scrum Masters fazem sempre as retrospectivas by the book: “O que devemos continuar a fazer”, “O que devemos parar de fazer” e “O que devemos começar a fazer”.

Eu pessoalmente gosto de garantir que não faço duas retrospectivas iguais de forma a garantir entusiasmo e puxar pela participação da equipa.

Deixo-vos aqui alguns três exemplos de retrospectivas que correram particularmente bem:

1. Sailboat

A ideia do Sailboat é por a equipa a pensar em: objectivos (ilha), impedimentos (ancoras), riscos (rochedos) e coisas que nos favorecem (vento).

2. Radar

O radar pode ter quantos eixos vocês quiserem. Aconselho a não terem muitos para não dispersarem a atenção da equipa. Para jogarmos o radar apenas temos de ter os eixos, que devem ter os temas que queremos discutir / reflectir, e uma escala, que por exemplo pode ser de 1 (Mau) a 5 (Excelente). Pedimos a cada membro da equipa para indicarem, em cada eixo, onde acham que a equipa está. No final pedimos para todos escreverem em post-its o que acham que seria preciso para melhorarmos um nível em cada um dos eixos.

3. Happiness metric

O objectivo do Happiness metric é “avaliarmos” o estado de felicidade de cada membro da equipa. Para isso pedimos a cada membro da equipa que numa escala de 1 (Infeliz) a 5 (Felicíssimo) indique a sua felicidade. No fim perguntamos o que seria preciso para que a felicidade subisse um ponto na escala.

Lembrem-se que a retrospectiva serve essencialmente para:

1. descontracção da equipa no final da sprint;

2. gerar action points para a próxima sprint (continuous improvement / Kaizen).

Não tem como objectivos:

1. finger pointing / blaming poker / troca de acusações;

2. fragilizar a equipa.

Boas retrospectivas. 🙂

Até para a semana.

retrospectivas

Cá está o primeiro post directamente de Londres!

Hoje venho-vos falar de retrospectivas (Scrum).

As retrospectivas são “cerimónias” que não estavam contempladas nas primeiras versões da framework do Scrum. Foram adicionadas mais tarde para garantir que as equipas de X em X tempo (normalmente 1 vez por sprint) se juntavam durante determinado tempo (normalmente 1 ou 2 horas) para comer bolachas e outras guloseimas reflectirem na forma de trabalhar, nos acontecimentos mais recentes, tentar identificar pontos de melhoria e sugerir/experimentar coisas novas.

É óbvio que não é preciso fazer tudo isto apenas numa retrospectiva. Se uma equipa durante uma sprint perceber que precisa de alterar qualquer coisa, toma-se medidas para concretizar essa alteração. Não é preciso uma retro (retrospectiva) para fazer / sugerir / acontecer. A retro só está lá para garantir que este tipo de reflexão / análise realmente acontece.

Durante todo o tempo da sprint a equipa deve estar em continuo PDCA (Plan – Do – Check – Act). Deve usar uma filosofia Kaizen (melhoria continua). De outra forma como pode uma equipa melhorar ao longo do tempo?

E afinal o que se passa numa retrospectiva?

Uma retrospectiva pode ser dividida em 5 passos:

1. Set the Stage (preparar o ambiente para a conversa)

2. Gather Data (recolher as opiniões das pessoas)

3. Generate Insights (promover discussões em torno das opiniões recolhidas)

4. Decide What to Do (decidir, como equipa, que medidas / action points serão tomadas nas próximas sprints)

5. Close the Retrospective (limpar as migalhas)

Antes do primeiro passo (ou durante esse primeiro passo) devemos revisitar as medidas / actions points que a retrospectiva anterior gerou de forma a “avaliarmos” se chegaram a ser implementadas. Só assim conseguimos  avaliar até que ponto as retrospectivas estão a gerar valor.

Existem várias formas de Gather Data: desde responder às clássicas perguntas “o que correu bem?” e “o que pode ser melhorado?” até jogos de forma a ajudar todas as pessoas a expressarem da melhor forma. Lembrem-se que existem sempre pessoas mais tímidas, pessoas que gostam de dominar conversas, pessoas que falam mais alto, etc.

No próximo post irei abordar os jogos mais populares usados em retrospectivas. Existem uns muito bons. 🙂

Até para a semana.

Henrik Kniberg

Sigo o Henrik há vários anos.

Para mim é uma das cabeças mais brilhantes no mundo Agile.

Ontem vi um video dele e acho que toda a gente devia ver. Na verdade até existem 2 videos que toda a gente devia ver… como tal… enjoy!

Bootstrapping an agile project with continuous deployment using cloudbees:

Agile Product Ownership in a Nutshell:

Quem sabe se um dia a White Spectrum traz o Henrik a Portugal. 🙂

Até para a semana.

quality assurance no scrum

Desde que adoptei o scrum, tenho feito mais testes do que alguma vez fiz.

O resultado está à vista de todos, temos tido muitos menos bugs nos testes finais de aprovação o que acaba por ser curioso pois como não existem praticamente bugs o cliente sente-se com confiança para pedir sempre alguns melhoramentos. Algo que antigamente com mais bugs era impossível, quer por falta de tempo ou por falta de confiança nos desenvolvimentos.

Após algum tempo a praticar scrum não tenho dúvidas que trouxe melhorias significativas no trabalho, principalmente a nível processual.

Não me canso de dizer que estou rendido ao scrum.

O único (grande) aspecto do scrum que ainda não estou, de todo, convencido é a utilização de sprints em desenvolvimentos web.

Os nossos clientes têm um time-to-market extremamente agressivo e não é concebível que tenham de esperar 2, 3 ou 4 semanas por um package de desenvolvimentos quando podemos ter várias releases durante esse período de tempo disponibilizando de forma gradual e mais atempada as novas features ou correções de bugs.

Eu costumo dizer que o melhor scrum é o nosso scrum. Não é o scrum que vem nos livros mas sim a forma como adaptamos o scrum à nossa realidade. Se forem vocês a adaptarem-se ao scrum, então o objectivo principal do scrum está logo desde o início a falhar. Deve ser o scrum a adaptar-se a vocês e não o contrário. O scrum procura melhorar o funcionamento de uma equipa e não mudá-lo completamente ignorando o meio onde esta equipa está inserida.

É como alguém uma vez disse: “Don’t ask what you can do for scrum, but what scrum can do for you!“. Não foi bem esta frase mas era algo do género. 🙂

Até para a semana.

como o scrum mudou a minha vida

Cheguei à conclusão que sinto um enorme afecto pelos post-its que durante a noite caem do quadro, e tenho de os colar de manhã quando chego ao escritório, obrigando-me saber de cor e salteado todas as tarefas de todos os projectos ao ponto de saber exactamente de onde cada post-it caiu (projecto/sprint e respectivo estado).

O scrum enquanto ferramenta de tracking de projectos é excelente. O que para mim é o mesmo que dizer: “Bye bye Microsoft Project!” 🙂

E não ajuda apenas o project manager / scrum master. De forma inconsciente toda a equipa tem presente todas as tarefas que estão feitas, por fazer e em progresso.

Não vou dizer que o scrum é muito melhor que os mandamentos do pmbok mas a verdade é que o scrum é mais prático enquanto o pmp é mais teórico.

Como já disse repetidas vezes, o scrum por si só não é a solução para o problema… agora que o ajuda a resolver lá isso ajuda.

Eu sei que sou suspeito, mas neste momento estou bastante mais fã da utilização do scrum do que do pmbok. Agora é como tudo, o scrum é especificamente vocacionado para o desenvolvimento de software (embora há quem diga que pode ser usado em outras áreas) enquanto o pmbok pode ser usado nas mais variadíssimas áreas. Daí a minha inclinação para o scrum. E verdade das verdades, o scrum é divertido!

Até para a semana.