Scrum Master

Today’s #scrum and #agile thought of the day

By Nicole Forsythe

scrum master


Traditional Marketing Management is On the Verge of Extinction

By Pino Soro

How our marketing team implemented #scrum to become faster and more responsive

Via @ruxit


Pernicious Scrum Anti-Patterns

By Dwight Kingdon

#Scrum anti-patterns in an article at Dr. Dobb’s:…

via Mike Cohn


When SCRUM Stand-Up Meetings feel like an Interrogation

By Thoma Schranz

When #SCRUM Stand-Up Meetings feel like an Interrogation … #agile prodmgmt

Via Paul Brown


That’s all folks!




After a long period away I’m back with more readings.

During this absence  my professional activity moved from Tester to Scrum Master. New experiences, new readings.


And because we are in vacation we have fewer readings.


Rely on Specialists, but Sparingly

by Mike Cohn

Making sandwiches and being specialist. #softwaredevelopment

via Sebastian Malaca


How do you increase velocity?

by  Scrum Alliance

How do you increase velocity? #scrum #agile

via Scrum Alliance

Media preview


How to help a team that is not performing so well

by Luis Gonçalves
How to help a team that is not performing so well – Part II – #scrum #agile #learning #improvement
via Luis Goncalves

Building Better Software

Last week I attended ExpoQA International Conference on Software Testing & Software, in Madrid. There was a lot of very good presentations. Sorry that we can’t attend all of them.

The one that touched me more even wasn’t in the program. But due to a last hour cancelation it was replaced by a presentation by Paul Gerrard about Specification by Example and the Business Story method.

It is amazing when we understand how such a simple thing could resolve such a huge problem like requisite’s flaws.

Some time ago I wrote about these kind of flaws and how we could mitigate them. My theory was close to Business Story method.

The idea of writing Business Stories based on client’s requisites or specifications, describing and giving examples in a clear language, it is simple and powerful. When we send these stories to the client we got the client’s confirmation about the correct understanding about what the he wants.

Whenever I mention Development Team I mean a team of Analysts, Developers, Testers, Technical Writers and User Experience experts.

The truth is that a requisite’s flaw is, most of the times, a communication problem. It happens when the information flows across teams and loose a bit each time it is passed, or a team just didn’t have access to all information.

We all know that a requisite’s flaw is very expensive. This phase is the most expensive where it can happen.

Being a communication issue, why don’t we ever look for experts non IT to help us? An exper in Organizations, a Human Resources specialist, team managers and others, have skills to watch our Development team behavior, find the problems and propose changes.

Why aren’t these people evolved in the Software Development Process definition? Engineers are not the best people to do it, yet we can only fid them in these teams.

What I like most in Business Story method is the fact that it is neither an agile nor a conventional method. We can adapt it to any of them but it still is neither of them.

Another advantage is that the writing of Business Stories is a collaborative process, involving the entire development team.

With this method everyone is automatically informed. The fact that they receive a pack of requisites or specifications, discuss then e rewrite them, consolidates all data among team members. When the client confirms that is really what he wants everyone can start working. Business Analysts write more detailed documentation, programmers write code, testers write test cases while they wait for code to test. All of them have the same information and they are aligned with each other.

It is not necessary to follow a methodology to the letter, instead, we should adapt it to our company and our team, looking to improve our performance.

Construir melhor software


A semana passada estive na ExpoQA International Conference on Software Testing & Software, em Madrid. Assisti a apresentações muito boas. É pena não podermos assistir a todas.

A que mais mexeu comigo, nem sequer estava no programa. Devido a um cancelamento de última hora, foi substituída por uma apresentação do Paul Gerrard , sobre “Especificação com exemplos” (Specification by Example) e o método “Business Story”.

Surpreendente foi perceber como uma coisa tão simples podia resolver um problema tão grave como a falha nos requisitos.

Em tempos escrevi sobre essa falha e como poderia ser mitigada. A minha teoria aproximava-se um pouco do método “Business Story”.

A ideia de escrever “Business Stories” baseadas nos requisitos ou especificações feitas pelo cliente, descrevendo e exemplificando numa linguagem de fácil leitura, é simples e eficaz. Enviando essas “Business Stories” ao cliente, consegue-se uma confirmação da sua parte, do correto entendimento sobre o que pretende.

Sempre que falar em equipa de Desenvolvimento falo de uma equipa constituída por analistas, programadores, testers, especialistas de documentação e user experience.

Na verdade, o problema da falha de requisitos é, na maioria das vezes, um problema de comunicação. Acontece quando a informação é passada sequencialmente pelas equipas, perdendo-se algo pelo caminho, ou quando algumas equipas não recebem a totalidade da informação.

Todos sabemos que uma falha na fase de requisitos é muito cara. É nesta fase do processo de desenvolvimento de software que uma falha tem o custo mais elevado.

Sendo um problema de comunicação, porque é que nunca recorremos a especialistas não IT, para nos ajudar? Um psicólogo especialista em organizações, um gestor de recursos humanos, um gestor de equipas, um gestor de projetos ou outros, têm competências para observar o comportamento das equipas de Desenvolvimento, encontrar falhas e aconselhar alterações.

Porque é que na definição do processo de desenvolvimento de software da nossa empresa, não estão estas pessoas? Os engenheiros não são as melhores pessoas para o fazer, no entanto, só os encontramos a eles nestas equipas.

O que mais gosto no método Business Story é o facto de não ser um método ágil nem convencional. Pode ser adaptado a qualquer um deles, não sendo nenhum dos dois.

Outra vantagem é que a escrita das Business Stories ser um processo colaborativo, envolvendo toda a equipa de Desenvolvimento.

