My Dealings With a Pandemic

Beren Van Daele, Running Isle of IT

People who follow my journey somewhat may know that at the beginning of 2018 I decided to break with a great many things and journey onwards. Up until recently, the road (business-wise) has been mainly littered with proverbial candy. Now, in what seems to be a resurgence of the global pandemic, a first real threat to the business has been culminating and will likely continue to do so. This blogpost will give you insight in my thought process and feelings of the past couple of months and what we’ve been doing so far.

The months, even years, that happened before the lockdown now feel like they were preparations for today. The moneybuffer the business amased, the hires, the projects, all of it suddenly shifted from ‘business as usual’ to ‘how is this helping us to survive?’. Let me shed some lights on the cards we’re holding.

Some Dreadful Things

Just before the lockdown, I hired two new people. Joanna is a seasoned event organiser, Aline a junior front end developer. The third employee, Geert, has had a good contract at a customer in media for some time and continues to do so. So steady income from one, while three (including me) are currently costing. We can see a slow decline in our moneybuffer monthly.

You can imagine that events got cancelled overal and it’s extremely difficult to find projects for juniors in such a market. Finding a project for myself at a reasonable rate seems to be difficult too.

20200704_124115

Hiking the Ardennes

For four months, we’ve been trying to find projects for either me or Aline, the front end developer, with no avail. This has been frustrating and stressful to say the least. Please realise that this includes: Countless times of ‘not hearing back’, doing interviews with no feedback or answer, being disappointed on a daily basis. This is difficult for me, but also impacts the morale Aline, who may start feeling like a burden rather than an asset.

Another aspect we face is that ITMatters.pl events were planned, but uncertain. For some weeks we were hopeful to organise them in a safe way. However, now we decided to hold only one event online. These experiences are rollercoasters in a time that one wishes stability.

20200704_160145

Kayak with the team

Some Hopeful Things

Because we have a small organisation that values transparancy and communication I can truly feel everyone engaged to make the best out of this situation. They’re thinking, even to their own disadvantange, about ways to help the business forward. I can feel that they love being part of this. That they subscribe to this ideology. That they want this company to succeed.
This is probably the single proudest achievement for me.

We have a good buffer that will last us some time longer even though I can see that number declining slightly month after month.
I can see Geert taking his responsibility to continuously work and bring in the baseline which we need.
Joanna is using her strengths to enlist people to her cause. ITMatters.pl has had some major setbacks, yet she’s building a flame that is growing brighter day by day.

Aline and I? We’re building something I’m very hopeful for: RiskStormingOnline.com.
She’s shown incredible motivation and aptitude in digitalising this workshop which I feel can help so, so many software projects. We’ve been able to recruit the help of several more experienced people to help us get to something marketable quicker. Check out the beta version here: riskstorming.praxio.be

This Is Not a Cry For Help

This is a window into my head, do with that what you will. As an employer, you take the risk. You reap the profits when things go well and you carry the risks when they don’t. That’s the simple truth.

The complexity behind it, the feelings and many events contributing to your state of mind are much less obvious. There’s the great pressure of having people relying on the company for their income. It’s both a (self inflicted) blessing and burden.
Another challenge is the daily planning for an uncertain future and hoping you’re making the right choices. There’s a constant influx of trade-offs to be made.

Should I invest time to find Aline a project, or make sure she can focus on RiskStormingOnline.com?
Should I accept a less-paying job for myself, getting some extra money, but having less time for others, possibly burning myself out?
Should I put all my eggs in the RiskStorming-basket?
How much more time do we have in this ‘normal market’ until the pandemic hits again?
Do I ask people to go temporarily unemployed and save some money while leaving people in the cold?

These are a few of many considerations that I’ve had to deal with once, multiple times or even daily. All the while, checking in with people around me.
These same people, whom I respect and love, often second guess my decisions. They shake my convictions. They give me hope, but they don’t take it easy on me.

20200704_131206

A much needed weekend together in Belgium

In the future, I may regret some decisions I’ve taken these days. However, I’ve learned a great deal of what it means to run a business during ‘good times’ in preparation of ‘bad times’. I’ve learned to treat advice for what it is: Glorified experiences. Very little people have dealt with running a company like mine, with its values and ideology in a global pandemic situation.

