In a way, pair programming is like riding a bicycle. You could read a book about it, you could watch videos of other people doing it, but you can only really learn it by doing it.

This workshop not only gives people a chance to experience pair programming, but to examine that experience in depth and see how their practice can be improved.

The “promiscuous pairing” technique is used, followed by an extended feedback session where participants analyse the strengths of pairing, and look at how they can improve their interactions with their colleagues.

We like to say that agile teams own their own process by choosing their way of working, their “WoW.” This of course is easier said than done because there are several aspects to WoW. First, our team needs to know how to choose the appropriate lifecycle for the situation that we face. Should we take a Scrum-based approach, a lean/Kanban-based approach, a continuous delivery approach, or an exploratory/lean startup approach? Second, what practices should the team adopt? How do they fit together? When should we apply them? Third, what artifacts should the team create? When should they be created? To what level of detail? Finally, how do we evolve our WoW as we experiment and learn?

There are several strategies that we could choose to follow when we tailor and evolve our WoW. One approach is to bootstrap our WoW, to figure it out on our own. This works, but it is a very slow and expensive strategy in practice. Another approach is to hire an agile coach, but sadly in practice the majority of coaches seem to be like professors who are only a chapter or two ahead of their students. Or we could take a more disciplined, streamlined approach and leverage the experiences of the thousands of teams who have already struggled through the very issues that our team currently faces. In this talk you’ll discover how to develop your WoW without starting from scratch and without having to rely on the limited experience and knowledge of “agile coaches.”

More asking, less telling. As an agile leader, adopt the approach of humble enquiry to build relationships, increase trust and collaboration, and deal with the challenges of organizational transformations.

"Humble enquiry is the fine art of drawing someone out, of asking questions to which you do not already know the answer, of building a relationship based on curiosity and interest in the other person." - Edgar H. Schein

Working in an agile way asks us to rethink how we relate to each other as we tackle complex problems and challenge the traditional structures of our organizations. Humble enquiry - the art of asking instead of telling - is a critical skill for agilists who seek to improve collaboration and address difficult problems head on. Inspired by Edgar H. Schein's book 'Humble Enquiry, this workshop will teach you the fundamentals of how to do more asking and less telling. Through mini-lectures and interactive exercises, we'll discuss the different types of questioning, consider the forces around and within us that inhibit our ability to ask instead of tell, and examine how this powerful technique can improve collaboration within agile teams as well as help to address some of the challenges of agile transformations.

Five people at one computer? How can that possibly be productive?

While this seems like a reasonable question, it's not easily answered - until we begin to understand the power of flow.

Mob Programming grew from the quest of one team to learn how to work well together. Once we started We almost immediately noticed that working this way provided better results in a variety of ways:

• We were getting more done, and they were the more important thing
• The quality of our work was increasing dramatically
• Our Knowledge, skills, and capabilities were improving rapidly
• And all while we were having a lot of fun as well!

While we noticed these benefits and more, and it was clear this was in a large part due to working well together throughout the day - we didn't have an understanding of why this was working so wonderfully for us.

A hint came early on when we recognized we were achieving a one-piece flow - but we didn't realize the importance of this until we started exploring the meaning and power of "flow".

In this presentation, we'll share the results of that exploration, and see if we can get a better understanding of Mob Programming and the power of flow.

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.

After 20 years since the manifesto, the latest state of agile reports more than 80% of organizations as "still maturing" in their agile practice. As agile methods expand beyond small teams and software itself, we are still struggling to answer these questions:

• Why is it that some teams are more 'agile' than others even though they all claim to be practicing agile methods?
• What all dimensions need to change as teams, managers, and entire organizations attempt to become agile?
• How do these dimensions interact with each other?
• Overall, what does it take to become agile and how does that differ from doing agile?

This talk is based on my original theory of becoming agile developed from 10+ years of industrial research of agile practice in New Zealand and India, which received the distinguished paper award at the IEEE/ACM international conference on software engineering (ICSE), in 2017.

In this session, I will explain the key dimensions that need to transition during agile transformations, using industrial examples, and highlight what you can do to progress beyond simply doing agile, to harness the most from your agile transformations.

This keynote will add a unique research perspective to the conference program, sharing agile research in an industry-friendly format and delivery style.

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!

Agile beyond IT and beyond just doing it, but rather being it requires experimenting continuously in order to learn continuously. Thus more important than failing fast is learning fast.

In this workshop we will learn what learning fast means for every individual and the organization as a whole and we will define experiments for you to use in your company for becoming agile truly. This will allow you to create an environment for continuous innovations.

In this workshop we will also make use of examples that make:

• the organizational structure (hierarchy?) more agile
• the organizational processes faster so that they enable innovation
• the organizational strategy better aligned with current needs so that your organization is able to drive the market instead of being driven by the market

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.

For a decade of software product agile, we had worked in a structure where business responsibility of what to build was allocated to a product owner and the responsibility of how to build it was allocated to a development team. Product owner would maintain a backlog, act as voice of the customers. Until one day we realized that the choice of what to build or fix is hard, and critical to everyone’s success. If we wanted to do it poorly, we delegated it to a single product owner.

