Posted in Uncategorized



I’m baaaack 🙂

Three fantastic news to be revealed at the same time, as I promised.

Thrilling news No.1 as a main course:  
My journey at UBS is over. It was a fantastic time and I’ve learned a lot, however, now it is time to move on. As some of you already know, since September I am beginning my adventure with New Voice Media.
I can’t wait and really looking forward to do some awesome things in the area of testing and agile.

Social news – as No.2 –
I’ve started a Facebook page to keep in touch with my (not only) Polish readers. It will be in Polish:)
I’ll try to post there updates about fantastic testing events (not only) in Wrocław and maybe more of my mobile-related discoveries. Fell free to Like!, Share or contact me through this channel, comment articles, posts and whatever you wish.
I wish it to be a common social IT-related space.

Conference News No3. –
September is going to be a busy month – I would like to meet you all at 3 fantastic events:
21st – QA talk at DataArt Wrocław
23rd – Wrocław Agile Day
28th – SeeTest in Sofia

Let’s meet and have a chat!

And exciting news No.4 –
I do believe that working in IT and earning money obliges us to help the others, who were not as lucky as we are – especially people in need. I always try to support various initiatives such as SiePomaga, Fundacja Gajusz or Fundacja Anny Dymnej.

Can we do more?

Together with quite large group of people from UBS, Credit Suisse, Epam, XL Catlin we’re preparing A MUSICAL called Freedom.
Yeeeeeeeeeees. Kinga Witko will be singing (and dancing – oh Lord) 🙂
All for Fundacja Jaśka Meli.

We do it for charity, but have amazing fun at the same time 🙂

Imagine bunch of IT and bank-related people singing and dancing on a real stage. 🙂 Insane. That will be huge! Our project lasts for couple of months now, but currently it speeds up! Great premiere will take place in April 2018 in one of REAL theaters in Wrocław. I’ll try to keep you updated on social media, as it’s now official 🙂

I would like to invite you all to Wrocław in April to be a part of this fantastic event, but in the meantime – you can support Jasiek Mela – or any other people in need.
Let’s be the change!
Let’s be open.
Let other people grow.


Posted in agile, scrum

I had scrum once. It was… fantastic!

National Sunglasses Day Sale

Hey People!

Why sunglasses at the beginning? It is 34 C degrees in Poland at the moment. Really hot – so sunny kisses for those of you –  who have milder weather conditions:)

Reason No 2 – it will be my last post before well deserved holidays (you can be jealous). Some major changes are coming just after the holidays, but let’s keep it in secret for now;)

Why Scrum again?

After my previous post I was asked if I had an example of nicely done retrospective meetings. Can I recommend some approaches?

I decided to leave theory and books aside for today and focus on practice. This is a unique opportunity of real-life project retrospective memoirs.


Step one – Communication

There is no Scrum, no Agile, no retrospective when people don’t talk. How to obtain it when not working at one spot? The other day I’ve heard of great approach “Pretend you are all remote”, even if some of you is sitting next to each other.

What’s the benefit? We are all at the same page. We are able to talk with the whole team  and at the same time, no one is excluded from important sessions or decisions. From tester’s point of view it is highly valuable.

My experiences with remote work and remote retrospective meetings used to be bad, very bad, actually. When people were sitting in two or more locations – the knowledge, skills and social life were divided as well. Retrospectives were rather rare and ALSO divided. People gathered in some conference rooms, were not able to hear well, some of them were excluded. Do you have such experiences as well?


The change has come.

Unique approach

I had a chance to work in a scrum project once. The real scrum project – with a scrum master, great mindsets and whole bunch of good  Agile treats 🙂
It was not a long-term, but definitely outstanding one.

We were located in three cities, but it was not important. Development team was at the same page all the time. However, great communication and demanding tasks were not the only features that make me think of this project as of the good one – retrospective made it remarkable.

What was so unique? Does remote retrospective really work? Sure it does! All you need is approach, sense of humor and the purpose.

The meeting