Advice is a form of nostalgia, dispensing it is a way of fishing the past from the disposal, wiping it off, painting over the ugly parts and recycling it for more than it’s worth.
– Baz Luhrman, Everybody’s free

We’re doing well. We could use some more good news here and there, but all in all, our foundations are steady and we’re building towards the future.

IMG_20200717_183637

Daria & Joanna at their own Polish weekend

 

The Relevance of a TestSphere Expansion

Beren Van Daele, Software Testing, TestSphere

The word is out! A new TestSphere expansion is available on the Ministry of Testing Store. I’ll give you the ‘short sell’ first, before going into my personal story of why this deck is a worthy addition.

  1. It’s got an amazing box. No longer will your feeble cardboard box break or tear as it tries to contain your TestSphere cards. The new box is stronger, big enough to hold both the orginal as the expansion.
  2. There are two new categories. The orignial cards focused much on known test techniques, patterns and heuristics which most testers already knew by name or by concept already. The two new categories venture into Operations and Architecture. Why those two? Because I personally feel they are/will become more relevant than anything else for testers across the globe.
  3. 7 Blank bonus cards. For every colour a blank card is added. This means you can customise a bit. We’ll make these empty cards available as a free to print template.
  4. 5 New cards for each colour. Each of the 5 existing colours got 5 new cards that further diversifies and deepens the dimension.

Image from iOS (1)

This is a pretty cool addition that will take your sphere of knowledge into quite different directions. You’ll be exposed to architectural concepts, observability strategies, increased availability measures and processes that will make your application more resilient.

Remember picking “stability”, “performance”, “operations” or… as a primary Quality Aspect during RiskStorming? Well, you now will have a more diverse set of techniques to tackle its possible risks. More improtantly though, the discussions you will have concerning quality will draw more diverse people in and will go wider, much wider than testing. This brings me to my personal insights…

A Bubbling Cauldron

Three years ago, I was a tester with some experience, launching a TestSphere deck that was largely a culmination of what I learned from others. Someone once said I threw some books and blogposts together into a card deck and resold that. I’d debate that, but then again, what’s the point?
This month, again with Ministry of Testing and the test community’s aid, we launch a very different addition to this deck. One that, in my opinion, is extremely relevant now and for the years to come.
Imagine me carrying around a big cauldron for the past 3 years. Consider all the possible ingredients I put in and where I picked them up:

  • Around 50 RiskStorming workshops on various projects all around Europe and one in Africa. 50 workshops, 15+ countries, about 1000 different testers/non-testers. That’s a lot of introspection and feedback.
  • Worked as a Product Owner and Quality Coach on top of growing my own business, employing people in my own special vision.
  • Supporting and advising the launch of a Europe-wide conference on Diversity & Inclusion and the human aspects in IT.
  • Attending numerous Testing Conferences, Development Conferences,…

It’s a lot to digest. Furthermore, because the cauldron has been bubbling so wildly and for so long, the dish wasn’t quite ready up until now.

Some digestible bites

The following are bits and pieces of my thought process, hopefully making clear to you, the reader, why this expansion is relevant.

  • ‘Testing’, be it manual, automated, exploratory, mobbed, isolated, executed, performed,… is a word very few people are concerned about. Many people feel burdened that they ‘should’ be concerned about it, but most people don’t want to be. Compare it to having to clean up your room. Some people really like doing it. Some people really like putting in hours automating some tasks, optimising and tweaking them. But most people just want a clean room and don’t need details on how it got there. I’d be the first person to say that this is irresponsible behaviour, degrading and probably a ticking timebomb. Yet after at least to deckades of trying to convince people of the importance, the industry as a whole becomes more and more hostile.
  • I was hired on a project as a ‘Quality Coach’ where they were vehemently against hiring testing. They had all the fancy stuff: Kubernetes, all the dockers, Kafka, Grafana, some scaling scrum thingy, communities of practice, SUPER COOL STUFF YO. The project had been running for more than a year when I joined. During the two months I was there the project release vision had yet to take shape. When it did, it changed several times and was eventually communicated to the teamleads. Then everyone assumed it would trickle down and the whole team would know ‘the plan’. Three months later, just before the massively important deadline, everyone is working overtime.

