Tim Schraepen's Blog Yet another developer blog.

DareFest 2016

DareFest 2016

This year I got the opportunity to find out what all the fuss on DareFest was about. I went the full three days, from Wednesday the 24th of August until Friday the 26th, smack dab in the middle of a rare heatwave.

DareFest is a conference (but more of an unconference actually), with speakers, workshops and side activities, on diverse technological topics. To give you an idea, there was a BlockChain workshop, a VR try-out, talks on new organizational culture (sociocracy and management 3.0), BioHacking, and a lot of stuff on design (both in fashion and in future technology).

The way I picked which thing to go to, was purely based on title because there wasn’t a lot of other information.


First thing I went to was a workshop on How we use gamification in service design. Dave Van De Maele from KnightMoves, showcased their game called Kingdom. We got to see the cards and play around with them on a hypothetical problem of fixing Antwerps mobility if no cars would be allowed inside the city. Read more about it here.


Then I went to Winnie Poncelet’s talk on DIY Bio, a movement that tries to opensource and democratize bio-engineering. Works well with home-made stuff like 3D printed containers etc.

They have a Code of Ethics.

Out of this movement some interesting initiatives have sprung up, like Epidemium, who have a program called Challenge4Cancer; opensourcing cancer research.

My biggest take-away was that if we leave bio-engineering to scientists only, we’ll dumb down society. Which will lead to delegating even more to scientists, causing a downwards spiral. And DIYBio is trying break the cycle.

Also: mushrooms as a replacement for all the things! (like leather, road-lighting, …).

Get your hands dirty at one of the labs in Ghent - Reagent (nl) or Namur.

Project Leven

Then I saw a talk on biohacking, or Human+, I’m not sure what the difference is.

Peter Joosten (@wpjoosten) talked about his life as a human labrat, all the different things he’s been trying out on himself.

Like various diets he’s tried, how he tried not ejaculating for a month, daily cold showers, … You know, normal, weird stuff.

He also demonstrated how to do a burpee for some reason.

He explained there are so many ways to measure everything about your body nowadays. For example you can send your poop to ubiome. Or find out what your DNA can do for you with 23andme.

After you gathered this data, there are some ways to improve as well. He was very excited that there are going to be human trials with CRISPr. If you haven’t heard of CRISPr yet, I urge you to listen to this RadioLab podcast right now.

He also mentioned Epigenetics, something I still need to look up, but it’s about modifying your environment to change your DNA or something.

Then he concluded by giving his 3 tips to do every day:

  1. Sleep enough (because you can’t gain back lost hours of sleep, and sleep deprivation is detrimental to your health)
  2. Get at least 30 minutes of sunshine/outside to recharge your body
  3. Hang (to stretch your back, and reduce lower back pain from sitting all day or even standing at your standing desk) He also mentioned alternate breathing, a technique where you breathe in through one nosehole and out the other. It helps calm you down in stressful situations.

Visit his website to see if he’s still alive or how he has improved his life.


Guerilla Leadership

In the afternoon I went to a Guerilla Leadership workshop, hosted by Herwig Deconinck and Lisa Boelaert. It wasn’t really a workshop in that we didn’t get to do all that much actually, aside from one super awkward exercise where we had to lose the thing that was holding us back by marching straight for our goal. With someone literally holding you back by the shoulders.

The other thing that annoyed me was that the speakers were trying to sell this method.

In the end they gave us 10 commandments, which do make sense and they had nice examples to go with them.

  1. Unite around a shared purpose
  2. Focus on Chances and opportunities
  3. Make it Small & Make it Happen
  4. Confront reality & Create transparency
  5. Make people feel strong
  6. Make success possible & feed resilience
  7. Be authentic & trustworthy
  8. Talk straight
  9. Build the bridge as you walk on it
  10. Right your wrongs

We shared what action we were going to take, or had done already, related to one of the commandments.

Here’s what everybody came up with.

After the workshop I asked about how to feed resilience, more specifically how to combat demotivation. And I distilled the excellent feedback in to the following points:

  • Define the common goal with your group.
  • Prepare for negative criticism and setbacks. So plan them in, make this concrete with your group (of guerillas)
  • Pull each other up when this happens. Every one in the group has a responsibility to be aware to this demotivation hitting the group. And you help each other get over it.
  • Create awareness loops to help “plan” demotivation hits.

Too bad they put up such a show to share such valuable information.

Pulling in the same direction with autonomous teams

Easily the most interesting talk of wednesday.

Manuel Küblböck works at Stylight, a German company that grew from 4 to 200+ employees, but managed to maintain their 4-man values and way of working (they scaled autonomy).

According to Manuel, there are three practices that they do that make that happen.

They use OKR’s (proper ones), Sprint Planning, and UX Research that feed into each other and most importantly, into the clearly defined company strategy.

The Shared Understanding this creates, along with defining proper OKR’s, create certainty, and certainty leads to happiness.

Another tip he gave us was to NOT use OKR’s as a performance review tool because you’ll set too low of a bar for yourself. Because there’s a reward tied to it. This is true for any target setting.

And yet another tip was to not become too short-sighted. Doing those OKR’s weekly makes it easy to make only quarterly goals, and lose view of the bigger context.

He’s written a magnificent blogpost about it already, so go ahead and read that in stead of my mumblings.



I did go to some company sponsored talks about Blockchain which were mostly commercialisation attempts. But I also went to a workshop that made the bad aftertaste go away.

Bart Waeterschoot (@bytesizebart), the guy that hosted the workshop, recognized me from one of our Software Factory visits. He used to work for SDWorx, and now works for a KMO called bITe. Who apparently are doing stuff with blockchain tech.

His talk/workshop was entertaining, he himself is very knowledgeable, and is able to clearly explain problems and how blockchains work etc.

I learned a lot, and was able to ask all the questions I still had. AND he had a live demo. Very cool workshop!

Here’s the github repo that used Ethereum (or more specifically Truffle) to build a so called Dapp (decentralized app).


Happiness for Teams

In this workshop, excellently hosted by Frederik Vannieuwenhuyse (@vfrederik) and Dieter Dehaes (@dehaesd), we first drew a personal context map of our neighbor by asking questions.

Afterwards someone else at our table had to explain who someone was based on the context map. Pretty cool!

I also learned that not everyone has legible hand writing. :)

Then we did the Moving Motivators game from Jurgen Appelo’s Management 3.0. Which gives a lot of insight into yourself: what motivates me, and how do motivators change in some events.