Nah, not that kind of meeting 🙂

I’m rather talking about such level of curiosity :

First of all, meetings were recurrent – same day, same time each sprint.
As I wrote before, the need of ritual is essential when talking about retrospective. Next – it was fun!

The scrum master took us by surprise each time. He provided awesome and delicious boards (online boards, of course), on which EACH OF US were welcome to “stick” their notes.

It was virtual – but it worked perfectly well. Going this direction, we had:
doughnuts retrospective, candy retrospective, pink fairy retrospective and so on…

Some of us complained that it is not “serious”, “somebody bought Creative Retrospectives book” or so. We played each time a bit like kids, but at the end of the day everyone benefit from it.

I also would like to highlight, that the funny form and elements of joy were not that important as the method, that made everyone speak and look for both:

  • fields for improvements
  • good things to honor.


How were we able to obtain that? By ‘talking’ or ‘thinking’ for somebody else. What do I mean by that?

Let’s try to rephrase a standard question:

What you are particularly proud of after this sprint?


What was not correct in this sprint?


What a person, who sits on your right thinks about it?
What he is proud of?
What did he achieved?
What was his blocker?

This little magic trick enables your mind to completely different behavior. It helps you to become a team, to acknowledge someone else’s needs and before the next meeting – you’ll ask first:)

As i said, each time we had surprise. Games were different, surrounding was different, but eventually it made a team – and this is all about in Agile, isn’t it?

Catch me on Twitter, I’ll keep you posted (and make you angry) from sunny beach 🙂 Cheers!


Posted in agile, scrum

Retrospective – it matters the most

Is it me only, who thinks that this blog becomes more and more Agile than testing? 🙂



The other day I was trying to describe myself in front of big audience – and I thought that the best sentence would be : a software tester, who fell in love with … agile methodology! 🙂 A friend of mine asked me if I am more a tester or more an Agile creature. As everyone is Agile now – I’d rather  stay with tester’s mindset but Agile way of work. Does it make sense?

Speaking of which – what is the most important meeting for you (if you work in Scrum, of course)?

For me, when thinking about Agile, the most important and valuable meeting that comes to my mind is RETROSPECTIVE. You may agree or not, stating who we are without daily? BUT in my opinion, a retrospective meeting is unique portion of time, when the whole team sits together and tries to improve.

Team as a choir


Let’s imagine that a Scrum team is a choir.

It has to practice, sing and perform together, exchange ideas, spend a lot of time with one another. They do work.
On the other hand, each of choir members practices alone. Each of them knows his notes by heart and can perfectly sing solo parts, but at the end of the day – they have to perform in front of the audience. The performance of a choir is not a bunch of gathered solo parts – it has to sound as one! All voices complement each other and act like human orchestra. Can you imagine your team acting as one organism?

When thinking about this kind of approach – it may become obvious that scrum team has to seat together and have a common goal. For me, a retrospective meeting is that period of time, when a choir meets, has a rehearsal, spends time to improve and acts together.
I do believe that as  voice rehearsals are the most important times of choir work – as daily meetings and retrospectives have the same roles in scrum team lives.
It is all about acting together in order to improve.

The need for ritual


In one of my favorite books about retrospective meetings – Agile Retrospectives: Making Good Teams Great (you can find it on Safari or Amazon) – retro meeting stretches across the whole sprint.
It is not just a meeting, of which everyone would not remember the next day. It lasts. The need for ritual is essential in preparation, conducting and improving. It is always about those three factors. That’s why everyone is welcome to come with his own opinion, problems and successes to the meeting. It is not supposed to be a one-man-show but a choir performance (or just a rehearsal 😉 Everyone is involved!

Leave your negative energy behind

How to act as a choir during retro? How many retrospective meetings, on which one person was a dominant do you have behind you?
Most of us have plenty of negative experiences connected with retrospective meetings (especially in Poland, when everyone is more tend to complain that to cheer up 😉 – please watch this YouTube video by Mark Walters to acknowledge what does the Polish Face mean 🙂 ). BUT complaining should not hijack the retro spirit !!!

Negative packaging is the first things the listeners see. Complain energy is tricky to handle. That’s why each of you should come to the meeting with your own mind. That’s why scrum masters use “stupid” games, “ridiculous” colorful sticky-notes and act (sometimes) like children :). Simply, in order to avoid a situation when only one person, one point of view and one problem matters. Everyone should be influential and benefit from the meeting.

