Every organisation has legacy systems, and people who know "where the bodies are buried" -- hidden aspects of dependency, communication, process flow and whatnot which every system relies on to function. These are the dirty secrets swept beneath the rug of "business as usual", and they represent risk and friction alike.

As Peter Drucker is famously quoted, "if you can't measure it, you can't manage it", and the first step towards measuring it is to be able to describe it. How can you do this with gigantic, complex, intertwined systems whose origins are buried in mystery and legend, whose very operation and continued existence is dependent, frequently, on specific people, high priests who may not want to share their arcane knowledge?

This session provides evidence-based techniques for uncovering this complexity, visualising it in a machine-friendly but fundamentally human-centric manner, and using the results to drive real organisational awareness that facilitates conversations and change.

I've been on a journey, and I've come to know that apathy and ambivalence are an awful place to be.

I want to talk about big life changes and the uncertainty that comes with them.

We will look at navigating this kind of journey in your own life. How curiosity and self-awareness can lead to meaningful change that will better equip you for new and exciting things in your life.

We will also discuss the importance of healthy company culture as the undercurrent that enables all of this.

Scrum is a great framework but there are many ways to do it poorly. The average IT worker is interrupted every 15 minutes, which equates to 2000+ interruptions for a Scrum team every sprint. Unthinkable on a production line, yet too often the norm in offices.

I conducted original research with Scrum teams in Australia last year as part of my Master of Management thesis (and achieved an A), to understand the causes, patterns and impacts of these interruptions on the team's effectiveness and their happiness. And, how mature teams control interruptions rather than let themselves be controlled by interruptions.

Attendees will play a short game to demonstrate how destructive the context switching from handling frequent interruptions is.

My talks are always highly practical and I provide 3 takeaway actions for teams to improve their 'flow' and reduce interruptions.

DevOps engineers fly from job to job doing the same things - the systems differ, but the problems (technical and otherwise) remain the same. Eventually, we ask questions not about implementation or technology, but meaning: what am I doing all of this for?

In this talk, we'll cover how we provided a converged solution (Docker cluster, monitoring, alerting, and security) from 0 to 70% of the company in three months. We'll cover how we did it - the approaches, the workflows, and the rules - but more importantly, the why: to provide an environment where the things that we produce change whole organizations and make people's lives a little better.

But most of all, how it made us a little bit kinder.

Software development has embraced techniques like TDD (Test Driven Development) to help reduce the cycle time between developing code and validating it works.

As application development practice evolved, we needed to respond to change faster while still maintaining our quality - the way we developed our solutions needed to change - and so did our tools.

Now that we have Infrastructure as Code (IaC) a whole new range of cycle time challenges have emerged. No longer are we building simple proof of concept systems using IaC, many of todays cloud deployments are multiple complex servers composed of tens or hundreds of servers.

In this session we take a look at the tools and practices available to Infrastructure developers to reduce the cycle time of change while maintaining a high level of quality and confidence.

Working on a software product team can be quite a terrifying experience for new employees, especially when you are a round peg in the square holes.

A year go, I landed in the biggest tech company in town as a non-technical person on a technical team. Looking back on a year full of adventures and scary challenges, I’m here to share with you:

• What to expect in the world of code, API, kanban, MVP and DevOps
• The candid (sometimes, painful) lessons on how individuals can prepare for, survive and thrive in this kind of environment

There’s a correlation between how happy people are and their productivity. When we are joyful, we are better workers. We have more excitement. Our creativity is stronger, and we're better team players.With buzz words around agile transformation such as New Ways Of Working, Future Ways Of Working, Being Agile rather than Doing Agile, do you feel agility makes us happy at work place?

As leader you can and will have an influence on how happy those you lead feel. This doesn't mean you should be constantly laughing or joking, rather constantly look for ways to make your team happier.In this session we will explore what are the factors that lead to happiness, discuss why they're important and how agility will improve happiness at work, In Pursuit of Happiness – Our Journey In The World Of Agility.

“Being human totally sucks most of the time. Videogames are the only thing that make life bearable.” ― Ernest Cline, Ready Player One

While this quote is probably an exaggeration, it holds true for all of us at some point or another. Indeed there is something about videogames and gaming that just draws people in and keeps them enticed and addicted.

It is no surprise that concepts of gamification in many industries continue to proliferate. But what really is gamification? Where did it all begin? Is it just a buzzword or is there real scientific proof behind it? And perhaps most importantly, how can you leverage it in improving your teams?