Joep Schuurkes (Posts about agile)

Three basic truths about planning

Joep Schuurkes — Sat, 17 Jan 2026 23:00:00 GMT

A plan is a not-unrealistic scenario for the future

A plan is a valid option to get from here to there, from where we are now to where we want to be. The plan might be difficult and challenging. We night not know all the steps. It might have a small chance of success. But it is not unrealistic.

The purpose of a plan is to change the plan

Plans are made at the start of things. Once we get going, we learn things about ourselves, about the world, about the plan. The point of a plan is not to stick to it. The point of the plan is to get started, learn, and change the plan.

The value of an estimate is in the response to the estimate

It's hard to give an estimate that's accurate and precise. That's fine, because the value is not in the estimate. The value is in the response to the estimate. To elicit a response, a rough estimate based on intuition often is all you need.

The five areas of Agile

Joep Schuurkes — Sat, 01 Nov 2025 23:00:00 GMT

In a previous post I claimed that any set of principles (or methodology for that matter) for good software development should cover these five areas:

collaboration
software engineering
work management
product
reflect & experiment

I mentioned these five again in my post "What is a scrum master?", but that's all I've said about them. That changes with this post. I will provide a brief description for each of the five areas. I'll share some ideas how a list of the five areas of Agile might be useful. And I'll reflect on the question: Are they the five areas of good software development or of Agile software development?

How adding a flex-wrap almost spiraled out of control

Joep Schuurkes — Sat, 23 Aug 2025 22:00:00 GMT

How does a project get to be a year late?
...One day at a time.
- The Mythical Man-Month (anniversary edition), Frederick P. Brooks Jr., p. 153

Last week I found a minor bug in the application my team is building. For every election committee, we have a page showing all sessions of that committee. These sessions are shown as a row of cards. Playing around with the number of sessions, I discovered that the row keeps on growing, resulting in a horizontal scroll bar:

Optimizing for moments of discovery

Joep Schuurkes — Sat, 15 Feb 2025 23:00:00 GMT

This is the third post in a three-part series about my statement "The difference between a test case and a requirement is the moment of discovery."

Last year I wrote about how the difference between a requirement and a test case is the moment of discovery. And how that means that we should be intentional about our exploratory testing. Exploratory testing is just one example of a bigger idea, though: optimizing for moments of discovery.

So what does that mean, optimizing for moments of discovery? Don't those moments just happen? Isn't that what serendipity is all about? I think it's fair to say that you can't make moments of discovery happen. You can make them more likely to happen. That you can optimize for.

Before I go into two practices to optimize for these moments of discovery, I want to talk more generally about moving the moment of discovery, either earlier or later, for both requirements and test cases, i.e. for design and test. Because the two practices will do exactly that: moving the moment of discovery.

Two short checklists for Scrum

Joep Schuurkes — Wed, 08 May 2024 22:00:00 GMT

checklist no.1

Do you add acceptance criteria and story points to each ticket before planning?
Do you have daily team meetings where people provide updates on their progress?
After each iteration, do you report to stakeholders what work was done and what will be planned next?

checklist no.2

Is the team protected during the sprint from stakeholders trying to interfere?
Is a sprint focused on achieving a goal and is how that goal is achieved, left sufficiently open?
Does the team address impediments as soon as they are discovered?

The difference between a dead and an alive Agile Manifesto

Joep Schuurkes — Mon, 01 Apr 2024 22:00:00 GMT

One of my favorite books on leadership is "Extreme Ownership" by Jocko Willink and Leif Babin. I can imagine some people bouncing off of the book because of the Navy SEAL angle, but to be honest I'm a bit of a sucker for the whole military leadership genre.

The second part of "Extreme Ownership" covers four critical leadership concepts, the "Laws of Combat". Curiously enough, you can map these to the four values in the Agile Manifesto. These four concepts do come in a specific order, so you have to shuffle the Agile values around a little bit:

Cover and Move maps to customer collaboration over contract negotiation.
Simple maps to working software over comprehensive documentation.
Prioritize and Execute maps to responding to change over following a plan.
Decentralized Command maps to individuals and interactions over processes and tools.

To me this mapping is interesting in two ways. It sheds a different light on the four Agile values. And it's an example of how I think we should be engaging with the Agile Manifesto, in a way that keeps it alive.

Tackling test automation in a new language

Joep Schuurkes — Sat, 10 Feb 2024 23:00:00 GMT

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 know. Sometimes those similarities will help you, sometimes they will mislead you.

Also, it's more than picking up a new language. There are also the testing libraries you will use and the language's ecosystem (e.g. how to install those libraries¹ or how to set up a pre-commit hook with a linter). That's quite a package.

Never estimate in something that's not negotiable

Joep Schuurkes — Sun, 21 Jan 2024 23:00:00 GMT

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 your team or organization that make any calculation tenuous.

So you have to provide an estimate. And you do. You say "six months". And the other person - from sales or marketing or some engineering director - says: "We need it in three." What just happened is that you estimated in something that's not negotiable. In time, in this case. And the end result is that everyone is unhappy. You have other options, though. You can negotiate in something else than time.

Old-school Scrum was rad!

Joep Schuurkes — Sun, 17 Dec 2023 23:00:00 GMT

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 version of Scrum, I do appreciate how radical it is compared to how software development is done - even today.

"Agile history, it matters, right?" at FroGS conf

Joep Schuurkes — Mon, 11 Sep 2023 07:48:40 GMT

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 Agile were:

When did Agile start?
What lightweight methodologies were represented at the Manifesto meeting?
What did the software development look like that Agile was reacting against?