A while ago I asked the teams in my department which parts of agile software development they wanted to learn more about. One of the topics that stood out, was: you have a high-level description of a new feature, then what? That’s still quite a wide topic, so the question become on what part of that problem would I focus first.

Quite quickly I settled on feature slicing - for several reasons. First of all, I had noticed teams delivering somewhat big chunks of functionality, split up into development tasks instead of vertical slices. Secondly, a team I had worked with on feature slicing, had gained some valuable planning flexibility because of it. And they continued the practice, breaking up projects vertically. Finally, I was aware that there was a workshop called “Elephant Carpaccio”, focused on feature slicing. So I could use that, or build on it, but at least I wouldn’t have to come up with something from scratch.

The Elephant Carpaccio exercise

The Elephant Carpaccio exercise was invented by Alistair Cockburn¹. Its purpose is to get people to practice “nano-incremental” development, i.e. slicing something small enough you can program it in 15-30 minutes. The exercise tries to bring home its point through exageration: you are asked to slice a very simple application in 15-20 slices, where you would normally do it in 2-3 slices. Then you get five iterations of 8 minutes to build those slices. To me that’s the coolest part of the exercise: you actually get to experience what’s it like to work with such small slices. As Alistair Cockburn himself says about the exercise: “the true learning is the actual programming section”.

Read more…

It’s been a bit more than a year since I posted my first blog post about learning Clojure. And it’s been five months since my last blog post about it. So far I’ve made it through the first three chapters¹ of “Clojure for the Brave and True“. Instead of commenting on my learning pace at the start of every post, I’ve decided that this pace is the pace that works for me at this time, so there’s no need to keep revisiting the topic.

Something I do want to mention is that one thing that triggered me to do some more Clojure was this episode of Gene Kim’s excellent Idealcast podcast with Michael Nygard, in which they spend some time talking about Clojure.

Vim macros

The exercises at the end of chapter 3 got me to try out a lot of things, so I got bored having to type in the commands to copy a line (yy), paste it (p), replace it by its evaluation (c!$), comment it out (gcc), and add a ”=>” to mark it as output. So I learned about Vim macros and recorded that sequence to run when I hit @c. At the end of my (clj 4) post I mentioned I might have to do this. Guess that moment came sooner than I expected.

Read more…

For a few weeks I’ve been thinking about how I would teach Agile¹ in 2021, 20 years after the Agile Manifesto was published. After sharing my thoughts at CitCon Europe 2021 Virtual and having an interesting conversation about the state of Agile and how to teach it, I figured it’s time to write a blog post about it.

Why I started thinking about this

As Allan Kelly stated in a 2018 blog post:

“Agile won the war but lost the peace.”

Everyone is doing Agile, even though very few people are living the dream promised by Agile. This makes it very difficult to use “Agile” as a label, as a name for something. When someone says “Agile”, are they referring to what you’re already doing or to something they think you should be doing?

Additionally, the Agile Manifesto was written in 2001, based on what its authors were doing in the 1990s in response to the common ways of doing software development of that time. And since the Manifesto we’ve seen the introduction of Lean, of DevOps, and of CI/CD. So the amount of history that comes with Agile is large and it raises the question how much (if any) we should teach - especially since a lot of it is folklore instead of history². Doing Agile’s history justice would probably cost more time than makes sense if your goal is to teach people how to develop software in an Agile way³. And a lot of that history was a relatively long time ago, which is why I titled my CitCon session “Teaching Agile to people younger than the Manifesto”.

Read more…

On 30 January 2021 I participated in the Quality Acceleration Peer Conference organized by Huib Schoots and Joost Voskuil. Participants were Alan Page, Areti Panou, Ash Winter, Bart Knaack, Conor Fitzgerald, Rouke de Jong, Gwen Diagram, George Dinwiddie, Janet Gregory, Joost Voskuil, Joost van Wollingen, Martijn Meijering, Rob Meaney, Vincent Wijnen - with Huib Schoots facilitating the peer conference. The main topics mentioned in the invite were: “How can you sell quality?”, “How can you convince people that quality can accelerate software delivery?”, and “What limitations or barriers do you hit?”

Reflecting during and after our discussions on these topics, I realized there are some interesting things going on about how we talk about quality and how to sell it. Enough interesting things to fill more than one blog post, so this will be a four-part series. And I might expand on some ideas in the series after that.

The first three parts covered rather philosophical topics: choosing your value system, exploring what it means to sell quality, and how management paradigms affect quality. At the end of the third post I brought up the main question for this fourth and last post: so now what? If you expect me to get very concrete and specific in this post, I’m afraid I have to disappoint you. What I will do, is share a way to think about actions that has been helpful to me.

Quality is something emergent

Anne-Marie Charrett says in a blog post titled “Emergent Quality“:

“My hypothesis is that quality is an emergent behaviour. It relies on a whole set of independent systems coming together to create this emergent property. We can never truly know what quality is. It’s constantly changing and morphing into different things. For sure, we can provide examples, but know quality itself? I’m not convinced.”

Read more…

On 30 January 2021 I participated in the Quality Acceleration Peer Conference organized by Huib Schoots and Joost Voskuil. Participants were Alan Page, Areti Panou, Ash Winter, Bart Knaack, Conor Fitzgerald, Rouke de Jong, Gwen Diagram, George Dinwiddie, Janet Gregory, Joost Voskuil, Joost van Wollingen, Martijn Meijering, Rob Meaney, Vincent Wijnen - with Huib Schoots facilitating the peer conference. The main topics mentioned in the invite were: “How can you sell quality?”, “How can you convince people that quality can accelerate software delivery?”, and “What limitations or barriers do you hit?”