My motivators are in the middle.

After event x happened. The Goal card is the baseline.

We finished up by giving feedback about the workshop to other people in the workshop using the Feedback Wrap. Which reminded me of course about Dan North’s How to make a Sandwich.


How to develop a creative culture within your organization

Presented by Pieter Daelman from Bedenk.

Alongside the university of Ghent, they have been doing research for 3 years, on how creativity works in companies. Which culminated in to some kind of framework that should help with instilling creativity in all layers of your company.

They call it CReative Organisation MAtrix or CROMA.

It’s basically a checklist in form of a matrix, check his slides to see what the matrix looks like.

This checklist, or rather radiator, gives a company an idea on how they’re doing in every quadrant (there’s 9 in total). 3 levels: Individual, Team and Company. 3 phases: Orientation, Idea creation and Promotion.

He gave some real life examples for every quadrant, so we could get an idea on how other companies or people improved that quadrant for them.

For example, aside from Colruyts Red Phone, where any customer can call them and tell them they saw a cheaper price at a competitors. They also have a Green phone, only for employees, that use it to share their improvement ideas with someone directly connected on the other side of the line.

It’ll get registered, and afterwards they get personal feedback on why it got approved, and if they’d want to join the implementation team, or why it didn’t get approved with a proper explanation etc.

That was an example of the Company + Promotion quadrant, where Decision making & constructive feedback live.

CROMA is based on scientific research, and basically works like any other organisation framework, like CMMI e.g.

Bedenk helps you create a matrix radiator, and facilitates actions etc., and they’re also releasing a book about it, coming this december. And we got the premiere about this new framework at DareFest.

My initial thoughts are that it seems like it’s overkill and might be a bit avant-garde at the moment, but that it might work very well to sell to higher management, while the working class reaps the benefits because most examples are about employee empowerment.

Education in the Exponential Age

Deepak Mehta (@deeeep) made me chuckle with his rant on Plastische Opvoeding (Arts & Crafts) in belgian schools: teaching kids important, artistic skills in 1 hour a week, which is perceived as relax-time without guidance, by the teacher that is the least motivated in the entire school.

With Exponential Age he is referring to the theory behind The Singularity (computer power is growing exponentially and will eventually outperform human brainpower).

Some issues he predicts:

  • Should you learn x when there is google.
  • Deepak thinks general practitioners job will be unnecessary in 5 years.
  • No single job for life.
  • Expect at least 2-3 job obsoleteness events
  • AI and Robots will do everything better
  • New tech will come and go faster and faster.

As a solution (in the field of education), he thinks that we should teach kids how to Learn - Unlearn - Relearn (Toffler). Read this.

21st century skills are the 4 C’s, Context, Container, Component and Class diagrams. No wait… Those are other 4 C’s. ;)

Deepak means Communications, Collaboration, Critical Thinking and Creativity.

We should also teach our kids Design Thinking.

And have them do peer-to-peer learning. Because learning from another kid increases relatedness, and teaching provides new and better insights.

The role of an actual teacher would then move more towards a coach and mentor instead of a know-it-all type of person.

He also said that schools are not going to be teaching this to your kids, so you should find alternatives. Such as TEDxYouth Flanders, or CoderDojo.


There was an interesting talk by Joao Gil, who made an art installation called BioComputer, that serves as a sort of assessment of future speculative technology.

It fit into the Speculative Everything… thing…

I do think it’s an easily underestimated step towards early feedback of novel ideas.

Things that Startups and VC investment have to deal with every day.

I also think it has the additional purpose of informing and slowly introducing new, groundbreaking, moral-changing technology to the general public.

Creating your future history: D-Day lessons for every day

Erin Meyer has been living in Belgium for half of her life now.

She set out to fulfill her dream of writing a book (instead of getting a Phd).

Through 3 questions out of her book D-Day lessons for every day, and accompanying exercises, she taught us about ourselves.

1. What is your current version of “impossible”.

Current, because after a while you’ll have reached what seemed impossible before. Let’s see how we get from Impossible to I’m possible.

Exercise: list what seems impossible for you at the moment.

2. What do you stand for?

Exercise: write down words that you think summarize your values, your idols, music, movies or series you love, concepts, experiences…

Then circle three of those that you will revisit in the next 3 weeks.

3. What makes you feel alive?

Honor the lives of the deceased by living your life

You contribute to the lives of others by doing what brings you to life

Exercise: Imagine that it’s now today + 3 years and you encounter the same people.

What will you tell them about what happened to you in the past 3 years. What did you achieve? What did you experience?

To me this workshop served as a mirror.

I reflected on the fact that I’m (still) not really doing anything with my life. Even in the last exercise I wrote I still won’t know what to do with my life, but I’ll have progressed in a natural way.

So it was an interesting self-reflection exercise.

Driver mapping - Sociocracy 3.0

Jef Cumps (@jcumps) from iLean, excellently facilitated a fun and insightful workshop on Driver Mapping.

Driver Mapping, I think, is a practice out of the Sociocracy 3.0 framework. It’s like Impact Mapping, but for organisational structure.

First we set out, with everybody in the room, to host a conference, and tried to figure out in groups what actors, or personas, are essential to a conference. And started to write down what their needs (sub-drivers) are.

Main driver and actors with their needs (sub-drivers) and their tasks

Then we changed perspective by taking away the actors and trying to categorize all of the drivers.

Then we changed perspective and tried to categorize

And we created so called circles, groups with people that are motivated enough to deal with a driver/category.

Overlapping tasks can be dealt with using the delegation circle pattern from Sociocracy 3.0.


Future of good and evil

I also went to The Future of Good and Evil by Dr. Stephen Cave.

He talked about what we can do when (not if) our values and morals change in the future.

To be able to answer that question, he gave us a thinking exercise: What can we be condemned for by our grandchildren?

He also questioned whether or not we can use data and machine learning (the tools of today), to answer the question of What will our future standards look like?.

As examples of current data and machine learning:

  • US Judges use AI to help decide on release on parole of offenders.
  • Surgeons trying to decide whether or not to cut off someones leg also gets fed info from AI.

There’s a pitfall in believing in AI provided solutions though. He retold Plato’s story of Socrates and Euthyphro where a son wanted to prosecute his father (who killed someone), because the Gods’ word is good.

Just like in that story, where the Gods provide morals, we can have our morals provided by AI, but it doesn’t mean that we should blindly pursue the AI’s suggestions.

