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?

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.

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?

Scrum master or scrum mascot?

Joep Schuurkes — Wed, 23 Aug 2023 11:17:40 GMT

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 mascots¹, so here we are.

According to the 2020 Scrum Guide a Scrum Master² 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 *and* you have sufficient power to influence those outcomes. That's a scrum master. A scrum mascot is a very different beast: they have neither power nor accountability. And yet that seems to be what a lot of organizations (and scrum masters?) want.

What is a scrum master?

Joep Schuurkes — Tue, 08 Aug 2023 12:04:40 GMT

Recently I applied to two scrum master jobs and it got me thinking: what is a scrum master? What is it exactly that they do?

What made this question even more pertinent to me (apart from the job applications) is that in the past I have been a scrum master. But that was five years ago and none of my jobs since had much involvement of a scrum master. And my experiences of those past five years made me wonder: where exactly does a scrum master fit in?

A scrum master is the Scrum boss

The 2020 Scrum Guide says:

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.

A backlog item is a backlog item is a backlog item

Joep Schuurkes — Mon, 03 Apr 2023 06:51:25 GMT

Originally Scrum was very much about "You tell us what needs building. We'll decide how we build it and how soon we'll deliver."¹ I've never seen that version of Scrum. The version I have seen, has a product manager try to get as many features into a sprint as reasonably possible - for varying degrees of reasonable. This comes at the expense of maintenance work, such as keeping libraries up-to-date or removing technical debt. And it incentivizes the team to cut corners on features, to not leave code in a better state than they found it, to not fix smaller bugs and instead log them somewhere for later.

One solution I see to this problem, is to put an engineering manager fully in charge of the team.² The product manager prioritizes the features. The engineering manager prioritizes the full scope of work for the team. That's not a simple change to pull off, however.

Another solution might be to change the way we use our backlogs. If a product manager gets to prioritize all the work, and the tool they use is a backlog, then we should make sure that all the work³ is in the backlog: features, bugs, and technical debt. Let's take a look at each of these three categories of work.