20191201_150724-effects

  • Test Automation on the UI and sometimes API level, as in the checking off things we already know, is largely a waste of time and in many, many cases a bad trade-off. A great number of projects could save lots of money by delivering with a bit of a delay and having one person check some flows or printscreens or whatever. The time invested in ‘pushing everything all the time and checking all the things all the time’ is exceptionally expensive. Some projects pull this off, most can’t (efficiently).
  • A very large portion of software projects are driven by personal wants, such as having the new state-of-the-art fancy thingy on one’s CV. Maybe someone wants to show a new shiny on the next demo. What happens even more often is someone saying at the start of the year: “This year we’ll grow by 10%.” with no plan, no risk assessment, only a feeling. I don’t see too much of that sustainable pace or good, honest communication between individuals from all ‘levels.

This works for the most of us. We can do cool things, earn a decent wage and most of us are bathing in luxuary nobody in the course of history could have ever imagined, anyway. So what’s the problem? … we’ll get to that.
I can only conclude that sweeping the dirt under the rug, or stashing all the garbage in the cellar is a good tactic to sell more, as long as the outside is shiny. This saddens, angers even, the idealist in me.

  • People with good testing knowledge, who can also transfer this knowledge to especially managers, leaders, anyone calling shots are worth their weight in gold. Your projects are an endless series of trade-offs. Investing in one thing means neglecting or breaking another. People with a testing mindset, who also know architecture systems or running an application in production, are in a unique position to point out these tradeoffs and can actually point out what is at risk.
  • Marcel Gehlen, a tester/developer/architect/.. turned manager says that Testing is a skill that is very difficult to sell. It is, however, a skill that will help people be loved. His advice is: get a skill, any skill, that gets you through the door. Then do testing.
    Following  the above clean-your-room analogy; customers buy roombas by the dozens. They pay good money for them. When the roomba starts cleaning up a lot more than just dust from the floor, there’s no way they want anything else.
  • Architects & Operations people are the closest people to us who are also focused and reliant on risks. We need to work together, not only mitigate risk, but also accept, tranfer and sometimes ignore risk.
    Only by discussing quality, risks and measures to improve our chances of success, can we do our jobs most effectively. Everything else is a waste of time and money.
  • Testing is an amazing skill. Testing is an amazing mindset. Testing itself isn’t that hard, but being a tester often is. (This is true for many roles in software development)

20191201_151555

My Advice

Expand your knowledge and your vocabulary. No, I’m not telling you you need to code or learn some whatever UI automation tool that’s just a shell on top of Selenium.
I AM telling you to play to your tester strengths:

  • Understand, explain, advocate for- and find holes in systems. Architectural systems, systems that Operations people use to ensure the application runs carefree. You’ll be surprised about the posibilities.
  • Find Allies. You are not the only one concerned about risks. Most people just lack the vocabulary and skills to advocate for measures to be taken. Find people who have those skills and learn how to advance conversations into plans.
  • Have a project-wide conversation on Quality. I’m super biased when it comes to RiskStorming, but in all honesty: I don’t are if you use TestSphere or any other tool. Just please, please, for the love of all the deities: have a conversation and prioritisation on quality aspects, risks to these quality aspects and come up with a plan that manages these risks and measures. It’s not easy, but it’s your job!

And that’s why this expansion is so relevant.

A Heartfelt Thank You to:

The Ministry of Testing, Abigail Bangser, Benny Hofman, Benjamin Fellows, Marcel Gehlen, Melissa Eaden and Thomas Harvey


Still not convinced? Here are a few examples:

Examples

Impartiality
This card is a result from a RiskStoming workshop. Questions started arising such as:
What if the person sat in a wheelchair?
What about facial types?
What about people of colour, different genders…

With the new rage of ‘Artificial Intelligence’ that is being taught by ‘data on the internet’, or whatever subset we feed it, this ‘new’ Quality Aspect is growing ever important.

Will your product amplify our biases & prejudices, or will it enable us to do something about it?

Dark Launch

 

 

“Releasing a project shouldn’t be a big deal anymore, certainly not a reason to party.”

Using Dark Launch, you can minimise risks in releasing by greatly lowering the target sample. Combined with several monitoring techniques, this can be a very cost-effective way to mitigate risk.

 

Distributed Systems

 

 

 

 

 

I guess this would qualify as a ‘new shiny’. Microservices have been on the rise for some time now and they certainly have their use in a great many products. Not all of them, mind you, but many.