Other practical stuff we can already start doing so as to not be condemned by our grandchildren:

  • Rights for future people. Decisions effect future people, so why don’t they have rights?
  • Animal rights. Comparable to cannibalism: eating equivalent things (things that are worth the same).
  • Opening up all borders. Comparable to sexism and racism. Don’t lock people up. Help them make better choices instead.

Every day there is more and more proof of intelligence in animals, yet we still keep eating, and basically torturing them in industrialized meat providing companies.

As a conclusion he turned his intro thinking exercise into a positive one: What might we be admired for?

As a user, I hate User Stories

Matteo Cavucci (@MatteoMced, Thoughtworks Berlin) had an interesting presentation too.

It was yet another reminder that user stories should be conversation starters, not requirements documents.

Do your Stories contain Acceptance Criteria, are created off of a Template (As a …, when I …, I want to …, so that …), or use User in their title?

Then it’s likely your stories are indeed requirement documents, and they are effectively hiding one of the most important values in Agile: Individuals and Interactions over processes and tools.

You could also easily make the case that Customer collaboration over contract negotiation is hidden as well.

He gave us some ideas on how to fix/improve:

Stop writing, start discussing.

Create shared understanding, instead of lists of requirements.

Don’t be a Template Zombie, tell a story.

If you’re unsure, you can use a placeholder in the text.

Avoid features, write down the user side of things. Basically, don’t write down the solution space, write down the problem space. I think this comes down to writing down the Why? instead of the What?.

Use actual people instead of the mythical user. Because they can provide context, limit scope creep, keep focus and serve motivations and impediments.

Then he also shared a more novel idea: Stories are not only small because these are easier to predict, but also because they’re actually small experiments (with hypotheses).

Your hypothesis must be small, right or wrong, and it should serve the purpose of learning, instead of amount of delivery.

To me this is a refreshing perspective at user stories.

A good way to move away from using Acceptance Criteria in your stories, is to come together (e.g. during kick-off or dev review) and to discuss what the BDD statements should be, together.


Virtual Reality - HTC Vive

I closed off the day, and DareFest, by trying out Steams HTC Vive.

Tanguy de Keyzer (@belgiumvr), your VR go-to guy in Belgium, loaded The Brookhaven Expirement, a zombie-shooter game. And I got to shoot at zombies. And whack them with my combat knife. And die a horrible death. Woot!

When you first put on the goggles (these did something!), you can easily notice the outline. Like if you use your hands as goggles, you can still see the outline of your hands, it’s just like that.

But after a while you stop noticing, because you’re continuously immersed in the 3D environment.

I think I spent about 8 minutes in the dark, gloomy, zombie infested (virtual) world. And I’m happy to say I didn’t shit my pants, or scream… too loud. :)

When the facilitator took off the goggles, my brain was struggling a little bit with reality.

It was weird knowing that a few seconds ago, there used to be a burning appartment behind me, and a busted car to the left, some oil cans and a camp fire on the ground etc. And now they’re suddenly gone.

It’s like, your brain accepts all these new orientation details, and now it has to override those orientation details with the current ones.

However, at the price of 900€, the fact that I’d still need to upgrade my desktop, and not the fact that there’s not that much content out yet, I’m going to wait for the next versions of VR hardware.

But it was a very fun experience! So thanks Tanguy!


On Thursday, in between presentations, I sat down across someone who happened to be Matteo Cavucci from ThoughtWorks (Berlin), before I knew who he was. And I got a chance to talk with him about the epic struggle with Legacy Software and applying DDD.

It’s stuff like this that make Darefest worthwhile for me. The interaction with (likeminded) new people has been great.

Most of the presentations themselves were too heavily sales oriented though.

It was all too clear that most speakers were there not to share their knowledge, but rather to sell their services or product. And that’s pretty sad.

As a conclusion, the first day I was disappointed, the second day less disappointed, and the third day I felt I learned a lot.

I had the feeling that a lot of the talks there valued promotion over knowledge sharing, and I really disliked that. I think it really deteriorates your learning experience.

DareFest organisation itself had a lot of issues too.

Because of the smoldering heat and lack of facilities (no airconditioning, not even ventilation), it was too hot to bear, most of the time.

Add to that a bunch of catering issues, complete lack of route signage, no sound isolation, no updated schedule information. e.g. I waited 10 minutes for a presentation that was cancelled; the drone racing was also cancelled (I think), and lack of information of the talks (I only had the title to know whether it would interest me or not).

I think it could’ve been done so much better. I also don’t understand how all these issues could happen, since this isn’t the first time that they organized this conference.

Everyone I talked to said that last years event was way better. They attributed the issues related to presentation content, to the topic diversity being too broad. I don’t know about that, I liked learning about shrooms, and then learning what other organizational structures are out there.

After re-reading all my notes and in writing this blog post, I did learn some valuable things in those 3 days. In the end I would’ve ideally just visited on the last day.

I think I made the mistake (?) of comparing DareFest to The Lead Developer conference. And they’re simply on a completely different level.

So… #WorthIt? I’m still unsure, but I am glad I once again had the opportunity to go to this conference.

The Lead Developer Conference - Recommendations

I blogged about Day 1 and Day 2 of The Lead Developer conference in London.

The videos have been released today, so here’s an easier way of watching all the presentations I recommended in those previous posts.

Nickolas Means - How to crash an airplane

Camille Fournier - Rebooting Culture

Dan North - How to make a sandwich

Michael Lopp - Leadership by the numbers

Ryan Alexander - Hacking verbal communication systems

Yasmina Banaszczuk - I know just the right person

Yan Cui - Tour of language landscape

Thomas Lobinger - Working backwards from the customer

Duretti Hirpa - How to get engineering team to eat their vegetables

Laura Czajkowski - How to deal with the cultural divide and internal advocacy within distributed teams

The Lead Developer Conference - Day 2

The Lead Developer - continued

The Lead Developer conference, or at least the one I went to, was held on the 23rd and 24th of June 2016, in the Queen Elizabeth II Centre in London, during the Brexit vote.

This is a post about all of the talks of Day 2, and I’m sorry that this one is considerably longer than Day 1. I don’t know what happened. :)

Day 2 

Michael Lopp - Leadership by the numbers 

So Michael Lopp, @rands, is a guy with a HUGE amount of knowledge. I’m very glad he was so generous to share with us.

