Hello, I'm Wojciech 👋

The term end-to-end tests is misleading, because the same way the horizon changes when you change you point of view, the “ends” also change when you have a different perspective. I once wrote: Let’s take a look at an imaginary ecommerce app. For a developer from a checkout team E2E test would probably mean: user picks some items, proceeds to checkout, fills in all their details, pays, order is created. But for an actual user, the “end-to-end” means: they were able to find a product that they...

When you're starting a new job, new project, or joining a new team - always make sure you know who your boss is. You need a single source of truth for any doubts. If you have more than one boss, don't trust any of them. Even if they mean well, they won't ever have the full picture. Double-check everything. Have a good one, Wojciech PS. I have lovingly crafted this email using only the best artisanal keystrokes. If you find come across any typos, feel free to fix them yourself and enjoy this...

There’s a phrase a friend of mine shared a few months ago that has been coming back to me over and over: “Senior developers don’t drop things”. There’s a few ways you can understand that, all of them useful: * If you say you’ll do something - do it, delegate it, or write down the details to do it later. * Recognise what’s important and make sure it’s done. * Own your tasks. Even if you need assistance from other people to get the necessary information, even when you delegated it, even when...

In a recent post I mentioned teams of A-players being able to work faster, more agile, and more independent. Of course, those are desired qualities for the team that you’re working on - who wouldn’t want that for themselves? So, a question arises - what does it mean to be an A-player? Obvious answer: it depends. Everybody has their own set of skills that they’re looking for and you can’t be an A-player to everyone. Useful answer: think of what kind of team you’d like to be on and strive to be...

After reading my last post, you might have thought “I’m working on a team of A-players that are free to do their best work, what do I pick instead of Scrum?”. My first answer would be - do Scrum anyway. That seems contradictory, but I’m a big believer in “slow is fast” (“If you need to go fast, go slow. Because slow is smooth and smooth is fast”). It’s very easy to trip and fall on your face when you start running out of a sudden, while it’s much safer to pick up the speed gradually. So, if...

So, we’ve discussed lately what are Scrum’s tradeoffs, now it’s time to weigh them and decide whether it’s a good fit for your team or not. The guideline is misleadingly simple: if you’re faster with Scrum - go for it, if you’re slower - ditch it. But what does it mean “faster”? Well, as Marty Cagan says, we should look beyond Time to Market - the metric when your feature gets deployed in front of your users, but rather focus on Time to Money - metric which means that you delivered something...

In the last email we talked about the (possible?) benefits of Scrum for the development team. Today, let’s get clear about the costs. There’s the context switch cost of having meetings in general and Scrum is widely known (hated?) for being meeting rich. While most of them are like any other longer meeting you might have, the worst offender is probably the daily standup with some common anti-patterns. Sometimes it’s done with a team that’s too big and everybody just waits for their turn to...

Today, let’s dive into the good parts of a Scrum process. I’m taking a limited perspective of the software development team here. There are many reasons organisations choose Scrum that are not listed here. However, those benefits would apply to different parts of the organisation and it’s up to different teams to analyse them. Scrum basically awards a protection for the team, allowing them to stop chasing moving targets. Starting with the idea of a sprint, where the team takes a chunk of work...

This week I wanted to share my thoughts on using Scrum. The aim here is to surface its tradeoffs to help you discuss more easily whether it’s the right fit for your team. Many people have instinctive understanding when something’s not working, but it’s hard for them to put a finger on what the problem actually is. It usually manifests in expressing disappointment with “the process” and requesting to “ditch Scrum”, which often doesn’t really address the issue well. So, let’s start with...

I’ve been (re)reading The First 20 Hours book recently and there was one thing that surprised me and kept coming back. When Josh Kaufman discusses his process of switching his keyboard layout to Colemak and he mentioned that his typing speed improved due to his schedule of deliberate practise of typing words and n-grams in the evening up to a point when he was typing fast enough for his daily work. What he did next was common sense - he stopped his practise sessions, because he’s typing the...