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 st 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 approach?

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!




Posted in agile, conferences, scrum

How to become Jedi Master


Lady Vader strikes again

My previous post was about Quality Excites conference in Gliwice. This time I would like to say something more about vivid conversation that took place during my discussion panel.

I had a chance to meet wonderful people and share inspiring ideas. It was an unique opportunity to hear about personal experiences and best practices worth to share.
As I wrote many times before:


How to become Jedi Master?

I do believe that every software tester is a kind of Jedi Knight. He fights for quality and the Quality is his light saber.
Who is a Jedi Master though? A person, who understands agility, quality and has a need for working together.

My best example of Jedi Master, who should lead all Jedi Testers, is Master Yoda. The same one, who talks about Agile:

“You must unlearn what you have learned”


Going further, I’ve asked people 3 – in my opinion important – questions about cooperation in an Agile team:

  1. How to communicate?
  2. How to introduce new people?
  3. How to share knowledge?

How to communicate

Nowadays, it is in job advertisements, small and large companies, everyone works in Agile.


When scrum team sits together – it is a perfect situation.

My concern was if a spread team (team located in several cities or countries) is still an Agile one.

I – Kinga Witko – claimed that spread team is not a real scrum team.

No one agreed with me 😦 Fine. (Misa no wise)


On the other hand, I need to underline here the one and only truth, that emerged as a discussion result:
Spread Agile team MUST use CAMERAS. And talk. Talk. Talk. All the time.

UNIX (1)

This is the fact, which everyone put their attention on. I do agree with that. When we don’t sit together – we talk, ask questions, get angry and happy together. However, when we work together, but there is no day-today interaction between us, we need to stay as close as possible to one another. Talking, laughing (even swearing) are the team-building features.
We are all humans, we have better and worse days. All of us need attention and understating. It is not possible to be achieved via Skype chat or other Slack-ish tool only. Conversation is the key to success within a team.
There is no team without little chats or coffee breaks, sorry!

The other important thing in agile approach is a mindset. If a team member is not eager to cooperate, denies flexibility or talking – it is maybe not the right place for him (or her).

I do agree that agile approach to software making is not suitable for everyone and is not fitted to every project. It is fine.
It is also OK if you are more comfortable with working on legacy code, together with a waterfall approach. You don’t need to force yourself do be AGILE. There is a lot of space within software industry for every style and every tester or developer. Chill!

New team members


In every Jedi Master’s life this day comes – he has to train young ‘Padawans’. Either a new team member, company member or a trainee.

Some time ago I was asked if there is a good way to introduce people into the project? The next question is – how will you know that the new team member IS READY to perform on his own.

Surprise! Surprise! (there is none)

People are not robots, it is not possible to predict what will happen. Going this direction – there is as many ways as Masters. The way you teach usually depends on your skills, empathy and understanding. And good will, of course!
There are such things as company values or project – related directions, but – AGAIN – conversation is the key.

People on my discussion panel suggested clever solutions, such as:

  • never imprison new testers with boundaries – let them explore your software
  • teach through example
  • less talking – more doing
  • provide documentation and lot of freedom.

Again, it depends on your skills and new-joiner’s abilities, what is possible to be achieved. Another point in this discussion is a recruitment process. If a correct person is selected, he’ll perform good testing in a short period of time.

People spotted also, that a new team member is fantastic benefit and opportunity for ourselves. In the position of trainer we are able to:

  • learn how much do we know
  • acknowledge our limitations (Context Driven Testing)
  • explore with a fresh look (Exploratory testing)
  • find unknown bugs
  • fix old bugs (for example those, that everyone got used to)
  • avoid knowledge silos.

Knowledge sharing


Modern companies have lot of ideas to share knowledge. Most of the times, employees are able to run or attend cross-team / cross-technology workshops or presentations, take part in training or read books.

As I love to collect clever knowledge-sharing ideas – I’ve asked people “How do you share knowledge in your teams/organizations”.

Some of you may already know Michał Buczko – he encourages developers and testers to work in pairs (Pair people!) – it is a convenient way of broadening your horizons and extending knowledge.

In order to share knowledge, you may also “rent time”.
It may be an hour / day of a developer, tester or other team or company member.
How to do that? Just book a time with the person and take part in his / her day. You can exchange afterwards – it’s up to you.
I know that there are companies, which even “swap” jobs among completely different departments to FEEL the other person’s real working environment (I’m talking about you – Ocado:). All of those brilliant ideas may seem tiny, but they really work and empower people to do ingenious things.

Maybe some of those practices shall be a software company standard at some point?
I wish it to all of my test-buddies and to myself as well.

Should you have any comments, ideas, things that work fine at your company and you would like to share – comment down below or stalk me on Twitter.

I hope you’ve enjoyed the summary – see you all on my next discussion panel 🙂