Gojko an gives his keynote talk at , the annual conference for passionate product owners, architects, developers and testers who want to learn agile techniques to capture, deliver and test business requirements for the systems they engineer.

Park Bench Panel Discussion – The concept

A Park Bench Panel discussion has in common with a normal panel discussion that it provides a good way for experts to spend some time answering direct questions from the audience. The audience gets to know the experts in a way that is only possible in person and the expert gets a little more exposure to the questions among the audience.

A Park Bench Panel discussion provides something more.

During a Park Bench Panel Discussion, everyone in the audience can join the panel.

Four chairs are provided for each Park Bench Panel Discussion. At the start of the discussion, three chairs are taken by the three expert speakers of the last few hours. One chair is left open. The Park Bench Panel Discussion Leader will introduce some basic rules for the session. The first rule is that anyone in the audience can join the panel, taking the empty chair available. As soon as the empty chair is taken by someone in the audience, one of the current complement of panelists will have to vacate their chair so that there is always exactly one empty chair.

You can ask questions, whilst remaining seated in the audience, but anyone who wishes to express an opinion, will have to stand up, join the panel, by taking the empty chair. The Park Bench Panel Discussion Leader will ensure people adopt the method and that no one on the panel overstays their due time. Anyone is welcome to rejoin the panel should they find renewed interest in the conversation.

This is an interactive session, with the room directing what topics we discuss. Some areas we could cover include:

• Psychology of the Tester
• Interactions with peers
• Value brought to the business
• Tools
• Skills
• What makes Testers tick
• How Testers use their skills to help deliver
• Implicit knowledge of the Tester.

Hear how we used ATDD for building a ubiquitous language across the entire team, promoting faster feedback, and cultivating a culture where product owners were deeply invested in the quality of both every deliverable and the system as a whole

There are many patterns on the internet about how to implement feature files. There are even many blog posts that teach us how to improve the style of our scenarios by raising the level of abstraction. Even when following those practices, we often end up with unmaintainable code, brittle tests and frustration. We are going to explore another step towards a state where the tool doesn't interfere with capturing the conversations by constraining the language we use. We'll learn about a pattern that could enable looser coupling between steps, cleaner step definition code, happiness and many more.

Diving through a brief litany of woe around his experiences in unit testing, Russ will then share the tools, techniques and hard-earned lessons he applies to write, communicate and organise his unit tests to make them as useful as possible to the future of the application.

Recently I’ve been seeing lots of things that don’t happen in real life. A Managing Director at Bank of America abandoning decades of organizational “best practices” and recreating his organization by letting people organize their own teams, and, if that weren’t unusual enough, the teams choose their own coach. This is, of course, impossible.

A group of former managers reinventing their role as servants rather than masters. This too, is impossible.

Other managers who had been working at the bank for over twenty years abandoning their lofty titles and moving out of their corner offices to join software delivery teams. This clearly is impossible.

The final straw was seeing a Java developer happily learning COBOL from a mainframe programmer. This, at the very least, is rather improbable. Come and hear what else has been happening before breakfast. It's all mad as a hatter.

This is a talk on how to transform an organization from a culture of command and control, to one where empowerment and learning rules.