A developer


A development team consists of… DEVELOPERS! Brilliant, isn’t it? And as we all know – developers are the most open, cheerful and ready-to-speak up people in the whole universe!

So… sorry, Scrum Maters, Product Owners and all business-related people – it is not an easy task for you to make them speak during  retrospective meeting:)
How can you encourage a technical person to do so?

Honor the heroes!

Bring sweets!

Hear success stories!

Don’t push!

Capture and analyze metrics  (technical people feel more comfortable with numbers)

Bring more sweets!

Always look on the bright side of life


Exactly. Speaking, complaining and honoring mean nothing if you don’t benefit from it. Sooooooooooooo – get it done!

Collect ideas in order to improve. As a choir during rehearsals:

practice, improve, repeat

Summarize your thoughts in an email, wiki or any other source of common project knowledge. Make your ideas and improvements visible.

Buy yourself a whiteboard, prepare a virtual Jira board. Do at least one thing to emphasize your conclusions, enable each team member to have an access to it.
The more you know – the more you are able to improve.
And remember – your conclusions from Reareo No1 might be a great beginning of Retro No2 and so on. It is a circle and a teamwork.

Good luck! May the retro-force be with you.

In case of any ideas – don’t hesitate to stalk me on Twitter or comment down below. Cheers!



Posted in Uncategorized

Don’t estimate bugs!


Don't ESTIMATE bugs!

Hello from abroad!
It seems, that when I am far away from home – I have more time for writing 🙂


Bunch of thoughts for today were a base for presentation, which I am preparing for SeeTest in Sofia. I have an honor to be a speaker at this well – known testing conference – it excites me a lot.  I would also like to encourage you all to come, discuss, disagree or simply say “Hi!”. Looking forward to it!



The other day I came across this fantastic article about estimating bugs, written by Bob Hartman . He says: “I tell people in my classes I only know two sizes for defect fixes: 1) Trivial because I already know what’s broken and how to fix it, or 2) Infinite because I have no idea what’s broken or how to fix it!”.

I like the idea of Infinite bugs, because, especially when you are in a project-hurry, all bug fixes seem to least forever.


To be honest, this is the definition I was looking for a long time. I am not sure if you have similar experiences in your projects, but each time in one of mines pressure appears – the pattern is quite predictable.

PM pushes -> developers try to declare (or predict using black magic) how much time do they need to provide fix.
Let’s state it clear – saying anything like we’ll knock out X bugs this iteration  or I’ll fix it today – that is a lie anyway.

When we are clear about that, let’s try to focus on some Agile theory.

 Scrum anti-pattern

According to Scrum Alliance – estimating or sizing bugs is an Agile anti-pattern. Scrum is such a lightweight way of producing software that things just happen 🙂 We should not interrupt, limit ourselves, state clear deadlines.

On the other hand, when we are focused on quality, but driven by rush – bugs appear.
In addition, they emerge in most unexpected situations. In this case – Agile teams should deal with the problem – fix bugs, but do it within some realistic time frames.
The cleanest way is to add the bug into the current sprint, without sizing it.The context if fresh, so the fixing costs should be low. It’s cheaper and more efficient.

In a contrary – this will (for sure) lower the velocity and reflect the remaining bug-free stories. What is, in my opinion, important – the process should be always a decision of development team – not a PO, PM, manager or whoever is standing above your head and repeating “Is it done yet?”.


The other option of dealing with bugs and keeping the product in a good shape is to plan separated bug-fixing sprint but instead of scrum – run int in Kanban manner.

Whatever you choose – plan and fix – in a most suitable way.