We started a no product owner experiment. For three months, we experienced the development team delivering multitudes of value to what we had grown to expect, and innovate customer-oriented solutions in direct collaboration with customers. Team satisfaction and happiness bloomed. The experiment turned into a continuous way of working.

Customer-focused team directly in touch with their customers performs better without a proxy. Join me to learn how the decision power shared for everyone in the team transformed the ability to deliver, and how collaboration is organized with product experts and business representatives.

We live in a world of "getting to yes" or "a positive no"
Yet the world is no black & white.
I live in a world of options. I like to say yes to all the options and only decide about an option at the last responsible moment. In this talk we will teach you to do the same.

Real options is one of these agile tidbits that is applicable to all aspects of life.
- a real option has a value
- a real option expires
- a real option has a cost

In this talk we will give you examples that will teach you how to apply real options to your life and projects.

In this interactive session Shane discuss his experience working in a distributed, virtual organization which is founded on an Agile Mindset. The challenges of maintaining agility when remote, the ways the ICAgile team have consciously designed their team and organization culture and provide actionable advice based on real experience on how to maintain collaboration, teamwork and live the agile values in a remote only organization.

ICAgile is a global, virtual organisation working with partners across over 100 countries spanning almost every timezone. There is no single corporate office and the ICAgile team is spread across seven locations in three countries. We have managed to build a strong collaborative culture and a truly safe working environment focused on outcomes rather than activities, holding each other to account and being really effective and productive while having a joyful workplace.

The agile manifesto was created in 2001. That is (when I write this) 17 years ago, (when the conference takes place 18 years ago.

At age 18, adult life begins. At 18 we think we know it all. Life is easy. Yet we quickly find out that easy, isn't always simple. Yves has gathered tips from many agile friends that are working in the trenches. Tips that will help your agile life.

We all know that innovative organizations are more successful. But how does Happiness at Work fit in the equation? Definitely, there is a link between happy, creative, innovative and successful organizations. In this interactive workshop, you will experience how Design Thinking and Happiness at Work go together and how that leads to success in so many organizations. We will provide practical tips on how to develop new habits to empower your creativity, empathy and thus happiness at work.

On the basis of the theory of happiness and design thinking participants will experience step by step how they can work on more creativity and innovative thinking in their organization. The workshop will be very interactive with small exercises and mind setters.

agile, devops is all about repeatable, predictable good behaviors.
Individuals have habits, teams and companies have routines.

This talk is based on a famous book about creating habits. I took what I learned from the book, and mixed this with agile ideas about teamwork.

If you have a bad habit you want to change? ==> Come to this session.
If you don't have habits and want to learn how to create good habits? ==> Come to this session.
If you want to understand what is the value of habits? ==> Come to this session.

The “Agile mindset” was introduced to the software development community in 2001 in an attempt to foster freedom in the way that we work together. Its intent was to encourage organizational change that focused on people, collaboration and culture.

But words on a screen don’t mean much in practice, especially if the people using them don’t - or won’t- understand their intent. How can individuals, teams and companies learn to correct these mistakes and break free from the challenges associated with change?

Jen will share practical advice on effective Project Management, Agile Transformation, and getting things done– all told through the stories of her own journey towards something better at Red Hat.

The speed of the team, is not the speed of the fastest, smartest person. Its the speed of the slowest. That is why in a lot of team, people don't like juniors. They think they slow them down.
In this session I want to show you the power of the junior. Why you need them.
Everyone that goes to a new team is a junior, everyone who learns a new technology becomes a junior.
At many moments in our life we are a junior.

Some experts are afraid of being again a junior, and that fear can block them from learning new stuff, which eventually will make them loose their experts status.

In this session I will show you what is the power of juniors, and why we should all embrace our internal junior.

Because the productivity driven world of the industrial era encouraged us to divide in order to control, we live today in disconnection. Disconnection from ourselves, from our team, from our society. This workshop proposes to shift the paradigm and innovate using "reconnection" principles as defined by the Theory U. To understand the way theory U operates at a people group level, a concrete framework, "Process Work", by Arnold Minundell, will be experienced.

The workshop is a hands-on experiment of impact of change on each member of a team, including the game change player. The different stages of transformation defined by the Theory U will be experimented via Process Work, and is equally inspired by the model of living systems.

The ultimate intention of this workshop is to offer participants a learning experience of emergent co-created innovation , via quality listening, and the ability to redirect perspective

You’ve worked hard, you have mastered every coding language on the planet, including COBOL. You know jenkins, travis, go, containers, puppet, chef, CFengine, nagios, github, graphite, logstash, ansible, aws, gce, vagrant, cms, cvs, abc, 123, and even a little bit of TFS. Your resume is up to date, and you are ready for your next job.

Well, slow down there… Industry trends in engineering are showing a growing desire in companies to hire people who have proven soft skills, are good at collaborating with others, and can regularly solve the most complex problem we face today: effectively talking to our fellow humans.

Please join Jen for a self-effacing and situationally humorous conversation about the journey of becoming more comfortable with collaboration, open communication and reaching through “the wall.”

Topics will include:

• “Collaborate or Die” survival skills
• The dreaded “soft skills” and how to become comfortable with them
• What to do in common situations all engineers face
• How to convince others that your idea is the right idea
• How do you get the time you need to get your work done

This is a pecha kutcha with 20 slides where I share 20 coaching tips.