Readings

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 bit.ly/1ol0pFR

Via @ruxit

 

Pernicious Scrum Anti-Patterns

By Dwight Kingdon

#Scrum anti-patterns in an article at Dr. Dobb’s: drdobbs.com/architecture-a…

via Mike Cohn

 

When SCRUM Stand-Up Meetings feel like an Interrogation

By Thoma Schranz

When #SCRUM Stand-Up Meetings feel like an Interrogation … buff.ly/1vZSwvC #agile prodmgmt

Via Paul Brown

 

That’s all folks!

 

Readings

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. http://pocket.co/sLvQR #softwaredevelopment

via Sebastian Malaca

 

How do you increase velocity?

by  Scrum Alliance

How do you increase velocity? #scrum #agile pic.twitter.com/A8fegwxmdQ

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 – go.shr.lc/R76woV #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

(português)

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.

Readings

Don’t Be Perfect

By Cameron Laird

Nice #dev | Don’t Be Perfect http://ow.ly/532PL

via Tordf

Tales from the trenches: Essential test case design

by Darren McMillan

Blogged: “Tales from the trenches: Essential test case design” http://bit.ly/jk7GlA #softwaretesting #qa #testing

Via darren_mcmillan 

Testers!! know your Business (& don’t do that of others!)

By Joel Montvelisky

Posted: Testers!! know your Business (& don’t do that of others!)http://bit.ly/kyNBdn based on feedback by @jerryweinberg to an old post

Via joelmonte

Agile Brings Changes to Key Roles and Responsibilities

By Dave Moran

Posted: Agile Brings Changes to Key Roles and Responsibilities http://tinyurl.com/3rk5fks #Agile #pmiagile

via wvanrheenen

Readings

Bug statistics are a waste of time

By Gojko Adzic

 new blog post: bug statistics are a waste of time http://bit.ly/ixnScj #agile #testing

via gojkoadzic

Agile Planning: My Top Five Tips on Decomposing User Stories Into Tasks

By Mike Kuphal

Blogged: Agile Planning: My Top Five Tips on Decomposing User Stories Into Tasks http://bit.ly/lSvXLH #Scrum #Agile #PMOT
via mkuphal

Does ATDD = Waterfall?

By Adam Yuret

Fantastic post! RT @AdamYuret New post: Does #ATDD = Waterfall? http://bit.ly/iGAQei #softwaretesting

via darren_mcmillan

Revisited – Test Strategy

By Fiona Charles

 Just published: Basics Revisited – Test Strategy http://tinyurl.com/3k3qyx5 & http://tinyurl.com/3b62j5c #testing #softwaretesting

via FionaCCharles

Testers are fixing bugs!

By Trish Khoo

 Blogged: Testers are fixing bugs! trishkhoo.com/?p=327

via hogfish

A Fair Witness

By Pete Houghton

 Nice post RT @pete_houghton: New blog post “A Fair Witness” http://bit.ly/jkYSbh #testing #softwaretesting

via adampknight

I’m part of the ‘Now Generation’

By Ewald Roodenrijs

 New blog post “I’m part of the ‘Now Generation’”: http://bit.ly/kEQGUi #testing

via ewaldroodenrijs

Readings

This week my reading went through the clouds. I read about its usefulness for testing and the problems we should be prepared to face.

Writing about testing was James Whittaker, who continues to explain how Google tests, and Janet Gregory brought back to life Exploratory Testing topic.

To close the week there is an interesting blog post about teams and communities.

Cloud cracks; break down or support 

by Ewald Roodenrijs

Cloud cracks; break down or support http://bit.ly/k0h7J8 by Ewald Roodenrijs

via Lubaia

Frontiers in Virtualization for Quality Assurance

By Cameron Laird

Frontiers in Virtualization for Quality Assurance http://t.co/qUzRCNf#testing by Cameron Laird

via Lubaia

How Google Tests Software – Part Six

by James Whittaker

The Life of an SET in Google http://j.mp/k6sLL9 by James Whittaker

via Lubaia

The Power of Personas in Exploratory Testing

By Janet Gregory

#testing news: The Power of Personas in Exploratory Testing http://bit.ly/kJvBnM

via testingref

The “One Team” defined as a gift economy

By Brian Marick

The “One Team” defined as a gift economy http://j.mp/mFvm53 by Brian Marick

via Lubaia

Back to Readings

This week I’m back to twitter and to reading.

I selected three blog posts about Agile, a special view about TDD evolution and about Leadership.

Enjoy reading.

Building an Agile test practice: Q&A with advocates for quality

By Matt Heusser

Building an Agile test practice: Q&A with advocates for quality by @mheusser #agiletesting #agile http://bit.ly/fUzR2m

Via CMLalle

The Evolution of Test Driven Developers

By Peter  Sellars

The Evolution of Test Driven Developers – http://www.catosplace.net/blogs/personal/?p=854

Via Lubaia

Test Leadership Lessons from Harry Potter

By Pete Walen

New Blog Post: Test Leadership Lessons from Harry Potter http://bit.ly/jm71K6 #leaders #testing #learning #sharing

via PeteWalen

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) http://bit.ly/fvTKR4 #agile #testing #agiletesting

Via  la__steph


Agile Thinking instead of Agile Testing

by Joel Montvelisky

Agile Thinking instead of Agile Testing – http://bit.ly/gL76DB #agile #testing #agiletesting

Via  la__steph


Acceptance tests are not enough!

by Anders Dinsen

Another good post from @andersdinsen “Acceptance tests are not enough!” http://t.co/aD4O1Tf #softwaretesting

via darren_mcmillan


Run, Run, as fast as you can…

by Rob Lambert

Run, Run, as fast as you can….. thesocialtester.posterous.com/run-run-as-fas… via @Rob_Lambert

Via lubaia


Have a nice week!

Plenty of Reading

Shortening the feedback loop

by Lisa Crispin

Shortening the feedback loop http://j.mp/fnhYU7 by Lisa Crispin – Great!

Via lubaia


Still No Silver Bullets

By Esther Derby

Still No Silver Bullets http://estherderby.com/?p=1903 #agile

Via lubaia


Best practices for “Best practices”

By Markus Gärtner

New blog entry: Best practices for “Best practices”http://f.ast.ly/ppBw5

Via mgaertne


Refactoring and Redesign are Different

by Johanna Rothman

Refactoring and Redesign are Different http://s2etx.th8.us 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 http://j.mp/hH01uv by The Cartoon Tester

via lubaia


My ABC’s of Agile

By Jason Novack

ABC’s of Agile http://j.mp/e3cmdJ 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 http://j.mp/fPs5Ap 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 http://j.mp/hyBhlM by Bj Rollison #softwaretesting #testing

Via lubaia

Read last week

Lost in the weeds

By Alan Page

New blog post: http://tinyurl.com/4hqx78a – Lost in the weeds

via alanpage

How Google Tests Software – Part Two

By James Whittaker

How Google Tests Software – Part Two http://bit.ly/eubFbQ #softwaretesting

via fredberinger


Believing you don’t know

By Pete Houghton

Enjoyed this article RT @pete_houghton: New Blog post: “Believing you don’t know” http://t.co/OsM2HkC #softwaretesting #testing #qa

via brownie490


Mending broken windows

By Michael Johnston

New blog post: “Mending broken windows” http://bit.ly/hZzBWO #softwaretesting #testing #qa contributed by @lilmarshmallow

via Darren_mcmillan


The rise of continuous application

By Michael Vizard

The rise of continuous application #testing http://ow.ly/3TMCz #softwaretesting #agile

via fredberinger