Meet Jean-Pierre


I used to be a software engineer with more interest in people, quality and business value than in technical design. Helping teams as Test Facilitator and Scrum Master is a way better fit!

I do my job by being true to myself, that is as an engineer. I convince people with rational arguments while I let people that won’t get convinced experiment and learn by themselves. Humility and kindness, always.

I am the kind of coach that attempts to create an environment where I would want to be a team member myself.



So Jean-Pierre, who are you?


W : What single life event helped defining who you are as a Test Facilitator today?

J-P : A long time ago… I was working so hard to build a new feature that I was working on it day and night. I actually knew for sure that I would fail to deliver working software by the deadline given my previous experience; I never had seen a first version working properly. So instead I wrote extensive test suites upfront. Guess what – it turned out I wrote a first version that worked very well and was delivered on time! That was my personal enlightenment about software testing.


W : My favourite gadget is…

J-P : A whiteboard – does it count as a gadget? It’s an old engineering habit: draw as you talk, things will magically become clearer! Really, it’s true. Protip: it also works with basic pen and paper. Another poor man’s alternative: it does wonders to move around stuff laying on your (messy) desk while you talk.


W : What single life event helped defining who you are as a Scrum Master today?

J-P : At some point in time when I knew nothing about Agile yet, I was given the unexpected opportunity to act as a Scrum Master for my team with the guideline “this time, we do Agile for real.” They said I had the right attitude.

I subsequently read a lot about Scrum and Agile and became a self-taught Scrum Master. This unique experience made me discover that Scrum Master was my calling.


W : What is your favourite Agile principle and why?

J-P : “Working software is the primary measure of progress.” Because when the team have too many “nearly done” items they get swamped and nothing ends up completely done. And in order to completely finish some part of software, you must get everybody to work together in the team: build, run, test, code.


W : What are you particularly passionate about?

J-P : The need for tests and testers in the team! Acceptance Testing, Specification by Example and Behaviour-Driven Development also belong to my favourite foods. Not to mention ACC Matrices! I could talk about it for hours. Are you ready to listen? Risk management is so awesome!