Reflecting during and after our discussions on these topics, I realized there are some interesting things going on about how we talk about quality and how to sell it. Enough interesting things to fill more than one blog post, so this will be a four-part series. And I might expand on some ideas in the series after that.

This is the third part, exploring five different management paradigms as identified by Carol Sanford in her book “The Regenerative Business” and how they affect quality. The first part was about choosing your value system can be found here. The second part about selling quality can be found here.

Psychological cover and psychological safety

If the challenge of quality is getting several things right (perception, desire, and means) and getting to an agreement among people, how we organize ourselves becomes a crucial topic. As W. Edwards Deming said: “A bad system will beat a good person every time.” Or as Kurt Lewin said in a more neutral way: “Behavior is a function of the Person and the Environment.” An important part of any environment is psychological safety. In episode 155 of their Troubleshooting Agile podcast Jeffrey Fredrick and Douglas Squirrel make an interesting distinction between psychological cover and psychological safety.

Read more…

On 30 January 2021 I participated in the Quality Acceleration Peer Conference organized by Huib Schoots and Joost Voskuil. Participants were Alan Page, Areti Panou, Ash Winter, Bart Knaack, Conor Fitzgerald, Rouke de Jong, Gwen Diagram, George Dinwiddie, Janet Gregory, Joost Voskuil, Joost van Wollingen, Martijn Meijering, Rob Meaney, Vincent Wijnen - with Huib Schoots facilitating the peer conference. The main topics mentioned in the invite were: “How can you sell quality?”, “How can you convince people that quality can accelerate software delivery?”, and “What limitations or barriers do you hit?”

Reflecting during and after our discussions on these topics, I realized there are some interesting things going on about how we talk about quality and how to sell it. Enough interesting things to fill more than one blog post, so this will be a four-part series. And I might expand on some ideas in the series after that.

This is the second part. The first one about choosing your value system can be found here.

Everyone wants quality, right?

In the previous post I distinguished two definitions of quality. If we proceed with the second and more interesting one, value to a person who matters, I would argue that everyone wants quality and is already doing their best to get it. The alternative would be that some people are not doing their best to get the things they value - which seems absurd to me.

Read more…

On 30 January 2021 I participated in the Quality Acceleration Peer Conference organized by Huib Schoots and Joost Voskuil. Participants were Alan Page, Areti Panou, Ash Winter, Bart Knaack, Conor Fitzgerald, Rouke de Jong, Gwen Diagram, George Dinwiddie, Janet Gregory, Joost Voskuil, Joost van Wollingen, Martijn Meijering, Rob Meaney, Vincent Wijnen - with Huib Schoots facilitating the peer conference. The main topics mentioned in the invite were: “How can you sell quality?”, “How can you convince people that quality can accelerate software delivery?”, and “What limitations or barriers do you hit?”

Reflecting during and after our discussions on these topics, I realized there are some interesting things going on about how we talk about quality and how to sell it. Enough interesting things to fill more than one blog post, so this will be a four-part series. And I might expand on some ideas in the series after that.

Quality has two different meanings

On the one hand, we use quality when we talk about things that are obviously better. A $3500 coffee grinder is obviously better than a £50 one. An application that does not crash on you is obviously better than one that does. Almost all other ways to input your phone number are better than these.

Read more…

Yet again it’s been a while since I did some Clojure or blogged about it. This time I’m writing this blog post three months after working on the code on September 5, 6 and 12. I’m not going to dwell on that too long, because other things in my life were more important. I did feel a little sad when this year’s Advent of Code launched and I realized my Clojure is nowhere near a state where I could attempt the puzzles. So I ended up doing the first 10 days in Python, which is twice as far as I got last year.

I also feel like my current approach to learning lends itself well enough to going slow. Taking my time to play around and make notes with while working through a section of Clojure for the Brave and True and then revisiting my code and notes later to write a blog post, does seem to result in stuff actually sticking in my memory. (Disclaimer: am writing this before writing the rest of this blog post.) Slow is smooth and smooth is fast, as they say.

The section I tackled in September is “Pulling It All Together” from Chapter 3, which describes the construction of a piece of code of about 50 lines in which - I’m sorry to say - a hobbit gets hit in different body parts.

Read more…

It’s been more than two months since I did any Clojure - for the obvious reasons. Luckily I did take notes as I proceeded with chapter 3 of “Clojure for the Brave and True“. So the plan is to process these notes into a blog post, which means this post will cover the sections “Data Structures” and “Functions” of that third chapter. Leaving me ready to proceed with the rest of the chapter, i.e. “Pulling It All Together” and the summary and exercises.

Why is there a when?

The part about control flow is actually before the part about and and or which I talked about in my previous post, but according to my notes I returned to it. I don’t remember why to be honest.

The book provides the following example of when:

(when true
    (println "Success!")
    "abra cadabra")
; => Success!
; => "abra cadabra"

Read more…

Recently the topic of test case management tools popped up a few times in my surroundings. In almost all cases I’d recommend against using these kinds of tools and I found myself able to give a few reasons, but also found that my thoughts lacked the clarity I’d like them to have. Hence this blog post, to force myself to think more deeply and communicate more clearly.

Before I go into that, there are a few things this blog post is not about. I won’t be really going into what effect test cases have on test execution, or rather if test cases are a good tool to use when doing actual testing. Personally I don’t think they are and I wrote about my inability to use them in this post from July 2013. For some deeper thoughts on this, I recommend James Bach’s and Aaron Hodder’s article “Test cases are not testing: Towards a culture of test performance“.

What I do want to cover in this post is managing test cases. Having a collection of test cases stored somewhere to re-use across releases and reporting their pass/fail numbers. Both are important use cases for a test case management tool and both are in my opinion a bad idea.

Read more…