We all have read the definition of the Scrum master role in the Scrum guide. However different organisations implement the role differently. Few companies have a "pure" Scrum master position. Others implement it as a "hatted" or "mixed" role, where the responsibilities are added to people who already have other duties and creating position titled as "Agile BA/SM".

While there is no right or wrong answer, we will look at a few different definitions, also looking at a few job advertisements - and then have a group activity discussing what the participants about how think the Scrum master could serve more effectively their organsation in their particular context.

Maybe in their context Scrum masters both coach agile values to their team(s) and are also responsible for delivery. Maybe they think that the SM should be both a BA and a SM - what would be the trade-offs then? Can a Scrum Master help the organisation with capability improvement (beyond their assigned team)? While there is no silver bullet to solve these issues, we will think together how we can answer these questions and what are the risks we should be aware of. 

Most practitioners and teams are familiar with sprint planning as an activity for their delivery for a certain timeframe.
When it comes to multiple teams and large organisations, there is a lot of practices and different frameworks to plan delivery. Lots of organisations are familiar with Big Room and PI planning and use it for quarterly planning.
In Australia, many large organisations have tried different frameworks and have also created their own ways of working (often termed as "new ways of working", "better ways of working" etc). 

There is a challenge though, specifically when planning larger initiatives with involvement of different teams from the inside and sometimes from the outside of the organisation. These teams can have different commitments, might use different frameworks and may operate in different release cadence. How much can we and should we standardise processes and how much should teams follow their own ways of working?
There is no easy answer to this. In this interactive session, Rajesh and Gabor will work with you and help you understand what is involved in delivery planning for large organisations, including topics like shared vocabulary (e.g. taxonomy, definition of done), planning activities, tools, team activities, reporting, etc.

When I have been recruited as one of the many Agile Coaches to one of the largest transformations programs in Australia, initially I had very "romantic" ideas how to help teams and groups/tribes to become more agile. I've been brainstorming with other coaches on how we can help the leadership to provide clear vision for the teams, how we can empower teams and work across all levels in the organisation. 

However, helping a huge program with over 1,000 people, located across countries and different timezones is not described in the Scrum guide nor in the manifesto. Can we be true to the basic values and principles, when senior stakeholders and executives expect up-to-date status reports? And how can we influence the culture, where a lot of the Scrum masters are ex project managers with minimal experience with Scrum? 

The presentations shares the journey of an Agile coach in this program, including ways of working in the program (not as "Agile" as you might expect) and the eternal question of how much command and control do we need?

Agile transformations are very popular in big corporates, however there is often a disconnect between the teams, the middle management, the "business" and the customer. Despite investing heavily in Agile frameworks (like Scrum) practices (stand-ups), tools and processes; transformations fail to deliver better outcome for the customers.

In my presentation I am looking at red flags when companies "go agile". However, it's not just an angry rant about all the things that are going wrong. I also have a look at how we can make our organisation a better place with setting the right goals, measuring the right things and nurturing the people.

There is no "one right way" to coach. Some coaches primarily focus on people and behaviour, some on processes and frameworks, some on system of work and the list goes on. Depending on the organisation and its context, different focus might be required.

My observation is that the different styles of coaching create different perception in the organisation. Those coaches who "preach" about the Agile manifesto and the value and principles, often looked as the “hippie coaches”. Even though their message is right, they often can't succeed in the corporate world, where it’s lot more fashionable to talk about “scaling agile” or “standardising new way of working”.

However, the coaches whose focus is helping huge corporates, can become "instituionalised" - within two years their focus and vocabulary become corporate-language and they become part of the machine.

So what can you do, if you’re one of those “hippie” coaches, who is afraid of being lost in the corporate world? And if you’re a “corporate” coach, who speaks the corporate language and became a master of agile tools and processes - but lost sight of the the original values?

This interactive talk / workshop will hopefully get these coaches closer to each other and to reality, so we can work on improving ourselves as coaches, independent on what type of people we are.

DevOps and Agile transformations are very popular in big corporates, however there is often a disconnect between the teams, the middle management, the "business" and the customer. Despite investing heavily in DevOps and Agile practices, tools and processes; transformations fail to deliver better outcome for the customers.