He guided his talk somewhat weird and I didn’t fully understand what the stuff he was saying had to do with Leadership by the numbers, but the content was great.

He started off by testing the skills of the people that were captioning the entire conference by saying out loud Ok I gotta test this real quick… Supercalifragilisticexpialidocious. After the word appeared after 1-2 seconds, the crowd went wild. :)

These guys really did do an amazing job. I found myself checking to see what was said when some of the presenters went a bit fast for me to keep up with my notes. So thanks again guys!

Team Communications

I would be jealous to be in his team, because @Rands takes 30 minutes every week, no matter what, to have a 1 on 1 meeting with every member of his team. Just to check in, and have a feeling of what’s actually going on that week with his team. In contrast to the Performance Evaluation timeslots everyone dreads because it feels so forced.

He also has staff starting points, little 1 hour meetings to set the tone for the week. If you can’t easily fill an hour, something is wrong.

He then started talking about the long term costs of not saying the hard thing at the right time.

The obvious cost is that when you don’t say something, work isn’t getting done, team morale is taking a hit (and more importantly the toxicity spreads), and your sanity takes a hit as well.

The less obvious cost is that your credibility as a leader is taking a hit, and that there’s impact on folks you do not know. Their sanity is taking a hit. Michael has learned that everyone is replaceable.. I learned that when you work for Michael, Rands, or whatever his name is, and he shows you a slide of corn, you’re about to get fired.

Diversity, delegation and leading by example

Again, Diversity made an appearance on stage. This time in the form of the Asch Conformity Experiments, where the experiment shows that you can easily get influenced by other people. Again, be aware of the bias that you probably hire people like you and that wanting a diverse team is a no brainer. And also that as leaders, we should be a diversity allies.

This phrase fired a bunch of neurons in my brain You set tone and cadence… all the time. Just like kids who watch you do stuff and repeat your actions you do subconsciously. He gave an example of his own daughter using redirection to a new game she saw at games convention E3, when she saw him enter her room all ready to lecture her. He realized that she learned that from him.

As an easy change, you could simply start and finish meetings on time, and show you respect peoples time. This can set the tone for the whole company to do the same.

Watch his complete talk to find out what you might be horrifically bad at, and how you might direct yourself to a path of learning how to become better at it.

Also delegate when you’re in a stressy situations (e.g. the site is down). You know how to do it so let someone else do it and learn. Another great quote:

Delegation is a great way to grow a team.

Be unfailingly kind

He finished with a bit that hit home for me.

He talked about how he plays the videogame Destiny, an online shooter where you need to finish missions with a (random P_ick _U_p) _G_roup. Since there’s a huge variation of skilled people online, you’re lucky if everyone knows what to do and knows their role. And a lot of frustration and toxicity can originate from these situations.

But he plays this game with a friend who is Unfailingly Kind. It doesn’t matter how toxic other players are, or how little they know about the game. This friend has a lot of patience.

This was such a recognizable situation to me, and I strongly believe in being this Unfailingly Kind guy. But it’s really difficult to always be like this. I’ve got MAD respect for Michaels friend. And I’ll do my best to help people out in the friendliest way possible again.

Great keynote to start off Day 2 if you ask me. The tone was set again.

Slides / Notes

Ryan Alexander - Hacking verbal communication systems 

Ryan (@RNAlexander) Alexander took us on a deep dive into conversation.

I learned that a group conversation or brainstorming session is like a race. Where everyone that’s trying to talk next is at a starting line, holding their positions, waiting for the starter flare to go off (the one talking to stop talking).

But that there might be people in the conversation that follow the rules, waiting in their position. And that there are others that don’t, leaving the rest behind, before the starter flare was even fired.

This is sort of a semi-conscious, complex algorithm going on in every participants head. And exactly because it’s an algorithm, we can hack it.

I never thought about discussions or conversations like this, but it makes SO much sense.

Then I learned about the Occupy Together hand signals. Where you can announce your intent, without interrupting, to the participants in the conversation. Click the image for a clarifying explanation, or watch Ryans talk.

Seems like this would work WAY better than a simple “speech token”.

To facilitate everyone getting their chance to speak/communicate, the hand signals are more friendly to neurodiverse individuals. Moreover you can decide who’s next to talk on the basis of whether or not they have spoken, this is called Progressive Stack.

Great little talk with a boat load of information. Definitely worth your time!

Slides / Notes

Yan Cui - Tour of language landscape 

I’m sorry I didn’t write down all that much in my notes about the stuff that Yan Cui (@theburningmonk) taught us. But it’s because as I was sitting in the audience, it soon became apparent that this talk was gonna be a ridiculously interesting one and it would deserve my full attention.

Here’s the stuff I’m able to recollect though.

After a short introduction on the impact of language on the way we think, he showcased some really excellent examples of how features in certain programming languages can make your code more expressive. He took a bunch of features of F#, Clojure, Rust and Idris and explained how they could make your code less error prone and more expressive at the same time.

If you’re in to DDD’s Ubiquitous Language, there’s no doubt that you should watch this talk. Even if you have 0 experience with the languages Yan mentions.

He closes off his talk by encouraging everyone that didn’t know the programming languages he mentioned. He did this through debunking Malcolm Gladwell’s “10,000 hours to master something” rule, with Josh Kaufmans correction that says you can already be “good” at something after the first 20 hours.

Really, interesting talk, hitting all the stuff I love. Would highly recommend.

If you’re not into watching a presentation, read. his. blog! This guy is a library of himself!

Yan Cui, if you’re reading this: Thank you!

Slides / Notes

Crystal Huff - Dealing with Impostor syndrome 

Crystal (@crystalhmhuff) replaced another presenter at the last minute, and her presentation was very interesting nonetheless.

Impostor Syndrome is not a disease, unlike the term suggests, but rather a state in which you think you feel underqualified but when in reality you’re really not.

It can have real consequences such as being less effective as collaborators (because nobody wants to be seen making a mistake), getting fewer promotions (because an impostor feels unworthy), etc. In the end the negative impact comes down to being marginalized and being silenced.

It gets fed by sentiments like Fake it until you make it, when if successful, you actually will have been an imposter. Other things that feed into it are phrases like Women are bad at math. Even worse is when you give in to those stereotypes where you say for example Math is hard, let’s go shopping.

Other important, notable things that might trigger it are comparing your worst snapshot to someone elses best snapshot, and the Being Liked vs. Being Competetent dichotomy.

