Quality in Eurofins Genomics is a central focus point - analysis we do or products we produce have critical applications, be it production of drugs, identifying rare diseases or gene editing. IT is a driving force behind the scenes which challenges us to ensure the highest quality standards without compromising on speed.

When we start a new project, we do it with enthusiasm and feeling of doing something meaningful or even cool. Following scrum we quickly establish our velocity and deliver soon first release into production. Overall quality is quite good; results from testing acceptable, deadlines are coming so nothing can stop us. Let’s prioritize last bugs, fix critical, move rest into backlog – now we can be proud of having delivered value to users!

We continue delivering at ever increasing speed as team matures! Unfortunately the idyllic scenery gets soon destroyed by first, more and more effort needs to be spent addressing issues from both QA and production. We spend time arguing with QA and users on what is bug or if this defect is P2 or P3 or can even be seen as P4, from time to time we take a sprint to “stabilize”, but all too often nothing changes. User stories are getting spilled to next sprints, we postpone releases to have more time for testing, club them with next releases and finally find ourselves in downward spiral..

As quality cannot be compromised we quickly decide that Agile is fine, but as we work in regulated environment we need to be pragmatic and adjust Agile to our needs. What comes out is unfortunately not much different to Waterfall or V-Model, we still keep sprints and do reviews, but realize that only form is left. I am directly responsible for IT in Eurofins Genomics so will share experience from the field on how did we overcome this and reanimated Agile.

Ever wondered why some people prefer to work alone? Or why some people cringe when pair programming is mentioned? It might be that that person, like me, is an introvert. But is is really that simple? Can we really put every person in a box labeled "introvert" or "extrovert" or are we all just ambiverts?

During this session I will talk about introverts, extroverts and everything in between.
Drawing from almost 15 years of personal experience being an introvert on agile teams I will talk about the differences of being an extrovert
or an introvert, how to foster an inclusive team environment, and the importance of psychological safety.
You will hopefully leave this session better fit to help EVERYONE on your team to reach their full potential!

DevOps and continuous delivery is typically elaborated technically - what kind of tools, technologies, or skills are necessary for being able to deliver continuously. Often it is forgotten that continuous delivery requires also a culture change - in development, operations, marketing, sales, and not least for the customer.

This can be recognized for example, that although it is technically possible for a team to deliver continuously, but it seems that this delivery isn't welcomed. This means the actual system will not be directly used.

Therefore, in this session by taking into account the necessary cultural change, I want to answer the question how to implement continuous delivery successfully and what kind of pitfalls you need to be aware of when doing so.

The communication tools of Liberating Structures will teach you how to facilitate the discussions your org needs. I am going to demonstrate how to use these techniques in the workshop. And all the attendees are going to be fully immersed and ready to wield their new knowledge the very next day at work.

Come learn how to help your team(s), org(s), and company(ies)!!!

For more information, watch my video at http://youtu.be/UNOjqMUv8h0

A version of this workshop that was presented at Agile Tour Sydney 2016 is at http://bit.ly/2f4Bie8

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.

Imagine you are a Mad Agile Scientist and have a diabolical experiment to conduct - what would happen if you exchanged the brains of a Product Owner and Scrum Master? Mwuhahahaha!!! How would the body of a Product Owner with the brain of a Scrum Master act? And vice versa?

Perhaps the Scrum Master would now treat the team like a backlog? This Scrum Master would be focused on value and maintaining a coaching backlog of team and person improvements. This Scrum Master is refining the team, crafting a group that delivers value.

And perhaps the Product Owner might treat the backlog like a team? Rather than backlog refining, they coach the backlog. They would be focused on nurturing, protecting, and empowering the backlog. The backlog might transform from an irritation into a labor of love.

Although this experiment sounds terrible, this change of perspective might be what you need to reanimate your dead team or backlog.

Join the fun and come learn what horrifying results await!

Agile methodology is not limited to software development but it can be applied beyond. I am sharing the experience of applying the Agile, to drive the volunteering activity for the social cause. Volvo Group’s Global Safety initiative for Kids – Stop, Look & Wave is a program with young children (aged 4-10) at schools or communities – introducing them to Road safety .

The success of the program was based on support from management ,engaging volunteers (team members) and touching the young hearts to become the Safety Ambassador. Agile methodology and Mindset is applied for planning and execution and was very helpful to achieve the objective.

Using a simple model to focus leadership on applying a cohesive set of transformational changes can improve the success of a agile adoption. This session explores how this model helped, and is continuing to help, the Boral Digital Solutions leadership team decide on a set of cohesive changes such as the adoption of Scrum, the use of Objective and Key Results, and the establishment of a culture code to accelerate its agile transformation.

Boral is a construction materials company founded in 1946. It adopted Lean practices in its manufacturing areas over 10 years ago but only recently started on a Technology/Digital transformation. Because Boral spans a diverse business from mining through to the delivery of construction materials, there are endless opportunities to pick from in building a highly engaged, autonomous workforce.
The challenge is creating clarity and focus from these choices as to what we will do, and what we won't. Using a simple model about how we work and how we engage our people, we are able to:
1) Create clarity and focus around a cohesive set of impactful changes
2) Build engagement and buy-in with executive leaders
We will explore how this model is currently helping Boral, as well as how it can help you in your own transformations. Having evolved through different industries (Campaign Monitor - Software Start-up, Commonwealth Bank of Australia - Financial Services), this model can help you create clarity and focus around what to do when you can't do everything.

Presenters: Ed Wong, Founder of the LAST, 1ST and Spark the Change conferences and Bruce Taylor, Agile Coach at RMIT Online.

Outline of program: How we used internal meetups, workshops, gamification, and learning design to build agile capability at RMIT University (One of Australia's oldest tertiary education institutions) as they navigated the rapidly changing world of online education.

With more and more institutions moving online, with all that implied in terms of speed, tech capability and agility, RMIT Online needed a world class agile capability. Ed and Bruce set up FERAL (The Federation of Eminent RMIT Online Active Learners): A fun, yet serious, way of fast tracking agile knowledge and practice within the many, disparate teams within this fast growing arm of the University. It was also a way of scaling learning and the effectiveness of 2 agile coaches working across multiple teams.

In this session we'll talk about the design of the program, the buy in needed from organisation, the types of workshops we ran, some practical examples from the workshops and our experiences running them and post-workshop application and coaching back in the teams to embed the practices.

The world of devops is a part of the agile journey that non techies may find intimidating. This talk demystifies the path to production.

Those of us who are used to uncovering new ways of developing software may struggle with the pace of executives and business teams adapting to a more agile way of working.

• How do we stay inspired?
• How do we leverage our experience with frameworks designed for technical teams?
• Do we know how to do this?
• How is leadership different?

I know something you don’t know. You know something I don’t know. And I don’t know what you know that I would need to know. This is where individual contributor approach to software development and testing breaks down. Why aren’t we working together, contributing together and learning together? Why do we, often at best, collaborate on the requirements and understanding of what to build, and then step away for implementation, only to come back to test it after?

This talk looks into my experiences in pairing (two people one computer) and mobbing (more than two people one computer), and the wonders of being a non-programming tester whose ideas get translated into code as equal. The journey to get to pairing and mobbing has been a rocky road, with loads of practical tips to offer on how to approach it.

In software development, those who learn the fastest do best. Could pairing and mobbing take us teamwork to the next level by enabling learning between everyone? Lessons specific to skillsets rub in both ways, leaving everyone better off after the experience.