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 (, 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)

No Backlog Policy

I hate Product Backlogs’ unrestrained tendency to grow, get messy and unmaintainable.

Photo: Grant Hutchinson on Flickr

How Backlog Was Supposed To Work

Ideally, a Product Backlog should give the whole team a clear roadmap on work to be done.

I remember times when I actually believed this is really possible, even with a huge Backlog, but in practice in every project I worked on I struggled with keeping the Backlog up-to-date, prioritised and consistent.

Then, thanks to Roman Pichler (see Top Ten Product Backlog Tips for example) I understood that the Product Backlog requires a lot of care (well, the same way like codebase does). This includes:

  • Finding right wording for user stories
  • Writing acceptance criteria for stories
  • Managing stories on various level of detail, decomposing them when necessary
  • Removing(!) no longer valid entries from the list
  • Rewriting other ones
  • Getting stories estimated
  • Prioritising
  • and that is probably not the end of the list.

All of this done regularly!

Woow, that is a lot of work!


In practice, most of Product Owners or people responsible for Product Backlog (including myself) do not perform most of these tasks regulary, because the only really important horizons (at least in agile/lean approach) are:

  1. This iteration/week
  2. Upcoming release or other important date, usually within a couple of weeks from now

This means that what actually matters is on the top of the Backlog. All other stories are… well… you can either say “less important at the moment” or, I believe more correctly, “waste”.

No… Well, Maybe

I am a huge fan of “Start With No” approach.

Photo: Nathan Gibbs on Flickr

Hovewer, over and over again I observe the following scenario:

Customer: Hey, could we have feature X in our product?

Development Team: Well… it all depends on your priorities.

Customer: Yeah, this X is really important.

Development Team: OK, in our Backlog next things to work on are Y and Z. Should we do X before?

Customer: Ah, no! Y and Z are crucial too. Hm… Maybe we could implement X immediately after Y and Z?

Development Team: Yeah, sounds like a plan. Although we will still have several important things to do after Z for the upcoming release, so we will have to see how X fits.


Development Team: OK, let’s put X to the Backlog and we will see.

And you know what? Quite often this X stays in the Backlog forever.

This is what I call saying “Maybe”, instead of “No”. Backlog is a safe option to close such a conversation, but unfortunatelly later on no one dares to remove anything from there, so lower part of Product Backlog becomes Idea Trash.

Possible solution

Here is what I suggest:

  • Keep very small, focused “Backlog” (better name “This week” or “This release”)
  • Put a hard limit on number stories in it. In other words, limit WIP, where story in the backlog is also considered as “in progress”
  • Anytime you are tempted to break the limit, remove less important stories from the Backlog
  • Most importantly: Have a clear working agreement that removing an item from the Backlog does not mean rejecting to do it at all. You can add such a story later when it becomes important enough.

I am using such an approach on my Personal Kanban board and I would love to give it a try in a project. Actually, this post is triggered by our hassles with managing Backlog in Codebrag and by writing my thoughts down I hope to convince my teammates to give it a try 😉 [update: We have tried it in Codebrag and it works very well]

The idea behind this is making an issue of “There is always more to be done than our capacity” more (frequently) visible. I believe that having a clear backlog helps having clear mind and making better decisions.

The argument against this approach I hear mostly is that something important or innovative might be forgotten if not written down. I disagree. If a user story really “loves” me, it will come back. Otherwise it is not worth my effort.


Why Write a Blog?

Question grunge
© Artaniss8 | Dreamstime Stock Photos & Stock Free Images

The goal of this post is convince myself to start writing. Argh, wrong. To evaluate whether this is something I want to do 😉

So, why have a blog? I could think of a couple of reasons:

Get recognition to get a better job
Well, not for me since I am not interested in leaving my company.

Sounds good, but I somehow associate such a motivation with learning technical stuff and my current focus is more at soft skills. Still worth considering, though.

Fun & enjoyment
Oh, I love writing. I have recently rediscovered how much I like it, while doing copywriting for new SoftwareMill’s website (sssshhh…).

OmmWriter, which I am using at this very moment to transcribe my thoughts to words, makes the whole act a unique experience.

Change the world
or, at least, part of it. I am not sure whether I want to do that 😉 However, there are things I do not like around me, including the world of IT. With my experience I could inspire change in someone else and this is rewarding.

Get recognition – once again
For other reasons, like spreading the word about my company in a cost effective and enjoyable (see above) way. That sounds good.

Building self-awareness, getting my mind around various useful subjects
I would say this is more or less the same as self-learning, but labeled that way somehow looks more appealing to me. I may also learn something new (or discover I am completely wrong) from the responses.

OK, fair enough. Fun, self-awareness and recognition works for me, probably in this order 🙂 I am not promising you anything, but I believe now I have convinced myself, writing will be easier.

How about you? Why do you (not) write a blog?