In my presentation I am looking at red flags when implementing Agile and DevOps practices. However, it's not just an angry rant about all the things that are going wrong. I also have a look at how we can make our organisation a better place with setting the right goals, measuring the right things and nurturing the people.

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.

Why are Agile teams supposed to be small? How big are they supposed to be? Most agilists tend to agree that a team of ten people works well.

But what is it about the number 10 that makes it the “magic” number?

Since the start of human evolution, people formed groups to be more effective. Whether it was the hunt for a mammoth or going to war, working in teams ensured a greater chance of success.

There have been various researches from Dunbar’s paper through the Scrum Guide to military formations about the ideal number of people in a team.

We’ll discuss the historical, scientific and cultural reasons why 10 seems to be the magic number of forming effective teams.

Does the number of team members really matter? Is 10 really the magic number. You will get an answer that will help you to create effective teams with the right amount of people.

Why are Agile teams supposed to be small? How big are they supposed to be? Most agilists tend to agree that a team of ten people works well.

But what is it about the number 10 that makes it the “magic” number?

Since the start of human evolution, people formed groups to be more effective. Whether it was the hunt for a mammoth or going to war, working in teams ensured a greater chance of success.

There have been various researches from Dunbar’s paper through the Scrum Guide to military formations about the ideal number of people in a team.

We’ll discuss the historical, scientific and cultural reasons why 10 seems to be the magic number of forming effective teams.

Does the number of team members really matter? Is 10 really the magic number. You will get an answer that will help you to create effective teams with the right amount of people.

Why are Agile teams supposed to be small? How big are they supposed to be? Most agilists tend to agree that a team of ten people works well.

But what is it about the number 10 that makes it the “magic” number?

Since the start of human evolution, people formed groups to be more effective. Whether it was the hunt for a mammoth or going to war, working in teams ensured a greater chance of success.

There have been various researches from Dunbar’s paper through the Scrum Guide to military formations about the ideal number of people in a team.

We’ll discuss the historical, scientific and cultural reasons why 10 seems to be the magic number of forming effective teams.

Does the number of team members really matter? Is 10 really the magic number. You will get an answer that will help you to create effective teams with the right amount of people.

DevOps is not just about technology, processes and practices. It's also about creating an organisation, where teams are empowered to enable them to deliver results early and continuously.

You can have frequent releases, use Jenkins for CI and still have a miserable culture. DevOps is of course about speed, rapid delivery and reliability - and additionally to that it's also about collaboration and culture. My talk focuses on creating and managing high-performing teams. Through a presentation of research and own experience I am providing an insight why do we need to create and manage teams based on

• “soft skills”,
• purpose,
• nurturing and
• strengths of the individuals.

The focus of my talk is how managers could put effort into building high-performing and motivated teams during a (digital) transformation.

When planning for a transformation, we often don’t think about how the cultural changes impacting our “workers” and “managers” when adopting unfamiliar technologies and new ways of working. The focus is quite often on processes, technology and how it can make money for the organisation. Employees come second, third… or often they are not even talked about.

But we can’t transform the business without our people. My talk will introduce basic but proven and effective thoughts and techniques, how we can help teams to be happier, more motivated and still transform together with our business.

One of the principles of the Agile manifesto is build projects around motivated individuals. “Give them the environment and support they need, and trust them to get the job done.”.

However, individuals have different strengths and weaknesses. Our focus shifts quite often on how to improve their performance and how we can “develop” their weaknesses. Science and my personal experience shows that building on the strengths rather than improving our weaknesses will get better results, and not only when we want to build projects around motivated individuals.

Sometimes we behave like monkeys. We imitate others, we "talk the talk" - even if we don't really understand the topic. We pretend to be agile, but we are not really. We use nice words like "business value" and "streamlining processes", but we don't really understand what our team is working on. 

In this funny, but insightful 20 minute speech I present 5 behaviour patterns that I observed in my Agile work life. As these are my personal observations, I introduce these patterns with the help of personification instead of scientific explanation (using the "Agile monkeys"). 

Fortunately, there is always a way to get better and I present the techniques I found the most useful to improve the working relationship with the "Agile monkeys" (whether it was someone else or me, who behaved like a monkey).