Com este método todas as pessoas ficam naturalmente informadas. O facto de receberem um conjunto de requisitos ou especificações, as discutirem em conjunto e as reescreverem, consolida a informação em todos os elementos da equipa. A confirmação por parte do cliente de que é efetivamente aquilo que pretende, dá o toque de partida para todos iniciarem as suas tarefas no processo de desenvolvimento. Os analistas escrevem os requisitos mais detalhados, os programadores avançam com a programação e os testers escrevem os seus testes, enquanto aguardam pelo código para testar. Todos têm a mesma informação e estão alinhados.

Não é necessário seguir uma metodologia à risca, em vez disso, devemos adapta-la à nossa empresa e à nossa equipa, procurando melhorar o nosso desempenho.

Agile week

This week I dedicated my readings to Agile Testing.

More and more articles are being written every day about Agile Testing what gives us some good insights.

And to relax, enjoy reading the adventures of a bug.

The Agile Tester

by  JoEllen Carter

“The Agile Tester” from JoEllen Carter (VersionOne) #agile #testing #agiletesting

Via  la__steph

Agile Thinking instead of Agile Testing

by Joel Montvelisky

Agile Thinking instead of Agile Testing – #agile #testing #agiletesting

Via  la__steph

Acceptance tests are not enough!

by Anders Dinsen

Another good post from @andersdinsen “Acceptance tests are not enough!” #softwaretesting

via darren_mcmillan

Run, Run, as fast as you can…

by Rob Lambert

Run, Run, as fast as you can…..… via @Rob_Lambert

Via lubaia

Have a nice week!

Plenty of Reading

Shortening the feedback loop

by Lisa Crispin

Shortening the feedback loop by Lisa Crispin – Great!

Via lubaia

Still No Silver Bullets

By Esther Derby

Still No Silver Bullets #agile

Via lubaia

Best practices for “Best practices”

By Markus Gärtner

New blog entry: Best practices for “Best practices”

Via mgaertne

Refactoring and Redesign are Different

by Johanna Rothman

Refactoring and Redesign are Different by Johanna Rothman #agile

Via lubaia

There are three main strategies when recruiting testers

By The Cartoon Tester

There are three main strategies when recruiting testers by The Cartoon Tester

via lubaia

My ABC’s of Agile

By Jason Novack

ABC’s of Agile by Jason Novack #agile

Via Lubaia

Don’t Test It #1 – Crisis In Production

By Eric Jacobson

Don’t Test It #1 – Crisis In Production by Eric Jacobson

Via Lubaia

Bugs that automated tests aren’t good at finding

By Bj Rollison

Bugs that automated tests aren’t good at finding by Bj Rollison #softwaretesting #testing

Via lubaia

Last week readings

A journey in Advocacy
By Lynn McKee

RT @lynn_mckee: My Journey in Advocating for Software Testing #testing #management #advocacy

Via gilbroza

I hate pair programming (and your code and you)

By David J Bland

Interesting #dev read | I hate pair programming (and your code and you)

via Tordf

How Google Tests Software

Via James Whittaker

How Google Tests Software (from J.Whittaker)

via fredberinger

Duplication between BDD and Unit Tests

By  Gojko Adzic

RT @gojkoadzic: new blog post: duplication between unit tests and bdd tests #tdd #agiletesting #bdd #cucumber

via gregmoeck

No Agile Gospel please, just give me Enlightenment

By Martijn Linssen

RT @MartijnLinssen: @stevedenning @fredsheahan @Jabaldaia @ralph_ohr My PoV on #Agile:

Via Ralph_ohr

Ideas about …

Be Creative: Bug Hunting Advice From Top Tester

By a Guest Blogger

Be Creative: Bug Hunting Advice From Top Tester @mumbaitesting Amit Kulkarni tells us how to find unique bugs…

via uTest

Good response to my TDD Apostate post

By  David Bernstein

Good response to my TDD Apostate post:

Via ploeh

Quality? Excellence? What?

By Tanmay Vora

Quality? Excellence? What? ->’Quality is a route to excellence’ #Pmot

Via mkuphal

Pair-programming for testers

By Joel Montvelisky

RT @MrsSarahJones Pair-programming for testers – #agilescout #agilepm #agiletesting

via Ardesco

Best readings

My Tack on Effective Change

by Anthony Marcano

Very good article about the challenge a team faces when moving to Agile. A very nice analogy with sailing!

Blog article: Agile transition, effective change, micro Satir Change Models and sailing… (alert 2 of 4) #lean #agile

via AntonyMarcano

TDD is Kanban for Code

by Kent Beck

Interesting analogy.

TDD is Kanban for Code, the explanation of the napkin:

via KentBeck

Moving to Agile: What the QA team needed to learn

by Devon Smith

Devon tell us about her experience in QA on moving to Agile.

#testing news: Moving to Agile: What the QA team needed to learn.

via testingref

All Hands on Deck

by Shilpa Venkateshwaran

Take it as an example to follow. Good idea.

I like this – All Hands on Deck 2 hours ago

via Lubaia

Cost vs. Risk In Testing

by Derick Bailey

Find your sweet spot!

Derick Bailey: Cost vs. Risk In Testing #testing

via AdrianLogan

ERP Clouds

by Ewald Roodenrijs

How do you think to move ERP into the cloud? Is it possible?

New blog post “ERP Clouds”: How do you think of #ERP and #cloudcomputing and #testing?

via ewaldroodenrijs

Can Computer Code Be Greener? Facebook Thinks So

by David Zax

Is your code green?

Can Computer Code Be Greener? Facebook Thinks So | Fast Company

via Jankovitch