go back to the blog

From the webinar: Q&A with Jeroen Mengerink

  • 11/09/2013
  • no comments
  • Posted by EuroSTAR

Below are Jeroen’s responses to questions posed at the webinar ‘ Test Improvement for Agile’ which took place on Monday 26th August 2013.


Q: Can you give a detailed example of one of the numbered boxes of the Key Areas you mentioned?


Of course I can. Let’s do the key area teamwork.
A checkpoint in the forming level is: “The team is co-located.” This might seem like a strange checkpoint since distributed Agile is also practiced a lot, but in my opinion the best work will emerge from a team that is co-located and if we want to improve the teamwork, co-location is the key.
When we look at the performing level of teamwork, a checkpoint is: “Team members know and value each other.” This means that you need to know about more than work related topics. The team will bond more if a more personal connection exists between the team members.


Q: Is there a publication describing the TI4Agile matrix?

Q: Where to read more about this assessment?


There’s no publication yet that goes into detail. On my blog ( you can find some posts on Agile and the service TI4Agile® is described on the Polteq webpage ( Whenever there is a publication, it will be announced on the Polteq website and social media.


Q: Do you know if there is an improvement model for Agile or Scrum? Focussing on the development process?


Yes, there are several models to improve Agile/Scrum. Google on Agile Maturity Model will provide you with a lot of links. One of the posts on Agile maturity that I like a lot is: ‘Yet Another Agile Maturity Model (AMM) – The 5 Levels of Maturity’ (


Q: Will your TI4Agile model be available similar to the TPI NEXT model?


Yes. At the moment we’re still fine-tuning the model by using it at different customers, so you will have to wait a bit before it comes available.


Q: Hi Jeroen, a question about the ‘good practices’ you talked about. Are these the ‘strengths’ out of a SWOT analysis in the assessment?

A: That’s indeed how the good practices came into existence. The strengths of different companies can be abstracted in to good practices that will help other companies. Next to this, a lot of weaknesses also provide the foundation for a good practice. We have supported many companies in improving their (Agile) testing and from our experience and practice we derived good practices.


Q: Hi, thanks for the webinar! If we do not report defects, aren’t we losing data that will help us to improve on the long term?


Yes, we are losing data. Please note that I’m not advocating reporting no defects. I’m just stating that within the Agile context, we want less overhead and waste. Managing defects takes a lot of time, so if we can reduce the number of defect to manage, we win time. Improvement in Agile is continuous. After every sprint, the team will take note of lessons learned and improve on areas that come up in the retrospective. By improving this often (every couple of weeks) you also ensure a solid long-term improvement.


Q: Any suggestions on how to think from the perspective of the other roles? Maybe by pairing?


Pairing is indeed a good option to learn how the other roles think. Another important option is by taking (basic) courses in disciplines outside your main area of expertise. By doing these courses in the areas of the other disciplines, you get to know a lot about the work of your team members. You do not need to become an expert in all disciplines, but knowing the basics will give you an edge over people that don’t.


Q: I understand the thoughts behind not logging a defect that is fixed by dev when reported, but how does that impact the visibility that agile brings? Is there any loss of information by not recording it?


Yes, some information will be lost, but this usually is not a problem. Make sure that you have a clear decision process on what to log. In my projects I try to log all Critical and Major defects, even if they are fixed immediately.
Lower level defects depend on the judgment of the reporter and on the time to fix. If the reporter believes that it is necessary to preserve the defect information, it should be logged. If it cannot be fixed within one or two days, log it. Of course these guidelines differ per project, since taking the context into account is important.


Q: Have you experiences with distributed Agile teams that you can share?


The first problem with distributed teams is one of communication. In distributed settings we need supporting tools to provide us with enough means of communication. Think of Skype, Google hangouts and other forms of videoconferencing. Notice that I choose communication methods that all provide sound and video, since using both is the richest form of communication. Team bonding is also more difficult. To improve bonding, make sure that the people meet in real-life too. A regular (monthly, bi-monthly or something else fitting) exchange of persons over the different locations, will allow them to meet with other team members.


Q: About metrics… do you report defects found during the sprint?

There has been some discussion about that not being fair. Teams should be able to find as many defects as they want during the sprint. But what is found after the finished sprint is relevant. That shows the quality of the sprint. From a tester’s perspective it is of source good to show how many defects the developers slipped through, but it is not very agile (whole team idea) to think like this.


Yes, I do report defects found during the sprint. We need to provide this transparency to earn the trust that is so much needed for this development method.


Q: ISTQB says that we cannot base on one person and human because when it’s gone we cannot or it’s very hard to rebuild team.


And ISTQB is right on this, but so is Agile/Scrum. By sharing the knowledge within the team, you always have multiple people that know enough to help a new team member up to speed. Also, it’s never said that there always is just one tester in a team.


Q: How and where we can we write down team work requirements and most frequently repeated problems?


Team work requirements can be written in a Definition of Done kind of way. Make a list of the requirements and put it up next to the scrum board. This can of course also be done for the frequently repeated problems. The problems also need to be part of the retrospective.


Q: Hey, Basing on your experience, do you have any suggested choice of management supporting tools / defect tracking tools?


Personally I prefer Jira for project management and defect tracking, but you must choose the tooling that fits your specific needs. It’s nice to have tooling that supports multiple needs.


w17 - jeroen mengerink web (78x100)Jeroen is a test consultant for Polteq. Next to his work for clients, he is involved in various test innovations. His main area of expertise is Agile. Jeroen teaches several test courses e.g. about Agile (CAT), SOA and Cloud. He is co-author of the book and approach Cloutest(r) on how to test when cloud computing is involved. He has contributed as a speaker to various events for Polteq and her clients. In international assignments he has presented the results of TPI assessments to senior management. He presented several times at events like EuroSTAR, ChinaTest and TestNet on a large variety of subjects.
agile content CTA

Blog post by

go back to the blog


Leave your blog link in the comments below.

EuroSTAR In Pictures

View image gallery