There are ways of combatting it though. And as usual it involves gaining more awareness. For example by asking your colleagues or friends about your strengths. Or by realizing your heroes struggle with this as well, and picturing the iceberg (illusion) of success.

Just the tip

Preventing Impostor Syndrome involves watching out for certain things that you say e.g. I’m not an expert, but…. If you repeat that phrase often enough, you’ll eventually believe it.

Compare yourself with yourself. Compare your past self (on your own personal scale of where you want to be in life), to your current and future self. Instead of comparing snapshots of your worst self to snapshots of somebody elses best self. This made a lot of sense, but it’s something you just need to hear more.

Crystal also inspired us to help each other prevent it by critiquing with kindness. Compliments are better when they’re personal. A good compliment is positive, not physical, specific, and honest. See Dan North’s “How to make a sandwich” presentation about feedback. When you notice someone else struggling with impostor syndrome, help them remind themselves of their happy thoughts and experiences.

I did reach out via the company Slack channel for someone to tell me 3 awesome things about me and here’s what I got.

You speak your mind, even to people you don’t know that well. You’re not scared (you don’t show it at least) to try out new things. When you’re enthusiastic about something, you shine your ray of enthusiasm onto other people. (you pull them along)

So thanks for helping me combat Impostor Syndrome!

Slides / Notes

Gil Zellner - How to not burn out your monitoring team 

We switched to a more ‘techie’ track with Gil Zellner (@heathenaspargus) giving tips on how not to burn out your monitoring (operations) team.

But before he did, he reminded us that the cost of hiring a new employee is 1.5 to 3 times their salary. So you might wanna retain those guys at ops by helping them as much as you can.


Do NOT watch this presentation or the slides if you haven’t seen Game of Thrones episode 9 of season 6 yet, there’s a massive spoiler in his slides. :)

Easy changes you can do to help (takes days to implement):

  • Mandatory half day off after night production issue.
  • Allocate weekly time to resolve or automate issues that kept us up at night.
  • Wider rotation (more people on call).
  • Follow the sun (if you have multiple timezones).

Medium changes you can do (things that might take months to implement)

  • ALERT ALL THE THINGS leads to alert fatigue.
  • So only alert on symptoms, not suspected “causes”
  • Only alert on actionable stuff
  • Only alert on business breaking stuff.
  • Direct alerts to relevant parties.
  • LOG ALL THE THINGS can tremendously help the team that gets woken out of their beds at night, but can lead to overwhelming stuff, especially if you also log success.
  • Connect detection scripts to correction scripts.
  • See Facebook Auto Remediation.

For the hard things (that might take years) he mentioned some AWS stuff I didn’t pick up on, but maybe you will so check out his slides (if you have seen Game of Thrones!).

Slides / Notes

Monika Piotrowicz - Lessons from growing a team 

Monika Piotrowicz (@monsika) talked about her experience of growing into a leader of dev leads.

A lead will have some combination of tech knowledge and skills, understanding of the business and product, and trust from their team. All so they can help develop their team.

And you can’t build a version of someone in only one day that has all those qualities. So what you want to do is encourage those traits in your entire team and see who picks ‘em up.

You can do this first of all by simply asking who’s up for becoming a lead (in the future), then talk about what it involves, and create opportunities for those candidates.

To help your colleagues and yourself grow, fill in the blanks

Most impactful thing I can do today is …

Right now I’m not great at …

In a few months I want to try …

Remember to Make Space for your candidates to grow. I trust you to do the right thing - here’s a list of things you should do is not how you make space. :)

This was all pretty great advice, but this one I felt like sharing with our current coach.

Every time you think you’re protecting your team by going to a meeting yourself, delegate to the team instead.

Slides / Notes

Thomas Lobinger - Working backwards from the customer 

Thomas Lobinger (@tlobinger) works at Amazon and talked about their (literally) backwards approach of aligning a team on values and creating a shared vision.

What I mean by backwards is that they’ll start with the end goal and work backwards from there.

So what they do is first they create a mock Press Release that shows, among regular stuff like title and summary, a quote of the customer and the team.

This helps them in not only creating a shared vision and understanding, but also a shared motivation. It’s what we usually try to do with a Mission statement of a project team. But I think it goes much further than that, because you’re imagining what impact your end result will have on the users or your clients.

After they’ve written this, they’ll create a FAQ document from the perspective of customers and stakeholders.

During the creation of the Press Release the team will have come up with a bunch of questions that you might be able to include in the FAQ as well. I think I can compare this to trying to figure out non-functional requirements during an RFP.

Then they’ll create Mockups of what their product/solution will look like. It should tell the story of how a user would use the product they’re going to build.

I’ve noticed that, much like Simon Brown’s (@simonbrown) C4 Diagrams, with this approach they’re effectively zooming in to their product, but from a less technical perspective. Every level of detail seems to put more focus on the users perspective. You know… the one we’re actually making this thing for.

Of course Thomas doesn’t just write these documents once and then be done with them. They iterate over them, so when they come across questions or more insight that should go in their Press Release, they put that stuff in there and update the rest accordingly.

So really what they’ve done is come up with a sort of Living Documentation that is able to continuously provide a Shared Understanding and Shared Values on a team.

If you’re looking for more information about this, it seems Werner Vogels (@werner) already wrote a blog post about this exact method back in 2006. Or simply watch his talk.

I do believe that it’ll work better for products you’re making yourself and innovations, rather than projects you do for clients, because there are no feedback loops from clients. But it’s easy to imagine asking the questions or verifying the assumptions that will come up when creating these documents.

Maybe it’s a great additional method to working on RFP’s or starting teams around a new project.

Slides / Notes

Penny Wyatt - Overhead, not downtrodden 

Atlassian’s Penny Wyatt (@pennozewyatt) gave us a bunch of tips when working in Quality Assurance.

  • Embrace you’re in an overhead team.
  • Broaden your view, work towards the company and customers goals.
  • Cost is not value.
  • Leaders are overhead too, so focus on where you can add value.

She told an anecdote where she spent 3 extra months testing stuff because the devs didn’t catch a lot of edge cases. At first she felt great because since it took her that long to thoroughly test the application and improve the quality of it. She felt like her role got validated because of this. Of course those 3 months were not perceived as extra value, but as extra cost.

There were better solutions to build in quality in to that team, like working more closely together with them. And focusing on installing quicker feedback loops.

They moved closer towards this goal by putting more accountability on the Quality Assurance team, so they wouldn’t just be accountable for quality, but also for development speed.