They add a layer of complexity that rises exponentially with each added system. They come with their own risks. Risks you better know about when testing these systems as a whole.

In my experience, very little people are actually testing ‘the whole, connected system’, but are content to make suretheir own small microservice does what it should.

 

Feature toggles

 

Another staple in ‘new ways of releasing’. Feature toggles lets you (theoretically) test safely in production. They allow for very, very cool tactics in releasing software.
Just make sure you don’t overdo it.

There’s usually not a good case to keep feature toggles for a long time. If they have fulfilled their use, remove them.

Exploring Company Ideology

Beren Van Daele, Running Isle of IT

The world is undergoing an interesting transition. People being isolated. Negative economic impact. Personal stress, anxiety and financial harships. This is a time that will shape our future in ways we can’t quite imagine. On the other hand there are many positive initiatives rising up on social media. People offering help to the weaker. Companies taking up their social responsibilities and large scale empathy.

Challenging, interesting, worrying.

“Worry, but know that worrying is as effective as trying to solve an algebra equation by chewing Bubble gum”
– Baz Luhrmann

 

Over the past two years my company grew from a one-man-show to a micro-organisation of four. This corona virus situation is also the first real threat to our business since its conception. It’s the first time our company, our values and people are under fire. This post explores several experiences I’ve had in the past days and dealt with in my personal way.

No Secrets, Fairness

The spread of the virus is fast. Very fast. Yet in human time, a couple of weeks, days even seem long when you’re right in the middle of them. We had just hired our fourth team-member and were looking forward to Test Bash Brighton, an event that which would be a milestone for us. As the days unfurled, the certainty it would be cancelled and the questions of personal safety & planning grew unbearably.

When the event was finally cancelled, it was a trigger, at least for me.
I shared to the team an explanation of our financial situation. That it is stable enough for none of them to worry about their jobs at least for several months. The priority is each of our health, both physically and mentally. Daily, we check up on each other.

Because we are a fully transparent company, they know exactly what kind of money we have on the bank, what’s coming in and going out. I gave it to them straight, as I always have. I enjoy the conversations, the ideas and discussions we have and the mutual understanding it brings.

Joanna kicking off ITMatters meetup in Wroclaw.

Joanna kicking off ITMatters meetup in Wroclaw.

Stability & People over Greed

People approached me with suggestions to cut their personal wages by a third or even half. They felt they could make do with less and help the company survive longer with these sacrifices.
I refused.
When we started working together we signed a contract. But much more than that contract, I made a pledge to them, that as long as they are comitted to the survival of the company, the company will support them back. If I can not pay them what they were promised in times of trouble I will have failed them miserably.

Maybe I’m too idealistic and/or I’m unaware of my privilege, but when I read that big companies are cutting down wages or forcing unpaid leave I get very angry. Paying people what they are promised is the absolute bare minimum an employer is obligated to do. It may be easy for a small company to point fingers, but in my opinion these things scale. If you’re in trouble within weeks of a crisis, you’ve been consistently taking too many risks, no matter how big or small you are.

Move Forward

Several things aren’t great for the company. We have just hired a new junior, who’s awesome by the way, but who would now need to find a project in a more challenging market. I’ve not been on a project for three months and one of the teammembers told me to get a project to help out with the financial situation. I love the fact that he felt empowered enough to tell his employer to step up his game. I applaud him for it. (If you have need for an experienced remote working Quality Coach/Product Owner or a junior Tester/Front-end Developer, get in touch!)
On top of this, we’re organising three events for ITMatters.pl this year which face uncertainty whether they’ll happen in the first place. Sponsorship is harder to come by, speakers are more anxious to sign up for new gigs, not to mention finding participants. Finding business is harder, but let’s not let that stop us.

After explaining the team our financially stable situation, that they will keep getting their montly wages and their focus now is on their physical and mental health, the last message to them is to be brave. Adapt if necessary, but keep your projects going forward.

Aline & Geert trudging muddled waters.

Aline & Geert trudging muddled waters.

My Learnings

Deliberate exploring leads to new insights. I see this whole new situation as a chance to understand myself a bit better, what I want to stand for and what I want my company to be. I’m looking for vocabulary to put under words the ideology that is behind Isle of IT, but I haven’t found anything academic or helpful yet.

