My Highlights from #Play14 Festival

Last weekend we attended the #play14 Festival in Basel organized by Bernhard Sterchi. Thanks, Bernhard for organizing!
I don’t know if “festival” is the right term, but I like to call events “festivals”, where people are having fun, get together and do something together as a team. Actually it’s an unconference as described here You find all about the general details on that page.

An impression of an Energizer.
The Unconference starts.

My pre-festival assumptions

It was my first #play14 event and I was a bit skeptic about just playing games a whole weekend.

Playing the Giant Witch Troll game
  • How long does it take until I get bored by energizers?
  • What do I learn by “just playing” Lego for a whole weekend?
  • What “weirdos” spend their whole weekend just playing games?

TLDR: I was totally wrong 🙂

The Plan

It started Friday evening and we immediately jumped into playing games (mostly energizers and brain-twisters) as a whole group. It was fun, we talked what the game is about and how to use it in another context (workshop, meeting, large group gathering, …). Awesome!

Saturday and Sunday were also kicked off with full group games and from 9h-17h we did an unconference-open-space style game selection.

Sunday we closed off the event a little earlier so that everyone had enough time to head home

The Games

Here is a list of games I collected and could remember from my notes:


  • Magic Triangle
  • Giant Witch Troll
  • Running Through Hands
  • Squat in Pairs – Discomfort – What happens?


  • 1 Word Story Telling in Circle – Energizer, Associations
  • Samurai – Energizer
  • Count until 33 and clap for every 3 – Energizer
  • Predator, Protector and your Position – Complexity
  • „Hello Johnny“ – Brain Teaser, Warmup

OPEN SPACE Unconference

The unconference plan of Saturday
  • Transport Bomb
  • Smelly Situations Role Play
  • Game to learn about Technical Debt
  • Gordian Knot
  • Board Game Magic Maze
  • 50min to build a game
  • Theory U 


  • 2 Detectives (find the 2 rules in the “system”)


  • In pairs – Change 5 things 
  • Silent counting in Circle (only numbers)
    • 2 people say the same -> restart
  • The Human Machine
  • Flamingo Pinguins …

OPEN SPACE Unconference

The plan for Sunday
  • How to celebrate Failure
  • Decisions in a complex environment
  • Little Games for Complexity
  • Taboo
  • Draw Guess Draw and see what happens
  • How long to write a Name
  • Toast Improv Game
  • Models with Lego
  • Tune In (Body exercise)
  • Agile Animal Farm


  • Whole Group: stone paper scissors (with fans)
  • Silent Goodbye

My Highlights

lightbulb idea

I really enjoyed:

  • The sessions about Complexity – Thanks Bernhard and all others
  • The idea of “Experimental Games” where you leave instructions open (or unspecific) on purpose
  • Taboo variation for workshop recaps – Thanks Kris
  • Lots of great conversations! Sorry I don’t want to start to name anyone here
  • Lots of little and great games to play with

The Experimentation


I didn’t realize it and was not prepared for it, but the cool power of the event is the people and the notion of experimenting with your games, workshop formats or whatever you need a group of VERY OPEN MINDED AND FUN people for.
If I would have known that I would have taken my game collection with me. For example “Keep Talking and Nobody Explodes” game I have bought and never played.

I ran 3 experimental workshop games and we brainstormed ideas on how to improve these

#1 Smelly Situations

  • Roleplay a weird situation from your office
  • Change the behavior of 1 person in the play
  • Experiment with situations
  • Reacting to situations you find “smelly” / strange.
  • How do you react as a Leader?
Situation: Boss and employees

I got lots of great input on what things to avoid and what things to make sure of. Safety is important!

Here the learnings for next time:

“Freeze” as a concept in an organization.

#2 Game to learn about “Technical Debt”

  • A short Game from Kris – Krzysztof Liszewski
  • Some theory around Technical Debt
  • Lots of suggestions on how to improve the game:
    • The “Technical Debt metaphor” is not ideal for complex knowledge work -> How do you explain it then?
      Unhedged Call Option might be another term 🙂
    • Technical Decisions are taken by the Teams or by Management -> What is the impact?
    • How to deal with uncertainty?
    • Conscious VS unconscious decisions?
    • Reckless VS prudent decisions?
    • Strategies to deal with Technical Cruft?

