Upcoming Public Trainings – “Effective Distributed Teams” and “Kanban in One Day”

I am pleased to join forces with Michał Bartyzel and Mariusz Sieraczkiewicz from BNS IT in delivering high-quality trainings for IT professionals.

This December you can register for one of our public trainings (in Polish) for a discounted price, including some of my workshops:

Full schedule. Feel free to contact me if you are interested.


Goodbye SoftwareMill. Time For New Challenges

Five years ago, together with my friends Tomek Szymański, Adam Warski and Jan Zborowski, I founded SoftwareMill.

SoftwareMill is a unique company – 26 awesome team members, all of them working remotely, flat structure with no managers and full financial transparency. I’m really proud of it.

That made the decision to leave an extremely hard one, but I feel it’s now time for me to look for new challenges. I have decided to leave SoftwareMill for two main reasons:

1) More face-to-face interactions

Over the last years my focus has moved from programming to organisation and leading and coaching people. In short – more talking to people, less talking to computers 🙂 I really enjoy it, but it’s much harder to do remotely, which is why I want to go outside my home office.

I’ve been really enjoying  working remotely for a long time. It has a number of benefits and I’d love to keep them. But since I’ve discovered how much joy face to face conversations bring to my life I want to have more of them.

2) New challenges for my personal development

SoftwareMill is doing great. There are, of course, things to improve here and there, but staying there would be staying in my comfort zone. 

To say I’ve learned a lot at SoftwareMill is an understatement. I’ve learned something from everyone who I worked with. I’d like to say a huge thank you for all the time we spent together, all the conversations and ideas we had. You guys are AWESOME. I am keeping my fingers crossed for your efforts in making SoftwareMill the best place to work for IT workers.

What’s next?

I am taking a short break for a while, but I am open to proposals for collaboration – short or long-term.

My passion is helping teams and individuals to discover and focus on what really matters for them. I enjoy working with teams and on the business side of IT. And in all of this, I aim to make myself dispensable by encouraging self-organisation. 

I have experience and a lot of passion to work in two areas of software development:

1) Building effective, self-organising, motivated teams

either as an Agile coach, trainer, facilitator

or as a servant leader a.k.a. Scrum Master

2) Bridging the gap between business and IT (and users)

as a Product Owner, Product Manager, User Experience specialist or all of them at once 🙂

So… if you think we could do something awesome together or just want to talk, ping me via e-mail, Skype (pawel.wrzeszcz.work), LinkedIn or Twitter.

Visibility Shift In Distributed Teams

“Distributed agile is hard” is what I often hear. And yes, after working remotely in various distributed teams for 8 years, I agree. But I am going to argue that this is a good thing.

Basically I believe that working in a distributed environment is like using Scrum – it does not solve your problems, but makes them more visible. I like to call this a “visibility shift”.

Visibility Shift In Distributed Teams
(photo by slackpics)

With the challenges being more visible, a distributed team can actually make it easier to adapt an agile approach to software development. Especially if it is a team where everyone works remotely (see “Remote Worker, Distributed Team”).

Value vs. presence

Working remotely makes it harder to verify whether someone is at work all the time or not. You cannot look around you and see other people sitting in front of their computers or having discussions.

And this is good. Because without this notion of presence, something else becomes more visible: the actual value delivered. Because at the end of the day what counts is not the fact that we have been to work, but the new feature or a fixed bug.

(Just to be clear: I am not saying that value delivered is not visible in the co-located environment. But in the distributed setup it is one of the very few visible signs that someone was at work. Which is great because this is what agile is all about – focusing on value.)

Communication challenges

If your team suffers from poor communication or endless meetings, working remotely will make this even more conspicuous.

It is really hard to stay awake during a long teleconference meeting. And this is good. Because it shows how useless meetings are in general. And by working remotely you will have less of them, in favor of more asynchronous communication.

Trust issues

Another thing that becomes painfully visible in the distributed setup is lack of trust.

I heard this statement from a manager on why distributed teams are hard for him: “Sometimes I have to go in person to make sure they are doing what they are supposed to”. Others are worried about their employees browsing Facebook instead of working. These are all signs that the level of trust in the team is low. And yeah… such a team would have a really hard time working in a distributed model, because the trust issue would be even more visible.

All in all

So yes, distributed teams do face challenges. But they face them because things that matter, like value delivered, communication and trust issues, are more visible to them. Which is good, because making an issue visible is the first step for improvement.

(originally published at SoftwareMill’s blog)

Retrospectives and Experiments

On team retrospectives this point seems to be the hardest one – deciding upon specific action points. Gathering data and discussion are much easier parts 😉


Here is an approach to make commitment for the action points a bit easier – make them experiments.

Try an idea for a week and see if it works. Put a clear timeframe after which an experiment is collectively evaluated by the team.

Our case

During company retrospective at SoftwareMill we had a discussion on improving our (remote) communication and we were considering using Mumble. Not everyone (including myself) was sold to this idea, but we decided to install it anyway and asked everyone to give it a try.

What brought me round to do the experiment was Tomek Szymański‘s reply to my concerns:

“How can you say you do not like it if you have not tried it?”

Within two or three weeks of experiments we ended up with a different tool (TeamSpeak gave us better quality). For some of teams it turned out bo be their favorite communication channel, other teams decided not to use it, but at least they made a decision based on their experience instead of speculations.

How does it make a difference?

This approach is especially useful if the proposal for an action point breaks the current habit or is somehow unusual, which makes some of the retrospective participants concerned about it. An experiment is a better idea for such a case than trying to enforce a solution.

For a team making the commitment for just a week or so is much easier. And maybe at the point of evaluation (which may happen on the next retrospective) those who were concerned will change their mind.

Give it a try!

So, next time you are stuck on a retrospective try conducting an experiment 🙂 Let me know how it worked for you.


My Talk @ GeeCON 2012

Tomorrow I am giving a talk “Visibility Shift In Distributed Teams” on GeeCON conference in Poznań.

Presentation abstract


If you are one of the geeks attending this great Java conference, join me in Room 8 at 11:30 to learn how working remotely looks like and what happens when an agile team gets distributed.

See you there!