In workshops I’ve run over the last year, I’ve learned that agile, as a word, can mean different things to project and change people, at times also confusing them.

Defining agile as a capability demystifies the word and helps us understand what it actually means for organisations, teams and individuals. Agility, or agile, is not a methodology; it’s a mindset, along with set of behaviours and practices.

To be agile is a mindset and a skill set.

For an organisation to become agile, it needs people who are agile in their thinking, their actions and in their practices.  

It’s time to make sense of what agile/Agile really means, and identify what change leaders and practitioners can do to create and support an agile environment. This talk will provide a snapshot of what this means.

Scaling is an anti-pattern. Big meetings, long loops, slow cadence, tight coupling, and deep hierarchies represent bottlenecks no matter how Agile your individual teams may be. But de-scaling refactors an organisation into self-directing streams of self-organizing teams working together like pods of dolphins.

How do human organizations de-scale? How can we balance autonomy of teams against alignment to business realities? This session presents principles, metrics and practice patterns for de-scaling based on a long running historical precedent, the Iroquois Confederacy, which sustained a de-scaled society of hundreds of thousands for over five centuries. And the Spotify tribal model. And Steve Jobs' NeXT/Apple culture.

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?

There is much discussion about the changing roles of Development and Operations staff when organisations undergo agile/digital/devops transformations. But what about the changing role of the Team Leader?

In pre-agile environments, as a Team Lead, your role is one of structure and co-ordination, it is through you that work routes. You know the skills and capacity of your team and are regularly making decisions about what can and can’t be done.

But as your team starts to work in agile teams, the need for you to keep them busy is reduced, as this is now a responsibility of the product owner and agile team itself.

You might find yourself asking “Do we need Team Lead’s in an agile/devops culture?”, and if so “What value can I provide?

This sessions looks at the opportunities existing Team Leaders have to support and drive digital transformation through the discussion of focus' they can bring to the team.

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.

Docker is an awesome container platform. As part of this talk , I would like to show and discuss , how it can help solve some of the common and annoying issues faced while testing . Namely :

• "It worked on my machine" problem
• Testing different configurations, with the same codebase
• Efficiently testing on your / dev's machine.
• Setting up the Continuous Integration Environment
• Scaling  / Parallelising Test Runs ( via Selenium Grid  & Docker Compose ) 

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…

In this talk we will share our insights from a year implementing Agile on a programme that already described itself as Agile.  Laugh as we recount our 23 team SAFe PI planning event, cry when you feel the pain of the over-worked build teams.  Puke when you learn of the atrocious Jira hygiene.

Bringing ‘genuine’ Agile to a large organisation is not easy.  There are many challenges to face, mindsets to change, battles to be fought and walls to be built.  However given time, it is often the small moments that generate the largest changes.  We hope to share those key moments with you.

We will cover insights from the Agile Coach, Release Train Engineer and a Domain Iteration Manager.  There will be a focus on Agile and Lean principles and how they were applied in key moments that changed the direction of the programme.  We hope these insights and experiences will help others who face similar challenges in bringing Agile to large traditional organisations.

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!

In this interactive session, Rob and Many from REA Group will go through an exercise designed to explore the agile testing mindset.  Together with the rest of the room we will build up a mindmap of a test plan for a simple application.  

Testing is an often mis-understood, under-estimated role.  We hope to challenge people into thinking outside the box and give people a better understanding of what a "QA" role brings to a high performing agile team.

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.

This session is a case study of how to apply Scrum and Systems thinking to a small development and support group working on multiple products at the same time. Scrum explains how to organise a single team working on a single product. Scaling frameworks such as Safe, LeSS, Nexus & DAD provide ways for multiple teams to work on a single product, but what do you do when you have multiple products and one siloed team?

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.

What's in a story? Perhaps more applicable to agilists today, what's in a user story?

Let's get real about user stories and what they are trying to achieve. Perhaps the user story is not the story format we should be using!

Let's examine the user story format that we all know and love today. We will dive a little deeper into how a story and personas can create synergy. We will discuss how a user story can be presented on a ticket and how stories can be supplemented with information like acceptance criteria.

Of course something so widely used will have anti-patterns. Let's look at a few and have a few laughs as well.

Let's go even further and talk about user story alternatives, I will propose two. But wait! Are there even other user story alternatives? I will introduce two more.

Finally, let's sum up the purpose of the user story and conclude with the central idea that's really important - your story can be anything you want it to be!