Almost everyone has had a pivotal moment that, on reflection, you realise was the catalyst for you to change the course of your life.

After working in retail for over 15 years, I had one of these moments that lead me to persue a career as a developer, through the developHER program at MYOB.

I will be sharing my story of successes, failures and many MANY learnings which I hope can help or inspire you or someone you know on their tech journey.

We all started our agile journey with some recommended template practices years ago. Over many many retros some of the practices persevered, pivoted or perished. In this talk I would like to share a team's experiment on why and what happens when you hit the hard reset button.

Any journey is a combination of planning, expectation, experiences, conversations, and knowledge gained.  The metrics journey that this Enterprise Agile Coach and experienced Release Train Engineer have travelled has all of this and more!  And many travelers like to have a copy of their Travel Guide to hand to not only plan their experiences but to help them manage some of the intricacies of their journey.  Consider this talk your opportunity to dip into an expedition through the wilds of agile metrics – with a cheat sheet.

This presentation will cover:

• Where am I?  Context is king.  Knowing your starting point is key.  Baseline metrics.
• Who’s on the journey?  Knowing your audience, who else is on the journey with you and what are their expectations. Agile vs Waterfall PMO. Internal vs External metrics
• What could go wrong?  Being clear about the challenges for metrics at scale
• Metrics as your compass.  Using metrics to help identify changes in direction

We started our metrics journey with different goals in mind and have uncovered some surprising aspects in what works and in particular what doesnt!  In this presentation they weave their expectations, experience and knowledge to show how these perspectives can meet.

A diverse set of luminaries to discuss how to enhance agility in the enterprise. Covering all the big scale challenges that large organisations face, such as multiple business lines, disparate technology stacks, geographically dispersed teams, 10s to 100s of products, etc.

One principle in the Agile Manifesto talks about the importance of face-to-face conversation. SAFe takes this to the next level with PI Planning which is a routine face-to-face event where teams create their plans for the upcoming Program Increment (PI). PI planning is facilitated by the Release Train Engineer (RTE) and includes all members of the Agile Release Train (ART).

To the non-SAFe practitioner, when they hear about the whole PI planning day palaver, they look askance and shake their heads and think to themselves "what a waste of time".  Is PI Planning a waste of time?  As part of an organisation that have had to embrace a framework to enable them to scale, PI planning is considered the heartbeat of the Agile Release Train.  In this lightening talk, I will share my experience with planning in 10-12 week increments.  Will 5 minutes be sufficient to change your mind?

Please don't assume that Agile is only good for Software Development, Startups, DevOps, Change Management, Personal Productivity, Product Development, Marketing, Sales, Time Management, Organisational Change, Educating Children, Operations, Infrastructure, Design, Teamwork and Saving your Organisation just because they are the only things that happened to be on the list.

Applying Agile principles in everyday life is a great way to not only improve your quality of life, but to experiment with Agile approaches and find out what you've really internalised.

For coaches and leaders practicing Agile in Everyday Life presents a rich opportunity to not just talk the talk, but also walk the walk.

In this talk I'll give a couple of examples of how I've drawn on Agile approaches to help address personal challenges, plus discuss with the audience what areas folks are "doin' it for themselves".

This will be an interactive session, somewhere between a talk and a short workshop.

When we decide to move from big batch, plan driven long dated constructs of change, so projects and programs in the traditional sense, to more agile methods, we need to rethink a whole raft of stuff. Assume for a second, if you will, we are using the historical program and project construct to identify and deliver change. Initiatives are bundled into a sequential approach and governed through stages of largely documentation production accordingly. As long as you are on track to the stages, your documents are reviewed and signed off, you are Green.

Then we disrupt this. We want more agility on how we identify, plan, deploy and release change. We want to deliver outputs to our customers and ultimately value or outcomes earlier and more regularly, which is one of the significant advantages of an agile delivery model. So we get an ROI uplift. Projects can be self funded.

So lets start a new theory and trial it. EVERY project is red until your first release to a real customer. No more debate, hand wringing, angst or arguments. Recognise and accept that until you have delivered something that tests your theories, is validated and works, and your customers are using it, you have done nothing. Use the RED as it is meant to be - a call to action to pay attention, provide support , facilitate and break through barriers, provide resources and time. Help the team get to done.

My goal is for the attendees to use this session to actually crowd source and  develop a model that people can take back to their business and propose, from scratch using design thinking and agile techniques. 

This workshop is inspired by drama therapy.  This approach can provide the context for participants to tell their stories, set goals and solve problems, express feelings, or achieve catharsis. Bring in your challenges in adopting Lean, Agile or System thinking. We will stage the story and help you find the solution through interactive play.

