Comunidade NetPonto :: Estimativas: Aproximação ou Precisão?

Foi no passado mês de Julho, acabadinho de regressar de umas merecidas férias em Cabo Verde, que fiz uma talk para a comunidade NetPonto.

Sem um tema em mente pediram-me para falar de estimativas… e assim o fiz.🙂

Aqui ficam os slides e o respectivo video:

Até para a semana.🙂

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.

 

Agile Portugal 2016 :: Wrap up

E lá terminou mais uma edição do Agile Portugal. Este ano tivemos mais de 300 participantes em dois dias completos de evento com 2 tracks de talks em simultâneo mais uma track de workshops.

Gostei imenso de falar pela 4ª vez consecutiva e mais uma vez passar a minha opinião (e experiência) para uma audiência cada vez mais envolvida com os princípios ágeis.

Aqui estão duas fotos do dia:

803e8341-6863-401b-91de-a0b7f24c3dee-original

56f6a7d3-d29f-4084-9347-22633dc50735-large

Pontos positivos a destacar:

  • O apoio que tive visto ter tido cerca de 50 pessoas da Bit | Sonae na audiência (o que mostra claramente o interesse que existe na minha actual empresa em torno do tema) a apoiar-me;
  • Fiz parte do grupo de voluntários que fez possível este evento;
  • O Geoff, o Paul e o Claudio deram keynotes muito ( mas mesmo muito) boas;
  • O Claudio conviveu com toda a gente (durante os dois dias) e aprendi uma mão cheia de coisas com ele.

Pontos a melhorar:

  • O ISEP podia ter feito melhor. Não quero dizer com isto que tenha estado mal… mas podia ter feito melhor;
  • Algumas talks tinham um conteúdo muito interessante mas os speakers não eram bons comunicadores;
  • Acho que faz falta talks em Português. Neste país fala-se muito bem Inglês mas não tenho dúvidas que uma track de talks em Português teria bastante adesão e ajudaria muito quem não se sente tão à vontade com Inglês;

Em relação à minha talk podem ver aqui os slides… no caso de quererem revisitar ou no caso de não terem assistido.

Em relação ao Agile Portugal… para o ano há mais. Mas antes de terminar 2016 tenho ainda dois eventos na minha agenda agile (e que por coincidência serão ambos no Porto):

Em Outubro Scrum Day Portugal e em Dezembro Regional Scrum Gathering Portugal.

Até para a semana.🙂

BIT around the block: Lean Coffee Portugal

Foi com muita honra que apresentei a Bit | Sonae no último Lean Coffee Portugal.🙂

O Lean Coffee Portugal para quem não sabe é um grupo (que tive o prazer de ajudar na sua criação) que fomenta Agile e Lean junto de praticantes, curiosos e de organizações que valorizam as práticas ágeis.

Para quem não pôde assistir aqui fica um video com o resumo do evento que aconteceu no HeartBit, o edifício da Bit | Sonae:

Até para a semana.

Agile Portugal 2016 :: SCRUM VS SCRUMAND VS SCRUMBUT: WHICH ONE ARE YOU DOING?

Para gáudio dos agilistas portugueses já se aproxima mais uma edição do Agile Portugal. Esta edição de 2016, tal como o ano passado, vai ser na cidade invicta, no Porto.

Este ano voltei a ser escolhido para falar e como participo, como speaker, desde 2013 esta será a minha quarta vez seguida.🙂

A minha talk chama-se “Scrum vs ScrumAnd vs ScrumBut: Which one are you doing?” e visa principalmente explorar os conceitos de “ScrumAnd” e “ScrumBut”.

É interessante olhar para as talks que já fiz neste evento e saber que se voltasse a fazer qualquer uma delas iria modificar o seu conteúdo… é o meu espírito de continuous improvement sempre a funcionar:

Agile Portugal 2013 – The Sky Way

Agile Portugal 2014 – Pair Programming

Agile Portugal 2015 – What I wish I knew on my first Scrum sprints

Outra novidade é que este ano faço parte da organização… o que me deixa muito feliz porque sempre quis ajudar a organizar este fantástico evento e fazer parte de uma equipa que conta com o Ademar Aguiar, a Catarina Reis, o Filipe Correia, o João Cerdeira,  a Teresa Carreiro e outras pessoas com quem me identifico pessoalmente e profissionalmente.

Até para a semana.

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.

 

Scrum Master Toolbox Podcast

A semana passada tive o prazer de ser convidado pelo meu amigo Luis Gonçalves (co-autor do livro Getting Value out of Agile Retrospectives) para participar no podcast Scrum Master Toolbox.

Falou-se de vários temas relacionados com Scrum e com situações que qualquer Scrum Master (mais cedo ou mais tarde) se depara ao longo da carreira.

O podcast decorreu durante uma semana, de segunda  sexta, e todos os dias respondi a uma pergunta diferente.

Deixo-vos ficar com os links para os dias:

Até para a semana.🙂