Suppose someone from support drops by your team with a question. No one on the team can remember exactly how that feature from the last release works. The document you created to guide development is out of date. Jira tickets lack detail. The developers start digging into the source code for answers.

There has to be a better way. There is. Itʼs called Specification by Example.

Hear the story of how a sceptical Product Owner and an experienced Agile Developer used Specification by Example to radically increase shared understanding and team collaboration.

In the second part of the session, everyone is invited to use our toolkit to build a plan to introduce Specification by Example to your own team.

Leave empowered to educate your team and others on why and how to get started.

I get frustrated with code that is sprinkled with poorly named classes, methods, and variables.

Whenever I work on a team or coach a team, I put a lot of energy into choosing good names and sensitizing my teammates to the power of naming.

I've noticed that developers spend most of their days reading code rather than writing code. I suspect you've noticed too. Creating understandable code is a high leverage activity for any team. And naming is where I start.

The core of the session is an example that illustrates the process and power of choosing good names. The example comes from a recent project. There will be code.

I will connect the example to specific techniques and patterns for choosing good names and share resources that you can use right away.

My goal for this session is to sensitize you to the power of naming.