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.

 

Anúncios

novidades

Trago duas novidades:

1 – A terceira, e última tertúlia, do Porto, em 2014, vai ser adiada para Setembro. Falamos com os potenciais locais (para realizar a tertúlia) e todos mostraram preferência pelo mês de Setembro em detrimento de Junho. Assim sendo achamos sensato dar ouvidos aos nossos parceiros e adiarmos a tertúlia para uma data que interesse a todas as partes. Mais próximo da data volto a dar novidades sobre este tema.

2 – O Agile Portugal 2014 está aí à porta. Este ano é em Leiria e vou voltar a ser orador com uma nova versão (ajustada ao evento) da talk “Pair Programming”. Podem ver tudo aqui. 🙂

Até para a semana.

segunda tertúlia

Realizamos mais uma tertúlia neste ano de 2014.

Só vos digo o seguinte: (na minha opinião) a melhor tertúlia de sempre!

Porto Business School + Isabel Paiva de Sousa (PBS) + António Andrade Dias (APOGEP) = receita de sucesso. 🙂

A Isabel foi uma pessoa que me impressionou. Tanto pela sua apresentação bem como pelo seu interesse no tema “felicidade no trabalho” / “happiness at work”.

Correu tudo muito bem e ainda tivemos a sorte de contar com umas palavras do Eduardo Santos (PBS) na abertura da tertúlia.

A próxima será no dia 18 de Junho.

Até para a semana.

ciclo de tertúlias 2014 :: gestão de conflitos

Na próxima semana (quarta-feira, dia 7) a IPMA Young Crew Portugal vai continuar o ciclo de tertúlias 2014, no Porto.

São eventos muito interessantes (e gratuitos) nos quais eu contribuo para a sua organização.

Nesta segunda tertúlia vai-se falar de gestão de conflitos e convidamos Isabel Paiva de Sousa (Porto Business School) e o António Andrade Dias (APOGEP).

Vai ser, outra vez, uma excelente tertúlia.

Para os interessados aqui fica o convite:

A IPMA Young Crew Portugal apresenta a 2ª Tertúlia, sobre Gestão de Conflitos em Projecto, integrada no ciclo “À conversa sobre Gestão de Projetos”.
A Prof. Isabel Margarida Paiva de Sousa, Porto Business School e o Prof. António Andrade Dias, APOGEP serão os oradores convidados desta sessão que decorrerá dia 7 de Maio de 2014, das 19h15 às 21h, na Porto Business School.
É necessário fazer inscrição mas a entrada é gratuitahttp://bit.ly/1m7My6I

A YCP está ligada à IPMA (International Project Management Association – www.ipma.ch), representada em Portugal pela APOGEP(Associação Portuguesa de Gestão de Projectos – www.apogep.pt).

tertulias v2

Vou voltar a estar presente e espero, mais uma vez, ver algumas caras conhecidas por lá. 🙂

Até para a semana.

primeira tertúlia

Realizamos (com sucesso) a primeira tertúlia na passada terça-feira.

Correu tudo muito bem.

Tivemos cerca de 50 pessoas a assistir. O que não é nada mau tendo em conta que estamos a falar de um evento (que apesar de gratuito) em horário pós-laboral.

Os oradores estiveram excelentes. Tanto o meu amigo Sérgio Lourenço (PPM Coachers) como o José Coutinho Sampaio (FEUP / INEGI) portaram-se muito bem e trouxeram uma riqueza indiscutível ao evento.

Tive oportunidade de conhecer o José Coutinho Sampaio bem como rever algumas caras conhecidas.

A logística foi um desafio mas os meus companheiros de projecto, bem como o NuIEEE, estiveram à altura dos acontecimentos.

Foi uma excelente experiência.

Agora o próximo é já no dia 7 de Maio.

Eu vou dando notícias. 🙂

Até para a semana.

 

ciclo de tertúlias 2014 :: gerir o risco

Na próxima semana (terça-feira, dia 22) a IPMA Young Crew Portugal vai iniciar o ciclo de tertúlias 2014, no Porto.

São eventos muito interessantes (e gratuitos) nos quais eu contribuo para a sua organização.

Nesta primeira tertúlia vai-se falar de gestão de risco e convidamos o meu amigo Sérgio Lourenço (PPM Coachers) e o José Coutinho Sampaio (professor na FEUP e no INEGI).

Vai ser uma excelente tertúlia.

Para os interessados aqui fica o convite:

A IPMA Young Crew Portugal apresenta a 1ª Tertúlia sobre Gestão de Risco, integrada no ciclo “À conversa sobre Gestão de Projetos”, a decorrer dia 22 de Abril de 2014, das 19h às 21h.
Terá lugar na Faculdade de Engenharia da Universidade do Porto (FEUP), sala I-105, com o apoio do NuIEEE.
Inscrições em: http://bit.ly/1fr3MuW
O acesso é gratuito e destinado a interessados e praticantes em gestão de projectos.
Decorrem em horário pós-laboral, em várias faculdades do Porto durante o ano de 2014.

tertulias v1

Eu vou estar presente e espero ver algumas caras conhecidas por lá. 🙂

Até para a semana.

3 talks em 2 dias

Já regressei a casa!

Estive desde Quinta a Sábado no SAPO Codebits e estive desde Sábado até Domingo no team building da IPMA Young Crew Portugal.

Foram 4 dias muito interessantes mas também muito cansativos.

Na sexta feira apresentei a minha talk “Pair Programming” e no Sábado a lightining talk “Estimates Sucks” e 10 dicas sobre “Gestão de Conflito”.

Estão todas aqui e também no meu slideshare.

Em relação ao SAPO Codebits foi o único evento em Portugal onde é possível juntar 900 geeks. Acho que está tudo dito. 🙂

O Team Building da IPMA YCP foi muito bom e tive oportunidade de conhecer algumas pessoas ao vivo que apenas tinha tido oportunidade de conhecer via Skype. Só vos digo que o Sabotage Club, em Lisboa, é sensacional. 🙂

Até para a semana.