I used to get told to be more flexible implementing Scrum. How can I be flexible when there are all these rules and principals to be followed. It seemed like the more flexible I was the more I watered it down till nothing left. Then I gained agile-enlightenment* when I was de-programmed from the cult of buzzwords and hard rules.

This is what I learnt…

* Disclaimer: There is no such thing as agile-enlightenment as you will soon see…

MVP is about learning, testing assumptions and deciding if its wise to continue working on the current product or if its better to drop it or pivot to something new.

I see teams working on year long projects but saying they are working on an MVP. I hear about projects which once the MVP is delivered the project stops. No matter how you define it MVP is not a destination!

As they say, nothing is more dangerous than using yesterday’s logic for today’s problems, yet we are still working in our organisations with mental models that were inspired by manufacturing. You can see artefacts of it even in the language we use: people are resources and they work in development factories. If we are surprised why our transformations are not progressing as fast as we hoped when Agile took the stage, then looking to these old mental models provides part of the answer.

In this talk I will explain from practical experience in my work, how the old models still influence us every day and how we can break away from them and learn new models. I will give positive and negative examples from real projects to show that it is normal to experience failures and how to course correct from the lessons such failures teach us.

I will also provide pragmatic steps that everyone can take in their own organisations that don’t rely on buying new tools or following specific methods. Charting your own course starts with understanding where the problem is and understanding where our mental models let us down is part of that journey.

The buzz word at the moment is Mob Programming. This is a fantastic way of solving problems collaboratively but it can have negative impacts on the team. During this talk I will explore what these impacts can be and how to deal with them when your team is deciding it wants to try Mob Programming. 

From the outside Spotify is a company who has solved the riddle of scaling agile, but the insiders perspective might surprise you, with our structure more closely resembling a collection of startups sharing a wifi connection.

Personal stories are a powerful way to deliver business messages in a way that is more engaging and inspiring. Learn why stories are so powerful and how you can find and share stories to communicate and influence more effectively.

An anti-pattern: “something that looks like a good idea, but which backfires badly when applied”.

My recent work implementing scaling frameworks showed me the inherent risk of using frameworks as an explicit means to affect change; any framework will always contain anti-pattern risks.

The infographics associated with frameworks (whether SAFe, LeSS or DaD, Nexus) are always drawn with the best of intent but how they are applied is where things can run contrary to agile principles.

Using real work examples and telling the story of a recent 18-month, 40-team experiment in scaling; Niall will highlight some of the "pot holes" to avoid when using frameworks.

Niall will also present his approach to using frameworks including when and how to "let go" of ceremonies/practices when they become redundant.

Lastly, a coaching approach will be presented to enable coaches to leverage the best of what frameworks offer without getting caught up in dogma.

NOTE: this is NOT a framework-bashing presentation but a hands-on report on the risks of mis-interpretation of any principles-based scaling framework.

Over the last 2 years Niall has coached teams of agile teams through the launch of two Agile Release Trains (SAFe). Niall helped leaders, managers and teams through the process of adopting SAFe.

Using his real experience as the basis for the presentation, Niall will make the case for moving past SAFe and going to the heart of scaled Agile using Large-Scale Scrum (LeSS).

Amazon are famous for their Leadership Principles and pride themselves on being peculiar because of them.

Customer Obsession is one of the principles that is not hard to grasp but easy to overlook.  It reads...  

       "Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers."

One of the ways this is done is specifically to construct a "Working Backwards" document before a project begins - its not hard and anyone can do it and it can be a great leveler for delivering real value for your customers.

Having done the inhouse training for this method and contributed to a few of these (and seen the benefits they bring) I want to briefly outline the approach

To make our products great, we can use the build-measure-learn cycle to drive continuous improvement with a lean startup approach. An approach to making our teams great is the plan-do-check-act cycle. Both "measure" and "check" imply the use of data to inform our decisions. To counter the common retrospective anti-patterns we see around actions that never get done, we can take these principles and ensure we are really adapting and not just inspecting. When running improvement experiments to improve the way the team works it is crucial to use some form of data to verify that the change has moved you toward your target condition. To do this effectively, we need to go beyond output focused measures and focus on metrics that tell us about the outcomes we are trying to reach. We can’t, and shouldn’t, measure everything, so I will explore what to measure, and discuss some common ways of capturing, visualising and using the data for team effectiveness. These aren’t metrics for managers and they aren’t metrics to compare teams.