Time matters

What I wanted to highlight – is not estimating bugs itself – but schedule some time for fixing them.


At the beginning. In each sprint. Each iteration.

The truth is, that development tent to be way too optimistic when scheduling time of their work.


It is not matter of good or bad will, but simply focusing on own tasks.
The problem is, that each software project is not just a pure development.
Apart from writing and testing the code, usually it consists of (at least): setting up the environment, failing environment, meetings, discussions. Altogether it ‘steal’ the time. Ironically, it is THE TIME, we want to save.

When our fixed deadline approaches – the pressure rises. The more pressure there is – the more bugs appear. The more bugs appear – the less time for new lines of good code. And here we are. Chasing our own tail.

My thoughts

I’m not discovering a cure for the cancer at the moment, but just reminding you well known fact:

Nine women can_t make a baby in a month.

Nine women can’t
a baby
in a month.

When you add more developers to the project (because you are in a hurry) it won’t help. Either you are a tester or a developer – try to face it:
there are bugs
you’ll have to fix them eventually,
so be prepared 🙂

Schedule time for them at the beginning of the project to avoid the hurry.
Win – Win , isn’t it?

As usual, in case of any comments, ideas (whatever you have in mind) – comment down below or chase me on Twitter.
Have a nice weekend!

Posted in Uncategorized

Geek doesn’t have gender

Geekdoesn't haveBETTER

Hello Boys and Girls!
Greetings from hot Wrocław (27 C degrees today!).

The Geek

If you live in US – it is probably not an issue for you, but here – in Poland (Eastern Europe) – it is still a big deal.

Option 1:

In IT?
Data warehouse?
Heeeeeeell NO!

Option 2:

In Data warehouse?
Do you have a picture?


We may fight stereotypes, run societies, be visible in IT industry, but at the end, there is always a guy asking: “Are you really from IT department?“.

What hurts me the most is adding a noun to words such as: geek, dev, it and so on.
We have ‘geek-girl‘ , ‘IT-girl‘. At the same time we don’t need to have ‘geek-boy‘ or ‘dev-boy‘. When we say ‘a developer‘ – the first thing that crosses peoples’ mind is a guy wearing T-shirt and glasses (another stereotype).

In the world divided into pink ponies and Barbies at one side and violent killers or fast cars at the other-  it is hard to grow a female geek. It’s getting more and more popular to teach women coding or testing (thanks God for such initiatives as Geek Girls Carrots or Girls Who Test), but still – it is a constant fight.

As good as men


A while ago I’ve read a sentence advertising programming course for girls: “We can be as good as men“.


Why not the other way around: “To be as good as women in testing“?

I truly believe that girls are awesome testers. We are able to share our attention to: test, prepare documentation, talk to 4 people at once and polish our nails at the same time:) No, really!

Job search

I can still remember one of my first work interviews for a tester position.
It went well, I believe. I’ve passed a written test and felt confident. There were plenty of us waiting outside the door to hear who is getting the job. I was the only girl there.
None of us had great experience in that field.

Unfortunately, I was the only one who was invited inside and informed by a manager, that he agrees – my results were great – but I am A GIRL. He said, that he prefers to hire even less experienced MALE candidate, because hiring a girl is a risk (pregnancy, lack of knowledge, you know. Ha. Ha. Ha.). It really happened.

A lot of things have changed on labor market since that day (even in Poland!), but I don’t believe that such managers are retired by now 🙂
I’m afraid, that there are still people out there with similar mindset.
We – the women – have to prove each and every day that we are skilled and talented equally as men. It’s tiring, isn’t it ladies?

Stop it – NOW

This is my statement – stop suggesting gender for geeks.
Geek can be either man or woman.
Being smart or talented is not a matter of gender.

When thinking about people – think about their abilities and skills. Fall in love with their brains. Stop asking for pictures. (Unless it has nothing to do with job offers:) )

Don’t get me wrong, I don’t want any special privileges because of my femininity.
Treat me equal, please. That’s all!