Message sent!

Someone from our support team will contact you shortly.

Get a Quote

Your email *

Tell us why you're considering making a switch:

Schedule a demo

Your name *

Your email *

Number of team members *


Tell us why you're considering making a switch:

Interview with Agilists

Interviews with Agilists Episode #8 - Piotr Majchrzak from Boldare

23 Aug 2018

interview with agilists piotr majchrzak

The initial idea behind our Interviews with Agilists series was to collect as many Agile stories from people working closely with their teams. Interviews with influencers, big Agile names are all over the internet and we wanted to hear a different side that is more familiar to all of us.

This is our eighth published interview, moving us another step closer to a White paper about the real-life Agilists.

Let us introduce you to Piotr Majchrzak, a co-CEO in an IT services company called Boldare. Boldare is a digital product design and development company. It is a Polish company formed by merging XSolve and Chilid.

The company employs 135 people (front-end and back-end developers, mobile developers, product designers, quality assurance engineers, business analysts), distributed at two locations.

Piotr is a company-wide Agile Leader but he sometimes plays the role of the Product Owner. He has been swimming in the “Scrum waters” since 2008.

Q: Since you are not involved in one team particularly, can you give us an example of what your teams are involved with?

A: I will name two examples that I believe give a fair perspective. One of our teams is involved in developing products for a leader in the renewable electricity industry in Germany, building a community of photovoltaic system operators. Another team is helping in the growth of the largest online food court in Saudi Arabia & Bahrain.

Q: It is quite challenging keeping teams synchronized in a large company. How do you tackle this challenge?

A: There are a few ways of handling this:

  • On-demand face to face synchro. We even designed our office with the purpose of supporting Agile development
  • On-demand online by Slack
  • Regular Community of Practice meetings
  • Regular Holacratic (Tactical and Governance) Meetings of the Product Design and Engineering Circle

Q: Did the teams in your company experience any difficulties when transitioning to a new way of work, the Agile way?

A: I think that I won't add any new things to this point. The biggest impediment is the mindset and the fact that we need to change our thinking to the new paradigm. What teamwork means is understood very differently - how to, at the same time, work in a group as part of a team and still be handle your personal responsibilities. And, finally, how to be agile in Agile and still deliver value.

Q: Which techniques do teams in your company use in their everyday work and why did they choose exactly those techniques?

A: Pair programming, Unit testing, Test-driven development (TDD), Continuous integration, Mob programming. I would say that these techniques cover two areas:

  • Knowledge redistribution and problem-solving.
  • Quality Assurance and Security.

In these two aspects, mentioned techniques significantly speed up the process and reduce risks. It means that the team can respond faster to business change and deliver more easily.

Q: This is a regular question in our interviews - what do your user stories and definition of done look like?

A: User story:

As a ____ I want to _____ so that _____

Definition of done:

A Story or Bug is done when...

  • It is defined:
    there's a common understanding between Devs and PO how it should look and behave
  • It is implemented:
    it's coded along with automated tests if required
  • It is integrated:
    it passes its own tests (if any) and all tests in the project pass on CI environment
  • It is reviewed:
    it had its code reviewed and accepted by another developer
  • It is checked:
    it passed manual testing by QA or a developer
  • It is accepted:
    it has been tested & accepted by another developer (i.e. QA\E, QA\BA, or another programmer)
    it has been accepted by Product Owner (during Sprint Review or earlier)
  • It is delivered:
    it has its code committed to a repository
    it is delivered to a proper application environment (xspreview, live, or other project-specific env.)

Q: When the teams estimate tasks, which techniques do they use and how often do they underestimate or overestimate?

A: Often. Currently, our predictability is at 80%. My advice on avoiding these situations is:

  • Make sure that the team understands domain and technology. Monitor output from the Retrospective and if there is a need, try to propose training or other action that could help.
  • Make sure that the team members don’t change too much. Otherwise, they will be forming again. However, if the team works too long in the same team-composition, it tends to decrease productivity/predictability as well.

We use Planning Poker and White Elephant.

White Elephant is a relative sizing story estimation. It is convenient for estamating a large number of stories. In this game, team members take turns. During one, time-limited turn, a team member can take a story from the Backlog and place it in the estimation category (e.g. XS, S, M, L, XL), move one already placed story to a different category or pass his/her turn if they are satisfied with the overall placement of the stories. The game continues until the whole team agrees (or is satisfied) with the arrangement.

Q: Do you hold all Scrum events proposed by the Scrum Guide? Who attends those meetings?

A: Yes, we do. All meetings, except Daily Scrum and sometimes Sprint Retrospective, are attended by the whole Scrum Team, very often with one of our company's Customer Experience stakeholders.

Q: Let’s talk about the Sprint Planning in your teams. When do you consider that the Sprint Planning meeting was a success and how do you achieve it?

A: When the PO feels satisfied with the plan for the business value increment and the Development Team understands what they committed to and feels capable of delivering the Sprint.

Q: Tell us something about the Sprint Retrospectives.

A: Most of the times we use simple Plus/Delta technique to discuss it and gather outputs that will improve the work.

Our main focus is to have a moment of reflection on everything good that had happened and to address tensions in a team in the form of output items that are handled by the Scrum Master (and/or a team) later.

Plus/Delta technique is used whenever the team wants to get constructive feedback. In terms of Scrum Retrospective meetings, team members list the positive things that brought value during the Sprint and all the things that need to be changed in order to start bringing value. This practice encourages team members to focus on changes rather than negative things that may have happened during the Sprint.

Q: We’ve come to the end of this interview, so as the last answer, share with us the good things that Scrum has brought to your teams and to your company in general.

A: The most important benefit when it comes to the team is the focus on the real goals of the Product. Working in Scrum offers an organized but not restrictive work environment, encourages creativity and enables team members to have more impact on the products they work on.

It obviously boosted the productivity. Among other things, we also measure the lead time that decreased by 30-50%.

When we talk about the quality of the products, there are fewer critical situations in terms of errors, and Development Teams are also delivering products with more business value.

Our collaboration with the clients has also been affected. Since our business is consulting, the whole Dev Team talks to the customer (Product Owner and other stakeholders) and also our clients get to talk to multiple people.

I would like to point out that, for the past 10 years of practicing Scrum, I can’t name a situation when I thought that Scrum wasn’t a good solution for my teams.


Get Featured


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