Notes from the March ‘24 FroGS conf open space

Yesterday Elizabeth Zagroba, Huib Schoots, Sanne Visser and I ran another FroGS conf online open space. There were plenty of great sessions, below are some notes from the five sessions I participated in. Thank you to everyone who was there, I had a great time!

If you want to join one of our next FroGS conf events, head over to our site and subscribe to our newsletter.

From notes to shared documentation culture

  • Co-creation works for code. In what ways is co-creation for documentation different?
  • Why do we talk about “an audience” for documentation, instead of about “the contributors”?
  • The purpose of documentation flips from “what we build” to “what we built”.
  • Old research paper on documentation: only documentation with lasting usefulness is architecture and test cases. Everything else is just notes.
  • Documentation heuristic: Is it easier/faster to reverse engineer it instead?
  • Documentation is a tool, a means to an end. What does it help you do?
  • Schrödingers documentation: If there are docs, no one will read them. If there are no docs, everyone will complain.”1 - Marit van Dijk
  • Book tip: Writing Effective Use Cases by Alistair Cockburn

Outsourcing bespoke open source software

  • Split the payment into a monthly fee and a risk/incentive fund.
  • From an Agile perspective it makes sense to put your acceptance tester into the development team. However, acceptance is linked to milestone-based payment. So you’ll want something more for acceptance than your tester in the development team.
  • Give both parties power and incentive. For example: the client does not have to pay for sprint if quality is insufficient. If that happens twice, the contractor can leave the project.
  • You want the contractor involved in requirements gathering, but be careful it doesn’t turn into the contractor deciding your acceptance criteria.
  • The earlier you open source the code, the easier, but also the scarier.

Thoughtleadership vs delivery goals, balancing or combining the two

  • Common route: delivery focus first, then develop thoughtleadership.
  • Make sure you balance the two in a way that fits you.
  • They require a different type of network.
  • There’s a tipping point. When people start to realize you can do both, they will come to you for both.
  • Shadow someone who does what you want to do.
  • Book tip: An Everyone Culture by Robert Kegan & Lisa Lahey

No Vehicles in the Park

  • A vehicle is any object that’s used for transportation of goods, people, regardless of surface.
  • Shoes are not a vehicle. Wheelie shoes when walking are not a vehicle, when sliding they are.
  • The rule says, “No vehicles in the park”. - a game about language and rules
  • Levels of vehicularity apply.
  • What’s the reason behind the rule? What’s its purpose?
  • Is violating the rule allowed? Do you want it happen regardless of the rule?
  • Book tip: The Four Tendencies by Gretchen Rubin

Improving effectiveness of testing/testers across teams

  • Safety is crucial. What is valuable to do? How will people be evaluates?
  • What’s hard and/or slow?
  • There are plenty of easy wins.
  • As Woody Zuill says: Turn up the good.
  • Tools: impact mapping, A3 problem solving.
  • Get people to do things together, e.g. through a community of practice.

Some of the sessions I missed

There were also some interesting sessions that I missed, because I can only be in place at a time:

  • How to find employers that value quality (and you)?
  • Capture the Flag Together: Security Testing for Everyone
  • Making changes from the inside out vs. outside in
  • Building a practice app for all things software and testing (ensemble)