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.”¹ - 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)