#3 The Celebration of Failure – Change

What played a short game and brainstormed around the question:

How can we influence the behavior from
“I failed, head down, something bad happened”
“I learned, we learned, we help, let’s move on”?

Lots of inspiration. Thanks!

What Next?

I will play games to learn things 🙂
Inspire yourself here on the game list page.

Check out when the next event happens near you

The next event in Basel will be announced on the “Basel Games Meetup” page.
Sign up and have fun!

Have fun and trust the team 🙂

Architecture Workshop with Legacy Systems

This is an agenda I used recently in a 2-day workshop on a future architecture with lots of existing system and Code legacy („brownfield project“):

  1. What is the Business Vision?
  2. What is the current Architecture?
  3. What drive a future Architecture?
  4. How could an ideal system look like?
  5. How do we get there? (Buy vs Build)

We started with the business vision and the management priorities and the current architecture situation. From there we elaborated an ideal system with potential strategies to get there.

Send us an email if you want to learn more or hire us.

Business Vision

Business Vision and Management Priorities
  • From the business vision, derive influencers on the architecture
    • What makes us cringe?
    • What makes us no worry?
  • Collect Functional and Nonfunctional items

Current Architecture

Working on the Current Architecture
  • Identify
    • pain points
    • user activities
    • top 5 use cases that drive the architecture
  • Create model(s) of the architecture to share understanding
  • What is slowing us down?
  • How long are the feedback cycles of work in the teams?
  • How can we enable Continuous Delivery?

Future System

What is the ideal system? How does it look like?
Where do we predict changes to happen in the future?

  • Work in smaller groups and capture ideas
  • Capture different approaches and compare
  • Data flow, security, user interaction
  • Use Event Storming to find user interaction points

Gather and merge ideas into architecture model(s)

  • What is the ideal architecture?
  • Use C4 Context and Component Diagrams
  • How can we minimize blast radius of issues and incidents? –> How can we create autonomy in teams?
  • Collect Glossary with common terms for shared understanding

How to get there?

  • What next?
    • Collect baby steps to get there
    • Collect big bang to get there
    • Buy or Build? Sub systems
  • Brainstorm activities and trade offs
  • Create a backlog of work

Pain Points

There are lots of points we address in the training or by running the workshop with your real operational systems architecture, like:

  • How do we know “Enough modeling is enough”?
  • When should we take which decision?
  • When do we start to digitize the models? (Why should we?)
  • Which notation makes sense?
  • What is a great architecture?

Tools we ❤

Here some tools we use in this Architecture workshop

  • C4
  • Clean Architecture
  • Wardley Mapping
  • Impact Mapping
  • Domain Driven Design
  • Event Storming
  • User Story Mapping
  • Ports and Adapters or also known as Hexagonal Architecture (by Alistair Cockburn)
  • The Universal Architecture (Concept by JB Rainsberger)
  • Pen, Paper, Post-Its

What does an Architect do? (Yes, the role)

From Business Vision to Leading the way.

Send us an email if you want to learn more or hire us.

Peter Gfader on Twitter Send Peter a tweet

5 Ways How Enterprises Can Successfully Act Like a Startup – My recommendations

Debo Olaosebikan @dolaoseb describes 5 Core Principles in his blog post “Big Winners Start Small

  1. Understand what users desperately want
  2. Test your understanding with cheap experiments
  3. Measure what’s important
  4. Build as little as possible
  5. Move fast and iterate

And a Roadmap to Go from Big to Small

  1. Create Small Projects
  2. Form Small Teams
  3. Differentiate between Product Management and Project Management
  4. Leverage Existing Technologies and Tools
  5. Nurture Entrepreneurial Teams

My comments

I like the roadmap, and in my experience for this change to work, you need to change the organizational constraints around “Projects” which include funding of them.
For me, that means I would start with “0.a Remove Legacy Management Practices” and then “0.b Differentiate between Product Management and Project Management