This caused them to work in close cooperation with the development team. And eventually get renamed from the Quality Assurance team to Quality Assistance team. Moreover because they were helping the dev teams become more accountable and more interested in quality.

Even though this caused her to do less Q&A, it produced more value in the end. She made the comparison to how management can also be considered overhead.

Instead of trying to get better quality by adding more developers, they can be able to get more value AND better quality from a smaller team, by letting the team improve their performance.

Slides / Notes

Melinda Seckington - How to succeed at hiring without really trying 

Melinda Seckington (@mseckington) made a compelling analogy of choosing between a closed box that had the label strawberries on it, or a transparent box where you could actually see the strawberries along with a label containing nutritional value etc. to choosing a company you want to work for.

Then she explained how at FutureLearn they’re making the transparent box, by focusing internally on helping colleagues write and speak, authentically.

The idea is that by doing this, you turn developers in evangelists for their teams (and by extension for your company).

The amount of support devs at FutureLearn get for this goal is staggering, and FutureLearn’s culture absolutely embodies this knowledge sharing and evangelism mindset.

To me personally this was eye opening. Because I’ll notice one of my colleagues has accomplished a great feat, and I’ll ask them to blog about it, but they never actually do. Usually they’ll come up with stuff like I’m not an expert, or I can’t write, I’m too nervous, I’m not a good speaker, Nothing I do is worth speaking about, …

From now on, I’m going to try and change my approach, by offering to help them write or prepare for a presentation. Try to help them take away their fears and blockers.

In any case, Melinda’s talk is a presentation you should show to your HR colleagues and/or your guild leads.

Slides / Notes

Laura Czajkowski - How to deal with the cultural divide and internal advocacy within distributed teams 

Laura Czajkowski (@czajkowski) works from home, for Couchbase. She was so kind to share her experience doing this and some pro-tips to help deal with the typical problems.

If you ever did some remoting yourself, you’ll recognize a lot of her descriptions. Most notably missing social talk and work discussions because of the absence of a watercooler (or coffee room), and lag (delay) issues with VOIP tools.

Watch her presentation for some pro tips on dealing with these situations.

If I ever work remotely again I’ll be sure to try out her tip on bringing your morning beverage to the friday mornings stand-up, and talk a bit about your weekend plans. This helps in getting to know your remote colleagues a bit more.

Slides / Notes

Camille Fournier - Rebooting Culture 

To close off this years The Lead Developer Conference, Camille Fournier (@skamille) talked about her own experience of bringing a Culture of Fear to the team she managed the first time she became a leader, noticing this and how she changed it around.

This was my first time experiencing Camille, and I don’t know if it’s because of her background as a developer, but all the things she pointed out, is very near to my heart. And she was talking about these things with such a passion… Validation feels great! So thanks Camille! :)


First she talked about Speed.

She reminded us that engineers like to ship, and be a part of something that matters.

Making sure your team can work as fast as they can is one of the most important things you can do. So remove resource constraints (e.g. code freezes), and be impatient with things that seem to take too long.


Then she explained how good Structure helps you get context quickly, and that Structure comes from failure. Failure in structure usually leads to getting rid of that structure, which isn’t always an appropriate response.

This reminded me of a story someone at our LeanCoffee shared about a team that had visible bottlenecks in their scrumboard, and decided to stop doing scrum.

Ambiguity is a bias factor, or how vagueness in job or role descriptions can be interpreted in a way that suits you. What you want instead is transparancy. She showed this really quick example of an excel sheet with DnD traits being used as measuring points. Take a look at this once her slides are up.

Here’s another nod to HR and people tasked with doing performance reviews. If you keep changing the interpretations of vague roles

Structure is not how to detail instructions on how to do it. If you find yourself doing this, ask yourself if you can’t automate that instead.


Vulnerability is the opposite of a culture of fear.

If I remember correctly I think she meant that when there’s room for feelings of vulnerability, i.e. there’s a safe environment to experiment and fail, both emotionally and technically, it empowers people.

Like how Kerth’s Prime Directive makes for great retrospectives.

Related to Vulnerability, you need to have Healthy Conflict.

Tina Turner wants violent conflict to resolve issues

Not because you’re Tina Turner in Mad Max Beyond Thunderdome, but because it draws out important data.

What I’ve noticed is when conflict is avoided all the time (as is common in Belgium), nothing can be learned, and it can lead to passive aggressive behavior.

Here’s another tip for leaders. Telling people You can’t criticize if you can’t come up with solutions yourself is a bad thing.

Instead, ask them to really articulate their criticism. It’s more effective to replace feelings of conflict with curiousity.

She also shared this fun definition of meetings:

A meeting consists of a group of people who have little to say - until after the meeting.


Because Camille felt like we hadn’t been given enough gems, she closed off her talk by telling us that Empathy is a learnable skill.

This is such an important statement actually. Much like how Responsibility is generally considered a trait, so is Empathy. But they’re both not.

How is it learnable though? Camille told us it’s as simple as asking about how somebody is doing, and really listen. Even if you don’t really care all that much, just do it. In time, you will care about Peter hurting his knee.

In hindsight, her talk was the culmination of what I expected from this conference, and at the same time it was a summary of what all the presenters before her had been saying.

What I’m trying to say is, watch her presentation now!

Slides / Notes

In conclusion 

Writing these blog posts have been great to recollect the abundance of shared knowledge and I’m glad I did, even though it took me quite some time. Hope you readers were also able get some use out of these posts.

I’m so glad Jan Sabbe recommended this conference to me last year. It really was an inspiring two days, full of new knowledge to share.

Thanks again to everyone involved! Hope to see you next year!

The Lead Developer Conference - Day 1

The Lead Developer what now?

The Lead Developer conference, or at least the one I went to, was held on the 23rd and 24th of June 2016, in the Queen Elizabeth II Centre in London, during the Brexit vote.

It’s a conference mainly about “that other part” of a job as programmer, namely working with people.

I can highly recommend this conference to anyone. It’s not just for developers; scrum masters, managers, and other roles can all learn from the abundance of information shared at this conference.

All the slides can be found on the conferences website, but I link to the specific slides (and my notes) in the short bits I write about the talks below.

Note: not all slides are online yet, but they’re getting in when the speakers have taken the time to share them

A word of thanks

Thank you to my faithful travel companions and colleagues Jan Sabbe and Bart De Neuter.