So in my own words:
I imagine a company of 6 people in total, not more. People who’s responsibility is the sustainability of the company and their own selffulfillment. A place that is fully transparent, fair, open-minded and progressive. Where people listen to each other, more than they speak. Where everyone’s peculiarities, skills, quirks and special powers are valued and openly appreciated. If you still think this is too fluffy and not competitive business-wise, I’m happy to have a chat with you.

I personally think this is the future. That more people will become fed up with the powerlust, greed and fear that governs many big companies and that they’ll build their own micro-businesses that feel more like a family than a machine.

It certainly is a future I’m building for my own and those who want to be part of my family.

Things don't always go as planned.

Things don’t always go as planned.

Releasing? No big deal.

Experience Reports

I’m jogging around in the park when my music suddenly stops and my phone vibrates.

– “Hi, I’m a bit… out of breath, how… can I help?”.

— “We have an issue in production. Our new release is eating away all the server   resources of the server, interfering with another product.”.

– “Ok. What can we do about that?”

— “We need to shut it down.”

– “Fine, shut it down.”

20190804_134955

Biking around the Mt. Blanc

There was a bit more to this conversation, as I wanted to know whether anyone had noticed our product’s malfunction and whether they’d notice if we would shut it down. Plus I wanted to know what would happen with the sending part of the system once we shut down the receiving part. It was a very short conversation though, where I made a quick and straightforward decision.

If this isn’t DevOps…

Why was this so easy? Why wasn’t I concerned/mad/fearful/…?
I was fine, because I understood the situation. 

I continued my run and after some time sent an email to the stakeholders explaining the situation. I started with an apology for the inconvenience, a congratulation for the great teamwork and communication and ended with the sentence
‘if this isn’t DevOps, I don’t know what is.’

The team had told me that the architecture had some possible malfunctions, that it might not scale well. But we had to learn exactly how badly it would be.
We decided to test this in Production. 

20190706_163416

Cat is not impressed.

Some context

We’re using the strangling pattern on already existing functionality. This means that we’re making a quasi-duplication of already existing systems, have them run in parallel and monitor the outcomes. When the outcomes are the same, or better, over a period of time, we know we have successfully replaced the old code. Then we can shut down the old legacy system and have our new one running as a cheaper, faster, better, more maintainable and future-proof system.

The first several releases are all about learning. ‘How do people react to a new, albeit badly, UI?’, ‘How much load does a production-like environment produce?’, ‘Can we integrate with the security partner’s software?’, ‘Can we display our new UI within the old UI without issues?’,…

Minimal Viable Experiments

We’ve learned a ton by experimenting with adding minimal changes and small valuable updates. We engineered the situation where this is possible. We have a management structure that supports this, yet is currently still a bit suspicious. We have the people who can make this happen.

We have the conversations, the vision, the strategy and the shared understanding.
I draw ugly pictures like this:

DWSB.png

What our next release strategy looks like. Simplified.

These ugly drawings don’t make sense when you look at them, but if you were part of the conversation, this is like a vacation picture where you fondly remember the moment and the outcome.

We don’t just talk about finishing User Stories. We talk about making an impact. Saving costs, making money, learning something new that will enable us to make the next move.

During our Blameless Post-Mortem we figured out that the architecture needs a drastic change. This change has been done now, which raises the question: ‘How shall we test this?’.
Remember the ‘sending part of our system’, that didn’t have a receiving end anymore? It amassed a big set of data over this past time and… well,… we could just point that to our new system and see what happens.

This is one of the parts of my job I really love. Strategising, discussing and thinking outside of the box to do a good job, doing it stress-free and doing it with people you enjoy working with.

20190602_173228

Complex structures: Monorail in Wuppertal

We have principles such as:
Bulkhead: Where you have different systems run on separate resources, so that they don’t interfere with each other. The only other impacted product was also an experimenting one.
Feature toggles: Virtually, this is a switch you flip to turn a system, or piece of a system on and off, much like a light switch. *click*, now you see it. *click*, now you don’t.
Dark Launches: We use pilot users, whom we can monitor, talk to, gather feedback from and learn, before we launch to the rest of Production.
Strangler Pattern: Explained above, this helps mitigate much of the risks of developing something new into the old.
Shadowing: Running our new software in Production, but completely invisible for our users. It helps us analyse load, investigate the outputs and evaluating its value.