At the end it would look like the following.


  1. Work with Management: What is hindering the value stream?
    1. What legacy management practice is hindering your employees?
    2. Where do we create value? Where are we just busy?
  2. Work with Management: How does money flow?
    1. What do we incentivize?
    2. Where is our focus and what do we measure?
      Internal metrics or external customer-centric metrics?
    3. What are Projects? What are Products?
  3. Work with 1 Team: How can we make it work in the small?
    1. Create 1 Small Team with external customer access
    2. Establish Trust in your organization
      I wrote a german article about: Why the management doesn’t trust the development teams.
  4. Work with multiple Teams: How can we scale this approach?
    1. What is the common goal and vision?
    2. What is the network of supporting people for the teams?
    3. Nurture Entrepreneurial Innovative Teams

And remember:

Kanban and Scrum don’t matter.
Your process doesn’t matter.

What matters is that you have a process to improve your process.

Sign up here to get notified of new articles.

If 95% of all Startups Fail, Why Should Enterprises Behave Like a Startup?

Great question! via Roman

I think “enterprise projects” should behave more like a startup!
By behaving like a startup I mean:

  • Reduce risk and uncertainties
  • Validate hypotheses and learn
  • Prototype and get user feedback early
  • Find paying customers: That means in an enterprise –> deliver usable features that people ❤ (love)

Most of the big projects do these things in some sort.


What they don’t do usually is:

  • Pivot: 
    “Hey this is not what the user wants, maybe we change something”

  • Kill it 
    “We invested 10 million in this, let’s add 1 more million then we are ready” (The sunk cost fallacy)

“95% of startups fail”
Ok…. In my experience in an enterprise context, people tend to ride the dead horse too long. 

Sign up here to get notified of new articles.

Original blog post was posted on on June 2016 here

Strategies to Ride a Dead Horse

If this website goes down again, I have a backup here.
All the below was copied from

Dakota tribal wisdom says that when you discover you’re riding a dead horse, the best strategy is to dismount.  However in business we often try other strategies with dead horses, including the following;

  • Buy a stronger whip.
  • Change riders.
  • Threaten the horse with termination.
  • Say things like, “This is the way we have always ridden this horse.”
  • Appoint a committee to study the horse.
  • Arrange to visit other sites to see how they ride dead horses.
  • Lower the standards so that dead horses can be included.
  • Appoint a tiger team to revive the dead horse.
  • Ride the dead horse “outside the box.”
  • Buy a commercial off-the-shelf dead horse.
  • Create a training session to increase our riding ability.
  • Reclassify the dead horse as “living-impaired.”
  • Compare the state of dead horses in today’s environment.
  • Change the autopsy report to declare that “This horse is not dead.”
  • Kill all the other horses, so this one will look the same.
  • Name the dead horse “Paradigm Shift” and keep riding it.
  • Ride the dead horse “smarter” not harder.
  • Hire outside contractors to ride the dead horse.
  • Harness several dead horses together for increased speed.
  • Do a time management study to see if the lighter riders would improve productivity.
  • Declare that “No horse is too dead to beat.”
  • Call the dead horse a “joint venture” and let others ride it.
  • Provide additional funding to increase the horse’s performance.
  • Do a cost analysis study to see if contractors can ride it cheaper.
  • Purchase an aftermarket product to make dead horses run faster.
  • Declare the horse is “better, faster, and cheaper” dead.
  • Form a quality circle to find uses for dead horses.
  • Declare that “This horse was procured with cost as an independent variable.”
  • Get the horse a Web site.
  • Promote the horse to a supervisory position.

Time for a question.  Did any of these seem vaguely familiar to you?  A few I suspect.  So, now that you have read about all the things that you shouldn’t do and already know, please go to the beginning of this website and check out all the things that you haven’t read about that you should do and don’t know!

The dead horse strategies were reproduced with the permission of Bill Dettmer.  From Appendix F, Strategic Navigation.  ASQ Press (2003).