Thanks also go out to our employer, Cegeka, who paid for travel, accomodation and the entrance fee.

Thanks to the organizers, White October Events, who did an amazing job at making everyone feel at home and for being super friendly people in general.

And thanks to Meri Williams, with her witty announcements, for being the perfect host and an inspiring example to us all.

Scribblings of a madman

Based on my notes, I’m sharing the most important things I learned in every talk I watched. So, you can decide if it’s interesting or not.

I’m also turning this into 2 blog posts, because after writing Day 1 it already was a lot.

Day 1 

Patrick Kua - What I wish I knew as a first time tech lead 

Using his fantastic art in his slide-deck, Patrick Kua (@patkua) gave everybody some pointers on the path to a wise lead developer.

He mentioned some recognisable things such as: trust your team, delegate to it, provide guidance, don’t write code all the time, don’t make all the technical decisions.

But the coolest thing I learned was that there are certain skills of yourself (as a leader) that can be represented by archetypes or personas. Patrick identified the Coach, Shepherd, Shaman, and Champion.

The Coach

The Coach (e.g. in a soccer team) personifies the part of you that tries to keep the team together and motivated.

The Shepherd

The Shepherd is the part of you that guides individuals back to the team, or guides the team to a shared goal.

The Shaman

The Shaman is your story telling skill. I thought it was so cool that this is important enough to validate turning into a persona. I never thought of it that way but it sure is refreshing.

The Champion

And finally The Champion, is that part of you that can Lead by example your team to a higher level.

We all carry all of these personas with us, it’s certain situations that will call these out at times.

Patrick closed off by saying that our role as Lead gives us greater impact. And instead of becoming the 10x Dev, we can grow the individuals in our team so that the team becomes the 10x Dev.

This keynote really set the tone for the talks that we’d see over the course of the next 2 days.

Slides / Notes

Heidi Waterhouse - The 7 righteous fights 

The 7 righteous fights… you should be fighting.

Heidi’s (@wiredferret) talk was mainly about making sure your application adheres to Localization, Security, Extensibility, Documentation, Affordance, Acceptance and Accessibility. If you don’t take these into account, you’ll build up compound technical debt.

I learned that Affordance is about nudging your users so they use your application correctly.

About Security she had a lovely quote:

Internet is not a series of tubes connected to hackers wearing hoodies.

That got a good laugh. :)

About technical debt in general she said if it’s already in a release, you’ll get more resistance when trying fixing it. She made the fitting analogy by saying that trying to fix stuff in a codebase after its release is ​like trying to pound chocolate chips into an already baked cookie​.

Slides / Notes

Mike Gehard - Moving from Monolith to Microservices 

Mike (@mikegehard) went so fast through his presentation, that it’s gonna take me at least a second viewing to really understand all the things he was trying to say.

The way Mike approached moving from a Monolith to Microservices is by starting from a monolith and then move towards Microservices, instead of trying to guess which microservice to distill from your application and do trial and error from that position.

Why Monolith first? Because it’s safer to learn about your domain and it’ll cost less to change Bounded Contexts.

Basically what he was saying was Use the benefits that immersive design provides.

  1. Write API level tests
  2. Arrange/Organize your application so you can see your domain (and Bounded Contexts)
  3. Break out components
  4. Promote one of your components to a microservice (here you’ll also build the minimum required infrastructure and test it out)
  5. Continue promoting microservices

As you might notice from the lingo, Mike is a big fan of Eric Evans’ Domain Driven Design (he even made the same jokes that go along with it). He also didn’t fail to mention Simon Brown’s component structuring. This made me feel right at home. :)

Slides / Notes

Lorna Mitchell - Wonderful world of webhooks 

Lorna (@lornajane) gave a lightning talk about why WebHooks are cool.

I remember that Webhooks are less chatty, and that its content is usually large (coars-grained) because you want to push the information that’s useful to 80% of the use cases to stay as least chatty as possible.

Slides / Notes

Dan North - How to make a sandwich 

Dan (@tastapod) North, the man, the Legend, gave a really great talk about Feedback.

He first talked about Feedback in the context of Systems Theory, which he does a way better job at explaining than I ever will, so watch the video.

The most important thing I picked up about this part is that there are different motivations why one would offer feedback. And that when you notice you would be offering feedback to control the one you’re giving feedback to, you should just walk away.

In the next part we learned about how to deliver feedback using SBI, Situation Behavior Impact.

And different ways of structuring feedback, e.g. the infamous Sandwich model.

To receive feedback there is only one rule: Always say Thank You. Even if the feedback you got made you angry. Because it shows your appreciative of getting feedback. Try to map that feedback you got to SBI yourself (how was the other person thinking about giving you feedback).

Great talk to start off the lunch. :)

Slides / Notes

Duretti Hirpa - How to get engineering team to eat their vegetables 

To stay in the food analogies after a very nice lunch, Duretti’s (@Duretti) talk about how teams operate had some really great one liners.

My favorite ones being (Acceptance of) vulnerability leads to a learning culture, Coordination IS competitive advantage, Productivity is a measure of comfort.

She noticed what qualities a good team shows:

  • A good team wants you to win
  • Has a sense of togetherness
  • Has a place for vulnerability.
  • Is psychologically safe
  • Has empathy

Nice talk with a whole lot of truth bombs. Worth watching!

Slides / Notes

Katie Fenn - Writing Modular Stylesheets with CSS Modules 

Katie Fenn (@katie_fenn) took the stage and talked about how CSS Modularization is sensical because along with making components in JavaScript, you also want the same for your CSS.

CSS Modules is the way to achieve this fairly easily. I think it makes the most sense when you work with JSX components like you do when you use ReactJS.

Other than the various JS loaders, you can also use it with both Sass and Less.

Slides / Notes

Yasmina Banaszczuk - I know just the right person 

After that short technical talk, in came Yasmina (@lasersushi), ready to blow us all away with refreshing german directness and delicate, yet powerful tone of voice.

Her talk was all about how our (personal) networks can influence hiring and retention in the tech industry.

After laying out studies and papers about how we really hire “People like ourselves”, we delved deeper into the motivation behind it.

She gave a hilarious example of how the name Kevin has (had?) a bad connotation in Germany, which even lead to a word called Kevinismus, and the entire floor laughing out loud when she visibly felt embarassed about all the Kevin’s in the audience, and the continued, emboldened laughter after she exclaimed There’s actual research in that!.

At the end of her talk we got a nice summary:

