Interviews with Agilists Episode #4 - Arthur Schmitt from Inbox

31 May 2018

Interview with Arthur Schmitt Product Owner

For the first time in the “Interviews with Agilists” series, we have an interviewee who works in the Marketing management field.

Arthur Schmitt works at a French company called Inbox and in this interview, Mr. Schmitt shared genuine examples from his daily work with his team of nine. They are an on-site team that enjoys working on machine learning projects and big data query builders for marketers.

Mr. Schmitt’s teammates are developers and system admins. The team uses different tools and ways to stay synchronized and updated about a project progress like Skype, Gitlab, emails, project management tool.

Q: How many years have passed since you’ve entered “the Agile world”? And have you incorporated any agile practices to make the entire process more suited to your workflow?

A: Our team has been practicing Agile for 5 years now. Over the years, we have started practicing extreme programming, permanent code review, pair-programming etc. We also use different techniques such as Behavior-driven development (BDD), Continuous integration, Unit testing, Test-driven development (TDD).

Q: When it comes to the mentioned techniques, why has your team chosen them and which positive effects can you name?

A: We are developing a big cloud product. We want to have the rolling-release (continuous delivery) and we have short iterations for our development. It’s very important for us not to introduce regression because that can affect all the projects of our clients.

Q: As a Product Owner in your team, how do you formulate your user stories?

A: I follow INVEST.

*INVEST is an acronym which includes six criteria that help with assessing the quality of a user story. INVEST stands for:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

 

Q: How does your team estimate tasks?

A: It has been supported by my experience that more mature teams and the ones who want to boost their productivity make better estimations. My current team uses Planning Poker for estimating tasks. As a Product Owner, one of my jobs during a meeting is to explain the required end result of a task. Later on, developers analyze the tasks and vote. The Product Owner also takes part in the Planning poker session, but only to verify that the tasks are understood clearly. He does not estimate or act as an arbiter.

Q: Tell us a little bit about your Scrum meetings.

A: This is our practice: Development team and the Product Owner are present at all meetings, keeping in mind that the Product Owner can be asked to leave the Sprint Retrospective if the team demands it. The CTO is sometimes present at the Daily Scrum and the Sprint planning meetings. We invite clients and other stakeholders to the Sprint Review meeting.

We consider the Sprint planning meeting as a success if at the end of a Sprint all planned work is completed and if the Development team didn’t take any “back-up” tasks from the Backlog because they were blocked.

To achieve a successful and valuable Sprint retrospective meeting, we use different techniques which include: “Start, Stop, Continue” or “Four Ls Retrospective” (Liked - Learned - Lacked - Longed for).

Mr. Schmitt shared his team’s Definitions of Done and one of their Burndown charts:

Merge-request

  • The merge request has a perfectly clear functional explanation for anyone on the team.
  • The changes made to the code are explained.
  • The test plan is described sufficiently simple to be achievable by anyone in the team.


Test plan

  • Functional acceptance tests are verified.
  • Non-regression tests are performed.
  • There is no new technical debt.
  • The replay of the code has been done.
  • The spell checking is done.
  • All constants read by users are translatable.
  • The safety tests are carried out to verify that no injection is possible.


Delivery

  • The spread is done by Ansible on Dev environments then, if there are no errors, on the Prod.
  • If the task is technical or is a requirement part of a user-story, then it is placed in the user-story branch.
  • If the task is a user-story, then it is placed in the master.
  • All branches of all applications must be merged (or deleted in the case of temporary branches).


Communication

  • The changelog to the destination of the customer is informed and fully understandable.
  • The user documentation is updated.
  • The customer and the teams impacted by the change are informed (Via Gitlab / E-Mail).
  • The task is set to "Done" in VivifyScrum.
  • Above everything else…
    The end user has access to the feature.

Burndown chart
Burndown chart

If you'd like to share your Agile experience with our readers, click the button below to find the interview.

Get Featured

 

Disclaimer: The interview has been edited for clarity and style.