How can an Agile Coach figure out when an Agile “Transformation” is going wrong? Are there signs that they might see, heed, and take action upon? Of course, there are!

Hindsight is 20/20, but in the moment, these warning signs can be hard to see. Let’s explore some of the more common, and frightening, warning signs that your Agile “Transformation” might be exhibiting. We will discuss transformation provider types, frameworks, keywords, and other anti-patterns that might be signs that THE END IS NIGH.

This session will review common themes and help familiarize you with the warning signs. Armed with this new knowledge, you will be able to plan as appropriate, to help navigate your organization through potential impending doom.

Ever wondered what on earth is going in your company? Your team? The system of work? Are people acting crae-crae? Is there conflict? Are there pockets of super awesomeness & pockets of unhappiness? Are people pulling in different directions?

In this talk, I will run through my systems thinking approach and experiences to unpacking and diagnosing a company, it’s context, it’s practices and it’s people.

If nothing else, this talk may help you with making the invisible more visible and may lead you to be even more situationally aware of the context you have found yourself in!

This talk is a case study of our architectural evolution over the last 2 years.

Our start-up had licensed a customised warehouse management system in order to demonstrate our innovative new business model. The WMS had a traditional 3-tier architecture based on Java and SQL server, and was lightning fast with most of the business logic encapuslated in stored procedures.

Out our start-up we needed to be able to "test and learn" - ie rapidly develop and deploy new features and test them in the market with our customers. Based on the feedback we would identify tweaks to the business model, and fine-tune the functionality that our customers wanted.

We had a launch date 5 months in future, a need to scale rapidly, growing the team from 2 devs to 20 within 8 weeks. And we needed to be able to work in parallel on multiple features. Whilst ensuring that the application was secure, performant, and reliable.

The answer, according to a bunch of experts, was to adopt microservices.

Three years later, we have a suite of secure, scalable, and resilient applications running in AWS. We deploy to Production multiple times a day, and our MTTR is less than 30 minutes.

And we have Services. Some of them are "micro".

But reflecting on what we learned in that period, there are a lot of things that we wished we had done differently.

In this talk I'll walk you through the evolution of our architecture, explain some of the choices, and highlight what we learned, and discuss what we would do differently if faced with the same decisions today.

This case study talks about the last 9 months of our start-up where we went from “no team, and limited functionality” – to launching a successful and thriving business backed by completely custom trading platform and fulfilment engine.

I wrote this blog a short while ago: https://medium.com/@justin.holland/cultivating-quiet-38cec9466feb

I feel like there are other continuous improvement addicts, or perennial impostor syndrome sufferers that feel the compulsive need to be more than they are, and do more in order to reach that unattainable perfect state of being...

And I know that a bunch of us find ourselves in a state of constant information processing & overload... thanks to the infinite information we are exposed to every day.

I have also come to believe this can be super unhealthy, and that there is something fundamental that we are losing, thanks to our perpetual busyness.

Some come and have a little chat, and reflect, about the role of not doing... and instead... being... (quietly)

The easy case for coaching looks something like this: a prospective coachee wants to change, can articulate their goals, and is matched up with a suitably experienced and competent coach, the two are a good fit, and they quickly get down to the challenging yet rewarding business of growth and change.

But what if a person (or team) doesn't want to change and would rather not be coached? And despite this an external power deems that change is needed and that coaching will bring this change about. What's a coach to do? What about the coachee(s)? What about the role of the client who's engaged the coach?

This situation is not uncommon, and bears more that a passing resemblance to what often goes on in addiction treatment. A person with a drug addiction (and often other problems) doesn't necessarily welcome therapeutic intervention at the outset. But an external authority has ordered it.

In this session we will explore the parallels between the two modalities of addiction therapy and coaching, including the applicability of the Transtheoretical Model of Change and the related technique of Motivational Interviewing.

These approaches offer insights into how to flex and adapt your coaching approach in the face of some of the most common human impediments to change.

Agile was coined in 2001, building on techniques and methods from the prior 10 or more years. We know that (smaller) software projects are more successful with agile delivery methods than with staged approaches like the SDLC. So why is it that 18 years after a better was was identified that managers struggle to adopt agile in a meaningful way.

This is a facilitated discussion - there are as many answers as there are people! So with the late afternoon timeslot - let's get together and have an interactive chat - with the intent that we all leave with some useful ideas, tools and techniques that we can apply when we get back to the office ...

When a group of stakeholders and team members come together to plan a new product or feature, they often focus on identifying stories that deliver end user value through solving a business problem, delighting the customer or disrupting a competitor. While these are critical stories, they are not the whole picture. Every product has non-functional or cross-functional stories which must be played.

Security stories are an important part of these but are often not considered at all. When they are considered, they are often an afterthought or are assumed to be part of the project infrastructure. Trying to bolt on security as an afterthought in this way is a mistake that can lead to disaster at one extreme, and compromises to reduce product usability or don't support good end-user security practices at the other.

The challenge, of course, is that from the stakeholder perspective, security is not seen as a priority. This workshop is for software delivery teams who want to learn how to change this perspective and work with their stakeholders to help them to understand more about the importance of security. The goal is to help technical and non-technical stakeholders understand security and why it should be given priority and built into their product from the ground up. We show participants how to facilitate a structured meeting or workshop with their stakeholders where they use a simplified threat modelling technique to identify risks. The outcome is the identification of user stories (or evil user stories) which when played will mitigate identified risks.

API development is fun! Everyone is doing it, from large organisations wanting to provide developer access to their systems, to small websites wanting to push web application business logic to the browser.

Password security is boring. It's also harder than you'd think. The number of reported system breaches is on the increase, with big names being hit by hackers.

