Yesterday Elizabeth Zagroba, Huib Schoots, Sanne Visser and I ran another FroGS conf online open space. There were plenty of great sessions, below are some notes from the five sessions I participated in. Thank you to everyone who was there, I had a great time! If you want to join one of our next FroGS conf events, head over to our site and subscribe to our newsletter. From notes to shared documentation culture Co-creation works for code. In what ways is co-creation for documentation different? Why do we talk about "an audience" for documentation, instead of about "the contributors"? The purp ..read more

Becoming a test engineer these days is probably harder than it was for me back in 2006. Back then, there was no test automation, we worked in the slow rhythm of waterfall, and for years I was in a team with other testers or at least had a test manager to bounce ideas off. These days, there's a good chance none of these are true as you start as a test engineer. While most of these changes are good ones (please don't take test automation or agile away), it does make me empathize with anyone who starts their career as a test engineer today. The pace is higher and the skill set is broader. More i ..read more

While there's value in learning all the ins-and-outs of one particular language, its ecosystem and its testing libraries, I think there's also a lot of value in having experience in several. Or at least, in two. If you only know one, you don't really know what's essential and what's incidental to the one set of tools you know. You don't know from experience in what ways things could be different. Picking up a new language is not trivial though, especially if it's your second one. There will be a lot to learn. You will notice similarities between the new language and the one(s) you already kno ..read more

Estimates in software development are hard. There are good reasons not to estimate at all. Work in thin slices, keep cycle time low, and deliver at steady pace. And yet, it's still fair of others to ask: when will this big chunk of work be done? And not "maybe done", but "definitely-I-can-promise-this-to-people done". Ideally you can calculate an expected delivery date based on your current pace and the number of slices in the new big chunk of work. But maybe you don't have the slices yet. Or it's a new kind of work and your current pace won't really apply. Or there are upcoming changes in yo ..read more

Throughout the years I've used quite a few different languages - if you allow me to be somewhat generous with the word "use". One language I actually feel proficient in. Some languages I've only done coding exercises in. And one language I've only used for a total of maybe 10 minutes, but that did really help out a whole team. I do believe we should be that generous, both towards ourselves and to others. For an industry that likes to talk about imposter syndrome, we seem to enjoy saying "You're not a real ... unless..." a bit too much. Listing these languages for myself made me wonder what I ..read more

In 2001, nine years before the first version of the Scrum Guide, Ken Schwaber and Mike Beedle published "Agile Software Development with Scrum". This version of Scrum has some remarkable differences from even the first version of the Scrum Guide. The three things that struck me most about this version of Scrum, were Scrum Master is a management role, preferably by an engineer there is no retrospective, impediments are addressed in the Daily Scrum Sprints are 30 days and have a goal, tasks can be added and removed throughout While I don't want to claim we should return to this old-school ver ..read more

Over the past year, I've been thinking about how testing-related roles are still an unsolved problem in software development. We keep trying different permutations: shifting left and shifting right, being closer to the programmers while not too far from other testers, doing less testing ourselves so we can support others more, etc. And still, to be effective in any of these permutations, you can't let yourself be limited by them. You need to work both inside and outside the existing structures. You have to "be all over the place", in a good way. Testers do testing Let's start with a straightf ..read more

On September 9th I facilitated a session at the FroGS conf open space titled "Agile history, it matters, right?" My main goal was to get input on where to take my Context of Agile site. Before asking for that input, however, I asked the participants three questions about the history of Agile. I figured it would provide a good introduction to the topic. And I was curious how much the kind of person that joins a session like this, knows about the history of Agile. So a big thank you to all the participants! The three questions about the history of Agile The three questions about the history of ..read more

At the end of my first week at my last job I published a Notion page that started with: Inspired by "The agile comms handbook" I'm experimenting with a weekly (internal) blog. No big promises on the content, just the things I feel like writing about at the end of my week. And as this is an experiment, things might change along the way. Please feel free to add a comment, respond to other people's comments and/or share with others! In this post, I'll tell the story of my eight-month experiment with weekly notes. After that, I'll share some tips in case you want to give weekly notes a try too ..read more

During our latest monthly call, Maaret Pyhäjärvi and I spent some of our time discussing agency, accountability and scrum masters. At one point I said something along the lines of: Scrum masters often end up as scrum mascots. Maaret said I should write a blog post about scrum mascots1, so here we are. According to the 2020 Scrum Guide a Scrum Master2 is accountable for two things: "establishing Scrum as defined in the Scrum Guide". "the Scrum Team's effectiveness". Accountability implies (or rather: should imply) corresponding authority. You're being held accountable for certain outcomes ..read more