But also: Eventual consistency, Distributed systems, Logging, Monitoring, Alerting,…

Releasing doesn’t have to be a big deal,…

  1. If you carry them as a team.
  2. If you’re smart about them.
  3. If you create a shared understanding.

 

 

Why my User Stories suck

Experience Reports, Software Testing

I keep on hearing how Testers must make excellent PO’s, because they’re so awesome at specifying acceptance criteria. People tell me how tester-now-POs can mold their user stories in such a way that they must be perfectly understandable and unambiguous.

I’m sad to break it to you, but my user stories are nothing of the sort. I know full well that when I feel ‘done’ with them, they still suck.

Possibly equally surprising, testers with a lot more product knowledge than me were unable to lay bare where my stories, acceptance criteria,… were lacking.

20190401_170005

The hills of Brighton – Devil’s Dyke

How can you live with yourself?

I accept various degrees of uncertainty. I don’t know everything, and neither does anyone else. Typically, at least in my experience, a concept has to go through several phases and through different hands to improve, to grow, to become something valuable.

This is also why the distinction between a User Story and Requirement is made:

  • A Requirement is something unambiguous, 100% clear and never changes. (Reality often proves to be different)
  • A User Story is a placeholder for a lower level of detail, often a discussion between people of different roles.


The examples you often read in blog posts or books that say: ‘As a user, I want to be able to filter on “name” so that I can easily find the product I need’ are relatively easy and make up very little of the actual work. In real projects, user stories are seldom as straightforward.

Most of my backlog is filled with stories that cover learning, investigating, building a proof of concept,… for quality aspects outside of the purely ‘functional’.
Before you can start building a filter, you must first have a minimum amount of security, stability, performance, reliability, observability, user experience… especially if you want to go live frequently and get feedback as soon as possible.

 

Most of my backlog is filled with stories that cover learning, investigating, building a proof of concept,… for quality aspects outside of the purely ‘functional’.

My hands are usually not the first ones our concepts go through. I get them by discussing problems and ideas with stakeholders. This could be a customer, a team member, a different team, anyone who might need our help to achieve something.

The concepts can be in a variety of different states: from very detailed and exactly described so that it’s hard to think about them differently,… to so vague that they hardly make sense.

 

My hands are also definitely not the last ones our concepts go through. As I pass my concepts on to the team, an 8-headed monster tears it apart with their questions, remarks, ideas, alternatives, examples, negative uses,… Which usually results in a stronger, clearer and all-round better view of the goal. Several additional tasks and potentially stories are created with this new information.

Then it gets built, tested, released, used, …

At any of these stages a concept can fall apart, need to be rethought, redefined, holes exposed, unexpected dependencies identified but also opportunities, ideas for innovation, strengthening, or additional business value found.

You have to start over so many times?

It can be frustrating, but this is exactly the strength a User Story has over requirements. They get better over time, they invite discussion and controversy and they result in better software.
From a PO perspective, it can be quite frustrating to get the feeling of having to ‘start over’. I’ve frequently thought ‘Why haven’t they thought of this SOONER?’, ‘why didn’t I think of this?!’.

We all learn new things over time. This is a core principle in agile software development. If we want to build better, we need to allow ourselves and the people around us to gain more and better insights over time.

Stories seldom end. Sometimes they are the beginning of something new, other times they have several spin-offs. The interesting ones, those that bring the most value, often sprout from several stories coming together.

They are not straightforward and that’s perfectly OK.

20190424_174703-1.jpg

Painting of a shipwreck in Church of Piedigrotta

What advantages does a previous tester have?

 

As a PO, I’m grateful for my previous experiences as a tester. Not because of my awesome acceptance criteria specification nor my powers of unambiguously writing down what a feature should do.
Instead, I’m grateful that during my tester years, I learned that:

  • Good software & software creators need time and several feedback-loops to be great.
  • Value is created by intellectual and creative people working together on a problem, not by following instructions to the letter.
  • My input should trigger discussion and controversy, rather than dismiss it.
  • Being able to hear solutions and problems from different people and asking the right questions.
  • Gathering and communicating information in a structured and understandable way to people with different backgrounds and expectations.

Combining these skills and knowledge with a vision & a strategy is how I enjoy being valuable as a PO.

20190420_154252-effects

Monastary in Swietokrzyskie, Poland