Last week Elizabeth Zagroba asked on Twitter:

If someone was completely new to working on software on an Agile team, what would you want them to read about Agile first?

My first thought was: “The Agile Manifesto!” After a second thought, though, I reconsidered and replied:

And I would recommend against reading the Agile Manifesto without consulting any secondary sources, except if you read it in the same way as you would visit a historical site “just to see where it all happened”.

As I wrote this, I could not really put my finger on why exactly I felt this way. The best I could come up with was that the Agile Manifesto is hard to understand on its own. You need some historical context and practical experience to make sense of it. Serendipity came to the rescue, though, as I’m currently reading Seeing Like a State by James C. Scott. Chapter 9 of the book focuses on the Greek concept of mētis (μῆτις) and how it relates to rules of thumb. Turns out that this explains why the Agile Manifesto is a poor introduction to Agile.

Read more…

Yesterday I came across a post on LinkedIn explaining why there are no testers in Scrum¹. What struck me most about the post was the amount of work the word “tester” was doing. In one sentence it meant one thing (a role in a team), in the next sentence something else (a step in the process), and so on. Hence the title of this post: the word “tester” was being used as an overloaded variable. So let’s do some unpacking.

Testers to people management

“Having a tester” means that there are people with the official title of “tester” or “QA engineer” or whatever within the company. For the purposes of people management², there’s a distinction between this role and the other roles in the company. This allows for more specific expectations about the role, for different career paths and salary scales, etc.

Read more…

The past month I’ve been thinking about risk-based testing. This post collects three thoughts on risk-based testing I kept returning to.

If not based on risks, then based on what?

About a month ago I tweeted:

What are the alternatives to risk-based testing?
Requirements-based? I’d argue that’s a subset of risk-based.
Unguided? That’s either a bad idea (“we hope to get lucky”) or aimed at the risk of unknown unknowns.
Any other options? Because something about the term is bothering me.

My question was inspired by the “opposite” heuristic from my talk about testing types: if we have some kind of category, what’s the name for the things not in that category? Applied to risk-based testing: what’s the name for testing that’s not risk-based?

Read more…

In my previous Clojure post I covered the code example at the end of Chapter 4 of “Clojure for the Brave and True”. Or rather, I focused on a single function in the example, called mapify, and described how I figured out what it does. At the end of that post I shared my disappointment:

Having done all this work (and writing) I can’t help but feel a bit disappointed. In the end, the function does not seem to do a lot.

And I shared a Python version of that same function, claiming that it basically does the same thing¹.

However, less than a week after publishing the post, I got a very kind email by someone named Martin. And “in defence of clojure and to maybe reduce your disappointment” Martin pointed out the two versions are not as equivalent as I claimed, because the Clojure version is more general than the Python version. So I looked at the two version again and the way they are different turned out to be quite interesting - interesting enough to write a follow-up post.

Read more…

Chapter 4 of “Clojure for the Brave and True” concludes with a Vampire Data Analysis Program, serving as a summary of the chapter. The book shows some code, explains it, moves on to the next bit of code, etc. I’m not sure why, but I decided I wanted to figure out the code on my own and then read the explanation to see if I got it right. Afterwards I realized it might make a good blog post: both explaining what the program does and what techniques (for lack of a better word) I used to figure it out.

With most of the work in the program being done by a function called mapify, this blog post will focus on that single function. As it turns out, it took me more than 2000 words (footnotes not included) to describe what this function consisting of only 9 lines does. So feel free to read all of it, skim through it, or skip straight ahead to the techniques and some reflections.

Read more…

Almost done with the chapter 4 “Core Functions in Depth” of “Clojure for the Brave and True“! Before wrapping up the chapter with a longer example, a summary, and some exercises, the book goes into lazy sequences, the collection abstraction, and function functions. In this post I will share some notes on infinite lazy sequences and function parameters, making comparisons between Clojure and Python.

Infinite lazy sequences

A lazy sequence is a sequence whose members aren’t computed until you try to access them. One advantage is that it’s more efficient: the whole sequence doesn’t have to be calculated and kept in memory from the start. Another advantage is that it allows you to create infinite sequences. Do that with a normal sequence and your program would never want to stop calculating.

Read more…

K-cards are often used at peer conferences to facilitate the discussion after someone has presented their experience report. Some people really hate them. In my experience they’re a great tool to enable rich conversations. Since the facilitator uses the K-cards to structure the discussion in threads, K-cards allow the group to drill down to the details of the experience report. This instead of the conversation jumping around as person 1 broaches topic A, person 2 introduces topic B, and person 3 wants to return to topic A.

The explanation of these K-cards often takes the form of “This is what each card means.” instead of “This is when to use this card for what purpose.” And despite the elegance of the K-cards system, when you learn about them during the opening of a peer conference, it’s a lot of information to digest. So I hope this blog post will be useful as a written explanation of how to use K-cards.

Read more…

At the second FroGS conf Open Space on 12 March 2022 I facilitated a session based on my blog post “Four skills to embody the four Agile values”. My goal with the session was to uncover more Agile (micro-)skills. In this post I’ll share what we did during the session and I’ll close off with some thoughts on the biggest challenge of this exercise: too many skills. Before I start however, a big thank you to everyone who participated in the session!

What we value

I opened the session with asking people to add stickies to the board of things they valued in Agile software development. When was I preparing the Miro board before the session, I labeled this part of the board “values”. Then I remembered I had decided earlier to label it “what we value”, so as to avoid the discussion about what values are and aren’t. The topic did come up (i.e. the relation between values, ethics and morals), so I was glad I could respond by saying it’s a great topic, but not for this session.

Read more…

If you’re familiar with the Agile Manifesto, you’re familiar with its four values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Recently this made me wonder: how do you apply these values? How do you live them? What skills do you need to embody them? In this post I won’t be sharing any definitive or complete answers, but as a starting point I have identified four skills needed to embody the four Agile values.

Read more…

Earlier this month I started my new job at a small consultancy. During my onboarding I noticed something that I thought could be improved. So I figured I should come up with a proposal to address that. It also made me wonder how me proposing this improvement would go over with my new colleagues. And then I remembered I learned about a good way of doing this in a workshop¹ at the 2016 XP Days Benelux conference. That workshop was about Sociocracy 3.0 (S3 for short). So I ended up proposing two things in the meeting: my improvement, but also a way to come to an agreement about my proposal.

The reactions to my proposal about how to come to agreements, were mostly positive. One person asked a very good question though: “Is this solving a problem we are having? Or is this a solution looking for a problem? What would be the reasons for adopting this?” In response I expanded on my reasons for wanting this and we decided to give it a try. My dual proposal helped here: let’s try the S3 patterns I shared on the improvement I proposed.

Looking back, I’m happy with my reply to those questions and I also feel I can do better. Which makes this the perfect opportunity for my first blog post of 2022. I’ll start with a brief introduction on Sociocracy 3.0, then I’ll share the proposal I made based on S3, and finally I’ll talk about why I like this form of decision-making.

Read more…