Check your processes, your networks and yourself.

Are they varied, do they have same educational background, do they spend their nights gaming, or do they speak or dress the same way?

Then your network might be too homogeneous.

This might turn your networks into gatekeepers instead of welcoming, open gates.

A very refreshing and interesting talk, with a very smart and very fun to listen to speaker. Definitely watch her talk.

If you’re interested in more of her research, definitely check out her website. She’s currently working on a series of articles on The Habitus of Tech.

Slides / Notes

Joel Chippindale - Telling stories through your commits 

One of Joel Chippindale (@joelchippindale) was preaching to the choir (at least on my part) about how The key challenge as lead dev is managing complexity and how Naming, code design, refactoring and automated tests are all about communicating the intent of our software.

He then went on to say that VCS (like Git, Mercurial, SVN, …) is underused in this regard.

To have every line of code always documented, he presented us with the 3 principles he adheres to.

  1. Make atomic commits; What’s the smallest useful change u can make to ur codebase?

  2. Write good commit messages (on his website he links to Chris Beams’ How to write a good commit message)

  3. Revise your development history before sharing. With git rebase.

The biggest motivator to a team on using these principles is that all of them have the benefit of making commits simpler, and also easier to think about.

Absolutely loved this talk. It amazed me how much information he was able to cram in a relatively short talk.

Check out his website dedicated to this concept.

Slides / Notes

Sam Lambert - The argument for simplicity 

Sam Lambert (@isamlambert) taught us a bit about how they work at github.

They deploy with hubot in slack so they can easily backtrace what happened before and after in the conversation that is deploying to production. Neat!

If there’s one thing he wanted us to take along it was to get a therapist. People laughed awkwardly, but he was dead serious. It was great to see this taboo being taken down.

At the end, in stead of mentioning his own internet location he shared some people he wants us to look up, so here are the ones I managed to note down: @ihavenotea, @jessfraz, @eanakashima.

Slides / Notes

Nickolas Means - How to crash an airplane 

Jezus christ, how do I even begin summarizing this talk.

Nickolas (@nmeans, glorious beardy man, airplane afficionado, …) left the audience mesmerized and awe struck after channeling his inner Shaman, telling us a story about how a horrible plane crash could’ve turned out even worse if it weren’t for Cockpit Resource Management. And making the analogy to what makes up a good team.

If there’s one presentation you should watch of this conference, it’s this one.

A grasp out of some of his quotes:

Cooperation over Heroics

Everyone has a voice.

As leaders we need to avoid teams to develop dominant voices, especially our own. Use your authority to ensure every voice is heard.

Software is a team sport.

Slides / Notes

Day 2 

Continue reading Day 2!

Value Stream Mapping Retrospective


Use Lean principles’ Value Stream Mapping if you want to:

  • identify and optimize your process
  • boost team morale by showing you’re making something valuable
  • boost collaboration between analysts and developers
  • want a break from the drudgery that is Mad, Sad, Glad.

Check my lessons learned to make sure you don’t make the same mistakes.

What is Value Stream Mapping

Value Stream Mapping is a collaborative exercise originating from Lean Principles, that visualizes the process of delivering value to your customers. As a result of the visualisation you’ll be able to analyze the flow of materials and information, identify chokepoints and waste, etc.

Setting the Stage

About 2 to 3 minutes

Make sure you mention Norm Kerths Prime Directive, especially if this is your first retro, but also as a refresher.

Aside from that, pick one! The internet is a vast ocean of possibilities.

Since we have the tradition of bringing a snack when it’s your turn to facilitate the retrospective, I brought clementines. I told my team to first draw a face on this fruit, expressing how they felt at the time. Being silly is very much allowed.

Gathering Data

30 minutes

I then started off by explaining Value Stream Mapping and told them to divide into groups of 4, with each group having at least 1 analyst. I asked them to create a flow of a story or a bug, not both. All teams ended up using the perspective of a story in our process.

Every group had an ample amount of sticky notes, sharpies, and flipchart paper. I also gave them a pdf printout of the Value Stream Mapping explanation they could refer to when something wasn’t clear.

They were kept up to date on how much time they had every 10 minutes. At first I didn’t plan to spend this much time in this phase, but they all seemed really into mapping out our process and having fun that I decided to have them continue on for a little while longer.

Group 1 Group 2 Group 3 Group 4

Generating Insights

5 minutes

While the groups were still working on their Value Stream Map, I went by each one and told them they had 5 minutes to answer 3 questions that I also wrote on a flipchart:

  • What did you learn?
  • What still puzzles you?
  • Where is the biggest time-sink/waste?

Sharing results

20 minutes

After those 5 minutes were over, I had every team share their Value Stream Map and their findings to the other groups.

Group 1 Sharing their results Group 2 Sharing their results Group 3 Sharing their results Group 4 Sharing their results

There was some discussion as well, mostly on our process. Remarkable was that every team had a different style of Value Stream Map.

Our alotted retrospective time was up, so we didn’t get a chance to make any S.M.A.R.T. actions. We did agree to have a follow up meeting with a couple people that showed interest to tackle some bottlenecks.

Retro of the retro

I listed sticky notes with numbers 1 to 5 on them on the table closest to the exit of the room and laid out stacks of sticky notes and sharpies.

The idea was for everybody to put a sticky note in the column corresponding to their opinion. 1 meaning Crowd is booing, 5 meaning Crowd is cheering. If they had concrete suggestions or remarks, they could write them down on the post it as well.

I liked this, because it lowers the threshold to give feedback. People that wanted to give remarks did, and people that didn’t still hung up a sticky anyway.

Retro of the retro

I loved how engaged everybody was when creating the Value Stream Maps and I loved the interaction between developers and analysts. This also came out of the feedback I got.

Lessons Learned 

Something I should have done at the beginning of the Gathering Data phase is to emphasize that they shouldn’t go into too much detail when following the flow of a story. Because this caused groups to require more time to finish the entire flow of a story. Mentioning that they should not use the current kanban board as a reference would have helped a lot too I think. Mostly because this causes them to start off on a level of detail that is unnecessary for a Value Stream Map. This way I can shorten the Gathering Data phase and we’ll have some room for making S.M.A.R.T. actions.

Eventhough I think it’s a pretty powerful format, I also think it can only work well if your team is mature enough. So maybe keep in mind not to try this out on teams that are completely new to an Agile way of working. It might be better to take more time and do a proper Value Stream Mapping session.