And when it comes to a service-oriented architecture, you have to secure multiple services. That's just tedious.

There are a number of solutions, but few that let you pretty much forget about security and access control.

In this talk and demo, Ben will show how using a third-party identity management system will allow you to ramp up your prototypes and MVPs with more ease, and to concentrate on the core purpose of the APIs, rather than the layers of security that are a must in today's digital world.

This is a practical workshop where the participants will work in two sprints to build a city using the material given to them.

The intention of this workshop is for people to understand all the ceremonies better and it also helps teams understand that collaboration and working together as a team is the best way to achieve the results.

This is going to be a very interactive workshop while teams get to learn Agile while having fun.

At MYOB we've been improving our graduate programme for software developers. Today I would like to share some of the insights we've gained over the last few years around how to do this better.

In this talk Ruma and Jay will share seven habits of highly effective teams, based on their work at Envato. They'll also share some tips to help build the habits.

Story (or, more accurately, capability) slicing is such a core and necessary practice for creating agility at team, portfolio and even organisational level. Yet it is not explicitly included in any of the popular methods and frameworks teams use such as XP, Scrum and Kanban.

Slicing heuristics are collaborative, contextual, evolving techniques for creating focus on value-generating activities, leading to delivering value sooner and with more predictability. They incorporate all of the 4 core agile values from the manifesto, and many of the 12 principles, particularly:

• continuous improvement (inspect and adapt),
• maximising the amount of work not done (simplicity and focus)
• face-to-face conversations
• continuous delivery of value

Best results are obtained if heuristics are applied for all types of work, by all of the folks collaboratively across the value chain, but they can be used as safe-to-fail experiments by individuals and groups wherever they sit in the product delivery pipeline.

From a practical perspective, they involve:

• slicing deliverables at all levels, not only "story"
• flow metrics (cycle times and variation)
• specific inspect and adapt / continuous improvement activities to improve speed-to-market and predictability
• big visible boards (ideally)

Come and learn about this powerful, practical approach to improving agility in your team or organisation from wherever you sit right now.

Hearing a lot about Objectives & Key Results (OKRs), but still a little unclear what they're about? Maybe you're hearing all the chatter and it's tweaking your interest! Well, join me for a farside chat and all will be revealed.

In this session we'll get under the hood of OKRs to understand the history, the core concepts and cut our teeth in a manner which allows us to take them back to our teams for further exploration.

At minimum, you'll walk out of the session with some clear goals for the coming quarter!

Do we know our stuff?
OKR Quickstart coaches and consults businesses on how to create strategic clarity, achieve audacious goals and build high performing teams. We've helped hundreds of people and businesses introduce OKR so that everyone finds crazy value out of them (not just the exec team). We've made every mistake in the book and this session summarises some of our biggest learnings!

What could it be like to work through a real-life security incident at your company? As awareness about security in our industry improves, we hear much about how to keep our applications secure, but rarely do we consider what happens with your employees when something goes wrong. Allow me to share my story about the emotional highs and lows of working through a security incident, as we look past its technical surface and into the human experience behind it instead.

Prepare for a contentious and deeply personal story.

I was an Enterprise Agile Coach. I am now a Consultant. But can I be both?

Discover why I made the leap to "the other side", what I have learnt in the process and why, if we don't do something soon, Agile in Australia risks imploding.

Product Road Mapping can be a challenge for those that are new to this and also for those that are experienced. Conventional product road mapping models have several limitations. We will explore how various Agile Product Road Mapping approaches and models can provide relevant information and direction to different stakeholder groups that are responsible for product development.

The current Millennial narrative is getting pretty old and whilst some are still complaining that Millennials are lazy, selfish and entitled most people have started to realise they are shaping the world around us. It’s time to reframe the dialogue and meet the new Millennial and based on a recent study Millennials are not who we think they are. The new Millennial characteristics according to research include Disruptors, Changemakers, Demanding, Ethically and Socially Minded, Progressive thinkers & Entrepreneurial just to name a few. Furthermore, there are plenty of Millennial Rainmakers shining a light on how they are disrupting industries and changing the business world as we know it. Think Ruslan Kogan, 36-year-old Founder of Kogan.com, Nicholas Molner 28-year-old Founder of Afterpay & Kayla Instines 28-year-old Fitness Mogul who is reportedly worth a cool $486M just to name just a few Aussies. It’s time to move over and get out of the way, the new wave of Millennial Entrepreneurs has arrived.

In this session we will take an introduction look to Continuous Integration and Continuous Delivery workflow.

This session is an introduction session to CI/CD and is best for people new to the CI/CD concepts, or looking to brush up on benefits of using these approaches.

User adoption is one of the most challenging things about projects. When they are consumer facing applications, you can measure your success through the number of click throughs, time spent by users reading pages or product purchases, money they spend. Consumers want to use your product because it fulfils a need or a want. Conversely, when a product or service is required out of obligation, regulation or to maintain a standard, and it doesn’t necessarily fit a need or a problem they’re trying to solve, then consumers don’t want to use the goods or services.

Welcome to the world of application security. Application security is sexy in theory, hacking at systems, breaking in, being a rebel without a cause, but what happens when you try and roll application security tooling out to hundreds of developers where many of them have less than no interest in embedding another tool into their software delivery lifecycle? How do you keep it sexy, interesting, engaging and make them want to use it?

This is the story of how we rolled out appsec tooling to developers, our wins, our failures, and the rollercoaster journey we went through. The aim is to provide some insight into how different behaviours influence user adoption and hopefully some takeaways you can use when you're involved in such projects, either as part of a delivery team or conversely as an end user