June 13-17, 2022
Copenhagen, Denmark


Industry and Practice

Comparing Pair-Programming to Red-Green-Refactor-Review Flow.

Alex Fedorov (RIDE Capital).

Abstract. 100% pair-programming is an effective method to get instant feedback and collaborate. Applying this method skillfully can significantly reduce the need for an asynchronous code review process, which improves the team’s work-in-progress.

However, in a remote and hybrid setting, it may be tiresome to pair-program for the whole day, every day, staying on the video call. Our experience is that remote and hybrid pair-programming is more energy-draining for people than the in-person version.

We hypothesized that there must be a method to achieve the same outcomes as pair-programming (e.g., short feedback cycle) that doesn’t require people to be constantly on the video call.

As the result of this thinking process, we have come up with an extension of the classic TDD cycle “Red-Green-Refactor” by adding a code review step on top of that.

Here’s how it works:

  1. RED — you write a failing test.
  2. GREEN — you make it pass with the most straightforward implementation increment.
  3. REFACTOR — you act on any refactoring opportunities that you can spot. You also review your fellow developer(s)’s comments on a few of your previous commits to the main branch. You either tackle these as part of this refactoring step or add them to your to-do list. If there are no refactoring opportunities, you proceed to the next step.
  4. REVIEW — you review a few last commits on the main branch made by your fellow developer(s)’s and leave code review comments. If there is nothing to review, you proceed to the next step.
  5. Go back to step 1: RED.

To ensure that other developer(s) can review the code frequently enough, it’s essential to make very frequent commits as part of this process. Recommended frequency is at the end of each RGRR cycle, just before writing a new failing test.

In this workshop, we’ll solve the same problem twice using two techniques for instant code feedback: well-known Pair-Programming with TDD and an innovative Red-Green-Refactor-Review flow (RGRR).

Then we’ll compare the results and discuss trade-offs.

Keywords:   Pair Programming, Code Review, Test-Driven Development, Red-Green-Refactor, Trunk-Based Development

Finding Team (and Architecture) Boundaries with Domain Storytelling.

Stefan Hofer (WPS – Workplace Solutions).

Abstract.  Misunderstandings between developers and the business are a plague. Bad communication makes projects fail. This workshop presents a remedy.

Domain Storytelling is a technique to transform domain knowledge into effective business software. It brings together domain experts and development teams to: (a) understand the domain of a software system, (b) find meaningful boundaries for teams and architecture, and (c) talk about requirements.

We let domain experts tell us stories about their tasks. While listening, we record the stories using an easy-to-understand pictographic language.

The domain experts can see immediately whether we understand their story correctly. After very few stories, we are able to talk about the people, processes, and events in that domain.

The workshop is aimed at everyone involved or interested in software development, including non-technical people. In small groups, you will create domain stories and analyze them to find boundaries.

Keywords:   Collaborative Modeling, Communication, Process Modeling, Domain-Driven Design

Lead Without Blame: Enable Resilient Learning Teams.

Diana Larsen (Agile Fluency Project LLC).

Abstract: In today’s fast-changing VUCA world, leaders need new tools and techniques that ensure reliable results. Old habits, like assigning individual tasks or finding who to blame for failures, waste precious time and effort. New ideas, like preparing teams for resilience to change, will foster faster learning, improvement, and delivery cycles. Join experienced leader, Diana Larsen, for an exploration of useful models leaders can apply today and tomorrow to enable resilient learning teams.

Keywords:   leadership, learning, resilience, teams, resilient learning teams, blame, accountability, leaders, useful models, psychological safety

A Simple Approach to Managing Complexity.

Jutta Eckstein (IT communication) and Buck John (Governance Alive).

Abstract. We often find ourselves in complex situations without recognizing what makes them complex. For example, what aspects of hybrid workplaces increase (or even decrease) complexity? Fortunately, understanding the context can help us to benefit from the situation by reducing or even increasing the complexity.

In this workshop, we will introduce a simple tool for understanding the context of complexity (the difference matrix of Human Systems Dynamics, HSD in short). HSD helps us see the differences and exchanges that make a situation complex and as well as providing hints for changing the level of the complexity. Using a case study, participants will experience in small groups an example of how they can use the HSD difference matrix.

Keywords:   change, complexity, differences, exchanges, Human Systems Dynamics, hybrid workplace

Unified Flow – From teams to organization.

Marcelo Walter (Objective) and Pedro Cruz (Objective).

Abstract. Unified flow is a method to scale agile/Kanban.

It is based on XP, Kanban, and the principles exposed by Don Reinertsen in ‘The Principles of Product Development Flow’.

In summary, the definition is: ‘Multiple teams working on multiple projects (product demands) in a shared flow, single backlog and workload balance (flow pressure)’.

In other words, what if your teams were able to consume demands from any request, and share the capacity over all the organization?

Yes, it is possible. And it has been done increasing the quality and productivity –  6 to 12 times on average!! Less than 1% staff turnover over five years.

We (and some others) replicate this method many times in many companies.

That’s what we will talk, show and discuss in this session.

Keywords:   scale, Kanban, Agile, XP, capacity, workload, Unified Flow

Don’t scale your teams, scale your products! – With event storming to high-performance teams.

Nils Hyoma (Novatec Consulting GmbH).

Abstract. Agility in a large department with many developers and stakeholders is anything but trivial! The Scrum Guide called for developers to be limited to 9 people per team by 2020. After that, at the latest, the definition must break this up into two parts. Since these teams work on the same product, they share the requirements, and depending on the scaling framework, they need further meetings for coordination. The risk of a joint release of the product also increases significantly.

But how do larger software development departments with many developers work on a product at the beginning of their agile transformation? Many large organizations established on the market rely on scaling frameworks to coordinate teams, releases, and requirements. For these frameworks like LeSS, SAFe, and Nexus, there always seems to be an implicit assumption: the number of teams in the variable, not the complexity of the product itself.

But it is precisely these top-down approaches that do not solve the problems of a complex product. The goal of Scrum, to get feedback on the development, the so-called increment, at the latest after each sprint, is almost never achieved. Learning cycles are becoming significantly longer. In addition, the approaches even bring new problems. The technical dependencies, the political games, and the problems between the teams increase sharply.

In order to make the complexity manageable, the product has to be broken down into smaller but value-adding units. But how can this be realized? Collaborative approaches suggest themselves, in this case, strategic domain-driven design with event storming and domain storytelling. It divided large systems or monoliths into so-called bounded contexts. Based on these contexts, it can realize more autonomous teams and products. By considering proven communication and collaboration patterns, such as the sprint review or the backlog refinement from Scrum, it can then coordinate relatively easily the releases across teams and products.

The practical talk takes up two real project situations and problems and shows how to work with the department and the developers to get through dynamic, self-organizing units. Nils Hyoma presents the empirical values ​​gained in the agile project in a highly complex environment in compressed form. He explains how and why a well-executed strategic domain-driven design can become a key success factor in agile projects.

Keywords:   Event Storming, Collaborative Moddeling, Scrum, Scaled Agile

Understanding the impact of the cost of delay: Optimizing for value across the enterprise

Jorgen Hesselber (Comparative Agility, LLC)

Abstract. Successfully unlocking business agility at the enterprise level requires finding a careful balance between flow and resource optimization that’s appropriate for your organizations’ unique context. While this may sound great in theory, the practical implications of finding this balance can be incredibly complex as there are a myriad of factors to consider. The workshop aims to simplify this dilemma by focusing on economic sensibilities to prioritize, organize and ultimately operate as a more agile organization. Through real-world examples and interactive group exercises, this workshop ensures attendees have a practical understanding of Cost of Delay so they can start using economics as a guiding principle towards organizational agility.A

Agile For Future: With Agility to greater Sustainability

Jutta Eckstein

Abstract. According to one forecast, IT will account for 21% of global energy consumption by 2030. If we don’t change the way we implement software, we will contribute to increasing the carbon footprint. So, it’s time to examine how agility can help reduce energy consumption and ensure greater – environmental, social & economic – sustainability. The point is not to pursue sustainability for altruistic reasons, but to understand that over time, sustainability is also becoming a key factor that determines the success of companies, both in the search for talent and for customers and markets.

Based on concrete examples, in this session, I would like to examine what sustainability means for agility and raise awareness of our contribution.

Bio. Jutta Eckstein works as an independent coach, consultant, and trainer. She has helped many teams and organizations worldwide to make an Agile transition. She has unique experience in applying Agile processes within medium-sized to large distributed mission-critical projects. Jutta has recently pair-written with John Buck a book entitled Company-wide Agility with Beyond Budgeting, Open Space & Sociocracy (dubbed BOSSA nova). Besides that, she has published her experience in her books Agile Software Development in the Large, Agile Software Development with Distributed Teams, Retrospectives for Organizational Change, and together with Johanna Rothman Diving for Hidden Treasures: Uncovering the Cost of Delay in your Project Portfolio.

Jutta is a member of the Agile Alliance (having served the board of directors from 2003-2007) and a member of the program committee of many different American, Asian, and European conferences, where she has also presented her work. She holds an M.A. in Business Coaching & Change Management, a Dipl. Eng. (MSc.) in Product-Engineering, a B.A. in Education, and is trained as a pollution control commissioner on ecological environmentalism.

Playful Agility at the LEGO Group.

Carsten Lützen (The LEGO Group).

Abstract. We often talk about different stances for an Agile Coach: Coaching, Mentoring, Advis- ing, Teaching, and Role-Modelling. How would you feel about adding another one? One we could call Playful. In this talk, you, me, and the rest of the audience will go on a journey together to see if we can figure out when, and how, to introduce playfulness in meetings, everyday work life. And when not to.

We will try and see what happens if we apply a playful coaching stance in different situations. What does that entail? Non-stop dad jokes? How can we be playful in our process design? Can curiosity or playfulness save the cat? And are there situations where this would be counter-productive?

Getting a team to work together has never been a trivial thing, and with the rise of work-from-home, this can become even more complex. But maybe, being a bit playful can help? How can we effectively build playful teams, that foster high psychological safety?

This will be an interactive session where I will share concrete tools and exercises that, in a playful way, can be used to generate ideas for product improvements, team missions, retrospectives, etc.

Later in the talk, we are going to mix Liberating Structures, Solution-Focused Coaching, and games and see what emerges. Some things will work, some things will not, and I will share the pretty and the ugly experiences, hopefully giving you a headstart for when you get back and wants to try out being more playful.

And why all of this you might ask? As an Agile Coach at the LEGO Group, we hear that the core belief in the LEGO Group is “Children are our role models.” I always try to bring my inner child to work, but what does that actually mean? We will try to figure out how we channel curiosity, playfulness, and creativity in more aspects of our work.

Keywords:   agile, facilitation, coaching, liberating structures, solution-focused, graphical facilitation

Live Test Driven Development.

Sebastian Larsson (Knowit).

Abstract. Test driven development (TDD) is a technique that developers use to develop software. With it comes expectations such as; executable documentation, loosely coupled components and a safety net for refactoring. Many presentations have been made about TDD, but here Sebastian will show you in a live demonstration. After a short introduction to TDD, we will construct a todo list, followed by iteratively developing and refactoring code. If not for TDD, you can attend this session just to get inspired by how to leverage your IDE.


Individual Performance Appraisals for Agile Teams.

Alexandre Nodari (Percival) and Klaus Wuestefeld (Percival).

Abstract. Team-Set Salaries (TSS) is a next-generation performance appraisal process that uses an elegant algorithm to solve a key problem in people management today: How do we set fair compensation for individuals in multiskilled, collaborative teams?

Throughout the last decade, management and HR gurus have recommended abolishing performance appraisals altogether, without providing any solution for fair compensation of individuals in collaborative teams. The industry as a whole is at a loss, struggling with several complicated approaches. Deloitte calls it “The Compensation Conundrum”.

I will present the Team-Set Salaries (TSS) process and explain why it is the only individual compensation process that is:

Fair – Results are not only fair, but also perceived by the team as being fair.

Actionable – TSS produces a precise numerical result for each person’s compensation.

Collaborative – Appraisals are made by team members themselves.

Easy-to-use – Team members take only 15 minutes each to carefully express their appraisal of their colleagues’ work.

Scalable – There is no limit to the size of the team.

TSS is used by companies to set salaries, share bonuses and even to distribute company equity.

Keywords:   Performance Appraisal, Compensation, Motivation, Autonomy

On the Internet, Nobody Knows You’re a Dog, or Remote Working for Agile Workers.

Steven Baker (Industrial Logic).

Abstract. In the late 90s, Steven Baker was able to bootstrap his career while working remotely from home, despite being a teenager.  He attributes this to the fact that on the internet, nobody knows you’re a dog.  In that time, he’s worked nearly exclusively remotely, and has learned an awful lot about what works, what doesn’t, and how to do it well.

Remote working had been growing in popularity for years.  Thanks to the ubiquity of internet connectivity, increased battery life in laptops, mobile phone tethering, and other technological advances, it’s easier than ever to work remotely.

Due to the recent worldwide situation, remote working is now often the default, and many are having trouble adjusting.

In this talk, we will explore effective techniques of working on agile teams remotely.  We’ll discuss environment setup, tools, activities, and practises that can help remote workers be more effective. Most importantly, we’ll talk about how to use remote working to your advantage to be happier, and have a healthy work/life balance.

Agile is about responding to change in your teams and software: remote working is about embracing agility in your working environment.

Keywords:   remote work, pair programming, teaming, remote teams

 Lessons from Lasso: Humble Inquiry and Beginner’s Mind.

Matthew Philip (Pfizer) and Michelle Pauk (Pfizer).

Abstract. Ted Lasso may be a fictional coach, but his coaching — imbued with humility and inquiry — is an example for anyone in real life. In the eponymously named hit series, Lasso — a head coach of a championship American football team — takes on the challenge of coaching in a totally different sport: football as it’s known in the rest of the world. This session draws out and applies the lessons from Lasso’s humility, trusting others and “beginner’s mind.”

Learning outcomes

  1. Ways that a beginner’s mind and humble inquiry can help our teams and the people we support
  2. Benefits of beginner’s mind for coaching and any learning endeavor
  3. How humble inquiry makes us better teammates

Session type: talk

Target Audience: all, particularly people in enabling roles

Prerequisites required of attendees: none

Level: practicing or expert

Bio: As an organizational fitness coach and refactorer, Matthew helps organizations evolve toward greater fitness for purpose via agile methods and engaging work environments. As senior director at Pfizer, he leads a coaching group that takes an evolutionary, generative and outcomes-based approach to improvement across the organization.

Keywords:   coaching, beginner’s mind, humble inquiry, servant leadership, learning, psychological safety, generative culture

Writing a story together; Ensemble Programming without programming.

Karel Boekhout (Hedgefields).

Abstract. Ensemble Programming, also known as Mob Programming, is slowly emerging from the basement lab of very experimental practises into a mainstream tool. Pair Programming for 3+ people has grown into a proven way to deliver high quality software, without delays or coordination overhead.

Join me to have fun in this version of Ensemble Programming, where we create something that is not code: a story! We’ll use the same format as an ensemble of developers, but there will be no technical skills required. As we build the story, line by line, we will also introduce different aspects of mobbing, and learn different ways of organising the group.

I’ll share variations of Ensemble Programming as used with different development teams, from absolute beginners to serial mobbers with specialised alterations.

Keywords:   Ensemble, Non-technical, Ensemble-programming, Mobbing, Mob-programming, Fishbowl

Unified Flow – From teams to organization.

Marcelo Walter (Objective) and Pedro Cruz (Objective).

Abstract. Unified flow is a method to scale agile/Kanban.

It is based on XP, Kanban, and the principles exposed by Don Reinertsen in ‘The Principles of Product Development Flow’.

In summary, the definition is: ‘Multiple teams working on multiple projects (product demands) in a shared flow, single backlog and workload balance (flow pressure)’.

In other words, what if your teams were able to consume demands from any request, and share the capacity over all the organization?

Yes, it is possible. And it has been done increasing the quality and productivity –  6 to 12 times on average!! Less than 1% staff turnover over five years.

We (and some others) replicate this method many times in many companies.

Keywords:   scale, Kanban, Agile, XP, capacity, workload, Unified Flow

#performanceData #measureSoftwareQuality: Can we effectively measure the quality of a software, team in distributed agile?

Paramjeet Dahiya (Thoughtworks)

Abstract. Often teams find themselves following different practices that are known to them which should drive them to deliver effectively, But lack ways to measure their effectiveness, performance, backed by data. The data which should enable measurement of the performance, pinpoint the problems and celebrate the victories.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.


As quoted from the agile manifesto, teams should have regular checkpoints to reflect on their effectiveness and how it can be improved. Teams need to have ways to find out data points to reflect upon, which are reliable and meaningful to them.

Data backed retrospection of team’s performance has become even more meaningful when we are working in a distributed manner.

This talk will present useful ways:

To gather the meaningful data not only to ascertain the technical quality of the product being built but also how the team is progressing towards building a software product. Starting from how the team is doing in gathering requirements to monitoring and reacting to delivered and new requirements.

To interpret the gathered data. Do’s and Don’t with respect to gathered data.

To react to the data so the teams can reach full potential. And what could be counter productive to measure. Based on personal experience of working with such data.

Learning Outcomes:

Challenges faced in distributed software development which often leads to mistrusts.

Understanding of meaningful data already generated, ways to gather that in a way that makes sense.

How to derive actionable outcomes and create a transparent way which is easy to reflect upon from this data.

Keywords:   Optimize an agile team’s performance, Software quality metrics, measure tech excellence

What are your Automation Strategies?

Lisette Zounon (Zsquare Solutions Inc).

Abstract. Everyone in your organization has probably discussed automation at least once.  But who is responsible for automation? and what are the automation strategies for your organization? Several factors should be considered before jumping into automation.

In this session, I will share my personal experiences and cover case studies and successful quality transformation. I  will also cover what to consider for your automation strategies because it always depends on your organization and what you are trying to achieve.

Attendees in this session will take away :

–  identify your automation framework

–  Determine what automation testing infrastructure

–  Deciding which tests to automate among your regression suite

–  Determine if you are ready to introduce machine learning or artificial intelligence to your testing?

Keywords:   automation, framework, testing

Unfreezing Resistance to Change with the SCARF Model.

Michelle Pauk, Matthew Philip and Ioannis Totlis (Pfizer)

Abstract. What causes some people to lean into change, while others resist and shut down? In this workshop we introduce the SCARF (Status, Certainty, Autonomy, Relatedness, Fairness) model in relation to agile team coaching, based on the information presented in the whitepaper “SCARF: A brain-based model for collaborating with and influencing others” by David Rock of the NeuroLeadership Institute. We connect these concepts with the notion of psychological safety to inspect our own behavior as agile coaches and uncover how we can reduce the threat we pose as change agents to those we hope to serve.

Ioannis Totlis is an Agile practitioner and enthusiast. His passion for Agile began during his software engineering years in the telecommunications industry, working for Ericsson and Intracom Telecom. As a Scrum Master and Coach, he has helped various organisations discover how Agile can improve their everyday operations and company culture. Currently he works as an Agile Coach at Pfizer, contributing to the Agile transformation of the company

Keywords:   Change, neuroscience, Psychological Safety, coaching skills, Team Coaching

Paved with good intentions.

Wouter Lagerweij (Wouter Lagerweij Consultancy).

Abstract. A talk about unintended consequences.

The problems remain the same. Legacy systems. Disengaged employees. Defects all around. Long delays getting software released. Being left behind by the competition. But why does everyone run into the same problems? And can they get out?

They say the first rule of holes is to stop digging. There’s a reason we start digging in the first place. We thought it would get us closer to where we needed to be. It just happened to get us stuck at the bottom with very few options of escape.

This talk is all about unintended consequences. The dysfunctional situations we encounter are created because well intentioned actions, intended to fix real problems, have only caused more and deeper problems. We simply didn’t foresee the wider impact.

We can take a page from systems thinking, but how do you know what to look out for? I’ll use familiar, concrete examples, to show what type of impact to look out for and how to see if you are just doing local optimizations. I’ll also provide a simple and quick checklist to help avoid overlooking undesirable impacts. After all, when we know where the holes are dug, we can avoid falling into them.

Keywords:   Organizationalchange, Organization-design, Systems-thinking, Organizational-structures, thinking-

Leading Responsible Adults.

Brenda Leeuwenberg

Abstract. The impact of remote working on our culture, our workplace structures and values, and on our people, has been huge.

Many organisations put a lot of energy and effort into taking care of their people. An amped up focus on wellbeing, on mental health and on looking out for each other permeated the more onto it workplaces. But this potentially has come at the expense of autonomy, of independence and responsibility. It’s also come at the expense of the health and wellbeing of many of our leaders.

This talk explores the impact of COVID on workplace culture, through a lens of leadership and being adults.

Based on interviews with executives, leaders and my own experiences I explore trust, wellbeing and communication as tools for the emerging hybrid workplace.

Bio. Brenda Leeuwenberg is a digital strategist with a strong agency background. She’s a co-founder of Nomad8, an Agile coach and trainer, and a scientist in a previous life. She works with clients to develop strategies for a variety of contexts. Brenda is currently the Delivery Director for a leading digital agency in New Zealand, guiding them through significant change – and introducing Agile ways of working through the creative sector.

LEGO Group’s agile journey.

Nils Michaelis

Abstract. Learn what role agile plays in the LEGO Group and how the company’s IT organization is currently transforming into what is now called Digital Technology.

The company is doing really well – so why bother changing? How does their agile and digital transformation affect the rest of the business, the role of leadership, and how investments are funded?

Hear about some transformational challenges and learnings along the way and what’s next.

Mastering Agile Coaching.

Bent Myllerup and Mogens Villadsen

Abstract. According to the State of Agile Coaching Report 2021 (https://resources.scrumalliance.org/Article/state-agile-coaching-report) only 19% of people who consider themselves to be Agile Coaches has a master level certification in this area. We do not believe that you blindly can evaluate people’s competences based on their collection of badges, but we think there lies a degree of truth within the numbers. We see it as a potential risk of damaging the reputation of the profession when the numbers are as low as indicated.What does it take to be a master Agile coach?Well, we think you first of all must have your Agile foundation in order. You must where Agile comes from; you must live the values and principles; you must know the various frameworks and practices and you must have the personal experiences of being practicing it yourself for years. You must have had your hands on the hobs for a while and know how it feels and smells.Another important matter is your awareness of your personal experiences and opinions as not directly applicable to the context of those you are coaching. Often Agile coaches are contracted for a limited time to help an organisation implement agile approaches. There is no chance you are going to gain a deep insight of the dynamics of the organisation in this short time. You need to rely on the members in the organisation and, in our opinion, you serve them best by enabling them to manage the change. In other words, unlock their potential to succeeding with Agile.This is where Systemic coaching comes in. Our experience is that the clients of Agile coaches highly benefit from their coach being skilful in professional coaching techniques, as this enables them to take ownership and act during the change.We have been educating Agile coaches in professional coaching techniques for more than a decade and in this workshop, we will take you through the fundamentals of Systemic coaching and some of the advanced techniques as well. Most importantly, we will do this by making you practice it throughout the workshop. We will also address when coaching is not the answer.You do not become a full-blown systemic coach after these few hours, but you have started on your journey of mastering Agile coaching and you will be ready to apply the learnings in your practice right away.

#GameChangingBeliefs for the Knowledge Working Organization

Morten Elvang (Nordic Business Agility Lead, Accenture)

Abstract. How can you create an organization where succeeding with agile is possible? Are there things you could choose to believe in that would push your luck in a favorable direction? Does it make sense to think like this? And if so, what should you then choose to believe in? This interactive talk argues in the favor of this and offers practical examples of what such beliefs could be.

This is about organizational design from first principles. The content and form have been iterated over several past XP conferences in conversations and collaborations.

Agile Games

Stop one-size-fits-all Transformation.

Martijn Oost (LEAT Academy) and Martijn Nas (LEAT Academy).

Abstract. LEGO your Transformation

If 80% of transformations are not successful, why do we insist on using the same textbook transformation approaches? Because until now there was no real alternative for large organisations? We believe we have found a radically better way and would like to share and open-source this with the Agile community. We use next-level LEGO simulations to teach and experience Agile frameworks before implementing them. With LEGO SERIOUS PLAY (LSP) we achieve real transformative moments by tapping into the hidden expertise of an organisation, converting insight and awareness into shared principles and objectives. All this while playing and having fun. LEGO ensures fully engaged participants minimal resistance and makes learning feel very natural.

Inspect & adapt transformations even before implementation

We will show you how you can use the Learning Experiential Agile Transformation(LEAT®) framework to design learning workshops that will allow you to inspect & adapt your transformations even before implementation, usually giving you a headstart of multiple improvement cycles. The workshop modules we use within the framework are ready to use out of the box but can also be adapted to your context. From a single starting Scrum team to custom scaled agile for a multinational, from 50 minutes to multiple days, from 1 sprint to full quarterly cycles we have facilitated and simulated them all with great results.

Stop one-size-fits-all big bang framework roll-outs or endless pilots in enlightened corners of the organisation. Start learning agile through safe experiments, it’s certainly no guarantee for success, but it is so much more fun and creates an inherently agile start or reset for your transformation.

Keywords:   LEGO SERIOUS PLAY, Experiential, Learning, Gamification, Simulation, Shift-left, Scaling, Fun, Engagement

Maturity Card Game – To know and to act.

Marcelo Walter (Objective) and Wagner Voltz (Objective).

Abstract. Engage in this game to know your organization/product/area maturity level or just for fun.

This session will show a competitive card game inspired by OWASP Cornucopia and Dixit to play in your company to check who is the best strategist and, in the side effect, discover your KMM  level.

It´s an excellent game to learn, reflect and take action.

In the end, we will have a game-winner person but also a prioritized backlog to improve our company.

Keywords:   maturity, organization, KMM, card-game, online game, agile game

Corona blues in agile teams? – Create stirring retrospectives with gamified storytelling.

Kira Naehring (Novatec Consulting GmbH) and Nils Hyoma (Novatec Consulting GmbH).

Abstract. You are a Scrum Master, and the retrospectives are no longer what they were before Covid 19? The participants no longer have a camera on, are difficult to inspire, and are not very communicative, you can no longer get answers to open questions and the mood is in the basement…

These are typical challenges of agile teams in the current exceptional situation. We, too, have had to make these experiences. With playful elements and stirring stories, we were able to reactivate many members.

Kira and Nils (both Agile Coaches of Novatec Consulting GmbH) share their experiences and challenges with you and invite you to an interactive workshop. In about 90 minutes we discover together the possibilities and advantages of gamification in combination storytelling for retrospectives. Our goal is that you can take new ideas from the workshop for your next retrospective.

About Facilitators:

Kira Naehring is a consultant (Novatec Consulting GmbH) and supports agile teams with retrospectives and workshops. She completed her studies in 2021 with a degree in information management and technology and developed a tool for assessing the transparency of agile teams in her master’s thesis.

Nils Hyoma (Novatec Consulting GmbH) is an agile coach and privately passionate water polo player. As a coach, he forms teams from developers and analysts who can develop products independently. His mission statement is always focused on customer satisfaction. Nils deals in depth with the Scrum Framework and talks about collaboration and backlog refinement at international conferences, such as Scrum Day Europe or Vietnam.

Keywords:   Sprint Retrospective, Gamification, Storytelling

The Sprint Experiment.

Bo Malling Christensen (Ørsted).

Abstract. Bo Malling, Product Leadership Coach at Ørsted; long-time player of games, first-time creator of games.

Whereas most agile games are fun, I find they focus primarily on some of the more elementary concepts of agility rather than the essentials. The Sprint Experiment focuses on fast learning rather than fast delivery, outcome rather than output and can be facilitated online as well as physically.

The Sprint Experiment is free to use and comes with a complete facilitation guide. The game simulates two sprints using nothing but Miro, a video conferencing tool and whatever each participant already has access to.

The ideal participant is an individual or a team who wants to deliver products sooner, embed knowledge sharing in their daily work or improve their team spirit. The game will also inspire you in better ways of using concepts like burndown chart, daily stand-up, definition of done, definition of ready, sprint goal, sprint review, velocity, WIP limit and working agreement.

I want to share The Sprint Experiment as I have already gotten a lot of promising feedback internally in Ørsted, and now I want to share the concept with whomever wants to try it out to have fun and gather more feedback for improving the game.

The game requires 1-2 facilitators per team of 4-11 individuals.

The game needs an hour preparation for a new context, but no preparation for multiple sessions in the same context. This can be done in advance.

There is a 10 minute briefing in the beginning, and a 20 minute debriefing at the end to ensure insights are gathered, shared and ready to be applied. Additionally, there will be reflections embedded in the simulation. The ideal duration of the session is 120 minutes, but it has previously been done in 90 minutes. The Sprint Experiment would fit best in a regular time slot, as the best insights comes from having a committed, stable team for the entire game.

Keywords:   Learning, Outcome, Online, Sprint, Experiment

Generative Scaling Game.

Matthew Philip (Pfizer).

Abstract. Inspired by Luca Minudel’s Agile at Scale Generative Principles, this game addresses needs for today’s teams and organizations to be able to accommodate scaling concerns in a generative way so that people can continue to do their best work and reduce the friction of more heavyweight approaches to scaling.

Learning outcomes:

– Alternatives to push-based, deterministic models of planning

– How to coordinate across multiple levels and upstream and downstream workflows

– How to use data to forecast

– How to reduce the pain in moving from points-based sprint loading  to flow-based workflows and time-based forecasts

– How to accommodate various delivery approaches (e.g., Scrum, flow-based) without requiring them to standardize to one approach

– How to use lightweight techniques for scaling, such as contextual-improvement feedback loops, blocker clustering, flight levels and probabilistic forecasting

– How to create policies for workflow boards to optimize economic outcomes and flow

Keywords:   planning, coordination, forecasting, scaling, policies, generative, dependencies, game

Dice Game Challenge for software Teams.

Elmohanned Mohamed (IBM Australia).

Abstract. Predicting throughput of software teams can be challenging. The interplay of variance and interdependency can lead to unexpected performance. In his book, The Goal, Dr Goldratt introduced the Dice Game to demonstrate the impact of this interplay of flow and throughput even in a perfectly balanced system.

In this workshop, we will play a version of Goldratt’s game adapted for software teams. The audience will be split into groups, each table representing a software delivery team. Each team will run through several iterations progressing the flow of their backlog through the delivery pipeline. The dice will introduce variation in each iteration. Teams will be asked to capture several metrics as they play turn by turn: throughput, WIP, utilisation, cost, and bottlenecks.

After the game an open discussion will be held around the results of the game, sources of variation and interdependence in software delivery, the role of upfront estimation versus flow management and the relation between utilisation, and throughput.

Finally, the results of running computer simulations of the same game with different variability distributions, pipeline lengths, utilisation levels and batch sizes will be presented to the audience will be presented to the audience discussing impacts and possible interventions.

Keywords:   TOC, Flow, utilisation, variability, interdependence

Get MAD and Get SERIOUS – Using LEGO SERIOUS PLAY Games to Make a Difference.

Steve Holyer.

Abstract. Look around. Everything is NOT awesome. So what can you do to make a difference – individually or as part of a team? This session is about getting MAD and Making an Awesome Difference. (See what I did there?) You will use the LEGO® SERIOUS PLAY® methods and materials to uncover new ways that you and your team can make a difference in a mad, mad, mad, mad world.

Let’s have fun. After a full week, would you like to chill out and play a game with LEGO bricks? If so – on the last day of XP2022 – let’s relax and enjoy using LEGO SERIOUS PLAY methods and materials to reflect on your discoveries over this past week. Identify what you can use now to make a difference. By playing you’ll build plans for using your most valuable XP2022 experiences to do something that matters when you get home.

(This session is limited to 30 participants.)

LEGO and SERIOUS PLAY are trademarks of the LEGO Group

Maturity Card Game – To know and to act.

Marcelo Walter & Wagner Voltz.

Abstract. Engage in this game to know your organization/product/area maturity level or just for fun. This session will show a competitive card game inspired by OWASP Cornucopia and Dixit to play in your company to check who is the best strategist and, in the side effect, discover your KMM level. It´s an excellent game to learn, reflect and take action.
In the end, we will have a game-winner person but also a prioritized backlog to improve our company.

Keywords: maturity organization, KMM, card-game, online game, agile game

Experience Reports

Using a chatbot to do DevOpsCust (*).

Stine Nørgaard Olesen (Alm. Brand).

Abstract. How do you re-invent great customer experience in a 230-year-old compliance regulated conservative company – whose products are the least sexy you can buy, and whose customers identify your brand with an old man in tweed?

This is a story about having the courage to launch a chatbot with very little content on the corporate main website, which is visited 1500 times a day by both customers and prospects. Why is that genius? Because with that many visits per day you have the perfect platform for getting insights on what topic is trending through the interactions with the chatbot – thereby, the customers write the requirements themselves, 100s of times per day.

With this solution, it’s never been easier for us to be close to our customers, and even deploy what they want several times a day. Working agile is perfect for this – the ability to ‘Turn on a dime, for a dime’. Two-weeks-sprints are almost too long for this fast-delivering AI Trainer team, so even within the sprint, every day requires a mini planning, and based on the feedback from customers, team members will self-organize around different topics to be deployed during the day, and then start over next day. On a daily basis the team simply delivers what’s hot, whether it’s a national storm, Covid 19 related travel issues, or broken glasses due to face masks.

While the chatbot with the AI technology only gets smarter when more and more answers and content are added, the AI trainers are also working hard on developing the bot’s unique personality to be able to handle both sensitive topics, standard questions as well as customers who are about to explode in anger. Bringing value to the customer is always essential.

Our conclusion so far is that with the mix of courage, our girl power development scrum team (an all- female team for which I was the Scrum Master) and experimenting with agile methodologies inside the sprints have a scalable product that will enable us to give the best customer experience while exploring our further journey into conversational AI.

(*) DevOpsCust: = Development – Operations – Customers

Keywords:   Continuous Delivery, Modelling and understanding customer value, experimentation, MVP, conversational AI, DevOpsCust, time-to-market

How Agile Can Make a Difference for Climate Action and Sustainability.

Jutta Eckstein (IT communication) and Steve Holyer (Engage Results / Steve Holyer and Associates).

Abstract. This is an emergency! None of our agile experiences will matter at all if we can’t change the course of climate change.

More and more people think about sustainability and their personal responsibility. For example, people talk about individual efforts which often include using less plastic, eating less meat, or reducing the carbon footprint we create by air travel. Beyond this personal focus, we are connecting agile practice and mindset to sustainability in our work. This includes a focus on sustainability in agile product development.

In this report, we will share our experience using Agile to make a difference in the sustainability sector—that’s Sustainability by Agile. We, like many others, feel overwhelmed to confront a problem as wickedly complex as the climate crisis. However, we’ll show agile practitioners have many skills and methods at our fingertips that we can use to make a real difference.

Keywords:   Adaptive Action, Climate Change, Complex Adaptive Systems, Continuous Improvement, Sustainability

Towards a sustainable remote-first team environment: one pairing session at a time.

Igor Formiga (RIDE Capital), Yuri Do Nascimento Farias da Silva (RIDE Capital), Oleksii Fedorov (RIDE Capital), Marco Mondini (RIDE Capital), Francisco Briceno (RIDE Capital) and Yigit Tanriverdi (RIDE Capital).

Abstract. Not just “working on the same code”. Pair programming is the core activity in the engineering team at RIDE, though talking about the single pairing sessions, while the world experienced hands-on the need of remote collaboration, could sound a bit diminishing. Developers jumping on and off calls, missed meeting notifications, and virtual colleagues. In this report, we are going to focus on how we are embracing the core values of XP and applying them in a remote-first environment for intra-/inter-team collaboration. We will go through the main team composition changes and how we persevere  on our core team values, challenging the team to enhance and embrace XP practises. We see the value in sharing our own main challenges and the lessons we learned while developing in a fast-paced environment, under business pressure with a focus on scaling the team and product without sacrificing values, quality, and happiness. Furthermore, we hope this report could be useful to inspire other software engineering teams and academics as a starting point for a handbook on how to scale remote engineering teams using XP. For this we discuss the benefits of remote pairing sessions, and then we provide a list of team patterns and personas antipatterns collected along our journey, while comparing classical pair-programming benefits – e.g. knowledge sharing – to specific advantages rising from applying the practice in a remote environment, like fostered informal communication, feeling of belonging, and transparency.

Keywords:   pair-programming, tdd, xp, extreme programming values, remote-first, sustainable pairing, sustainable software engineering, happy developers, remote collaboration

Agile from the Frontlines: Overcoming Inertia in the Federal Government.

Ankur Saini (U.S. Department of Transportation) and Colleen McGann (General Services Administration).

Abstract. Agile Transformation initiatives need not originate at the senior management level. By examining the successes and failures along the journey of a mission-critical system for the United States Federal Government, GSA Real Estate Exchange (G-REX), this experience report discusses how the business and IT established a true partnership to effect organizational change from the grassroots level. Developed in 2014 to replace a legacy system, G-REX serves as the system of record for the procurement of leases in the federal government and supports a real estate portfolio valued at approximately $2.7 billion in annual rent billing through 77 million rentable square feet across 8,000 leased assets. Approximately 2500 leasing practitioners, ranging from novice to expert, who are geographically dispersed across the continental United States, rely on the application to accomplish their duties on a daily basis. At the time of this experience, G-REX was a system that was functional but did not resonate with the user group and was viewed as an impediment rather than an effective tool given the business process misalignment and technology challenges that plagued the system. The silver-lining is that we, collectively as an organization, learned from our failures and implemented a customer-centric approach to deliver transformational results. We demonstrate the importance of creating a culture of transparency, experimentation and trust towards achieving organizational agility, especially in highly structured and bureaucratic organizations, and provide insights that other organizations may use to jumpstart their agile transformation initiatives.

Keywords:   Trust, Experimentation, Partnership, Transformation, Modernization

The Unpredictable Bean Counters.

Benjamin Laffel Strandesen Hooge (Ørsted A/S).

Abstract. Once upon a time in an Agile Release Train (ART) not that far away really, the so-called “Bean Counters” were chucking away on their ever-growing backlog. Having done this for more than 3 years they had built a solid planning habit.

Once a quarter they would plan for the next quarter – in SAFe terms this would be the Program Increment (PI). However, prior to this magnificent planning session they would spend several days breaking down work items into very granular slices of work that could be assigned to individuals. This “breaking down”-ritual was followed by the classic “let’s estimate”-ritual, where they would be estimating the upcoming work in – what was perceived – high precision in the well-known format; the infamous story point, where 1 story point would be equal to 1 day’s work.

Finally, when planning was due, based on their capacity for the coming PI, they would create the plan – detailed and filled near maximum capacity. Aiming for 100% utilization – Perfect!

While this worked flawlessly from a pure process perspective, reality was they didn’t manage to hit the target or deliver according to the plan. Estimates were unfortunately, yet expected, way off. The plan got changed almost immediately after PI planning and at the end of a PI roughly 60% of what had been planned and committed got delivered.

Interestingly enough, the Bean Counters had been able to plan and execute in this particular way consistently for multiple consecutive PI’s. Very little variation could be measured or observed.

Then one day an agile coach ventured into this ART and said the powerful words: “Your plans are bad, your estimates are bad, and you should feel bad too!” And so they begged, “Please teach us” and everyone lived happily ever after.

Right, that’s not how it happened. Not even close.

Keywords:   Predictability, Yesterday’s Weather, Planning fallacy

User Experience Design – a true part of SAFe or a patch?

Helle Lønroth (Demant) and Teresa Bartoszewicz (Demant).

Abstract. This experience was derived during our transformation to Scaled Agile Framework (SAFe) in Demant, starting January 2021 and ongoing.

While implementing SAFe in our Software organization we decided to use a “by the book” approach to SAFe implementation but experienced challenges on how to best infuse Human Centered Design practices. SAFe cames late to the User Experience party and doesn’t offer much guidance.

In this report we will share our experiences and sum up what we did wrong and learned about building high performing Design teams under the SAFe umbrella.

Key topics we cover are:

  • Is the Design/Research competence a true part of the Agile Teams or ART-level shared service?
  • How to ensure that working in “different times zones” (discovery vs development) is doable?
  • How to run the proper exploration phase and how to stay agile at the same time?
  • What is the role of UX managers in Agile transformation?

Keywords:   Agile teams setup, Collaboration between different competences, Dual Agile track, Empowerment of teams, Customer centricity in SAFe, UX Runway, Lean UX

The art of ART redesign.

Bo Malling Christensen (Ørsted).

Abstract. Upon going from an ART as an organizational structure to an ART as a means for execution, I found out first-hand how something as simple as a first draft can mess up the entire perception of an otherwise well-intentioned redesign.

Keywords:   Scaled, Self-organizing, Design Principles

What we learned from descaling 25 Scrum teams.

Martin Schwalbe Lohmann (Alm Brand) and Jørgen Krabbe (Alm Brand).

Abstract. What happens when you descale? We learned that some additional roles and events are needed to address cross-team and cross-organizational alignment and prioritization, when our organization went from a ‘Spotify-model’ inspired setup to a descaled setup with 25 stand-alone autonomous Scrum teams. We have found these new roles and events to be effective and flexible in serving our needs, that is to handle constantly changing dependencies between our 25 teams. However, based on our experience with descaling, we would still recommend adopting a more formal scaling model when a group of teams needs to coordinate closely for an extended period.

Keywords:   Descaling, Agile transformation, cross team coordination

The Art of Splitting an ART.

Christian Eske Bruun (Ikano Bank), Jessica Fraser-Darling (Ikano Bank) and Sven Carlstedt (Ikano Bank / Meqify).

Abstract. When organisations use the Scaled Agile Framework® they may come to the point where their Agile (ART) Release Trains have grown too big. This report is about our journey of splitting an ART using ideas from Team Topologies and the principle of self-selection.

Keywords:   Splitting an Agile Release Train (ART), Using Team Topologies to form teams, Self-selection, SAFe, Agile transformation

Uncover the unknown with Gemba Troika Consulting.

Maryanne Kmit (SimCorp), Bo Bjerregaard (SimCorp) and Jakob Schmidt Sørensen (tryZone).

Abstract. Knowledge sharing in large groups of Scrum Masters is a challenge. Prior to the Covid-19 outbreak it was an issue in SimCorp, and the pandemic did not improve this situation at all.  All collaboration happened online, and the challenge for SimCorp’s 40 Scrum masters grew. The authors, internal Scrum Masters and an external Agile Coach, came up with a series of experiments to enable Scrum Masters to learn from and inspire each other across physical borders and functional areas. By combining known techniques from the Liberating Structure Troika Consulting and the Gemba Walk, triads of Scrum Masters would collaborate closely, gather experiences and consult using a lightweight, simple-to-follow framework.

Focusing on three events, Sprint Planning, Daily Scrum and Refinement, the triads visited each other’s events as a Gemba Walk, and subsequently gave constructive feedback using Troika Consulting.

“Gemba Troika Consulting” enabled Scrum Masters to overcome their reluctance to share positive and negative experiences. What is more, it increased participants’ awareness of unknown unknowns, of different views on similar challenges, and gave opportunities to share and align both success stories and failures in small autonomous groups of peers across the 700 person Product Division.

Keywords:   Scrum, Agile coaching, Gemba Walk

Professionalising the Scrum Master role.

Jan B. Olsen (Jan B. Olsen Consulting / Better Change) and Heine Alsaker (Grundfos).

Abstract. The Transformation Office at Grundfos has set out to professionalise the Scrum Master role and competency development and will, in this session, share lessons learned and challenges encountered doing so.

Why is this important for you?

In order for Agile to work to its fullest potential, Scrum Masters need to have the necessary competencies to support and challenge the organisation. Still, this is not enough, as the Scrum Masters’ focus needs to be based on the organisational maturity of the organisation to achieve maximum results. Misalignment between the two will keep the organisation dead-in-the-water, and self-orientated Scrum Masters will be seen as less valuable.

What you learn:

In the session, you will learn how to effectively align Scrum Master’s purpose and competency development with the organisational maturity, which will enable you to communicate the focused effort to the organisation. You will also learn the importance of building a strong community of practise within the Scrum Masters, to ensure continuous learning of Agile and Lean practices as well as various Scrum Master stances.

About the authors/speakers:

Jan B. Olsen has experience with strategic and operational consultancy within complex and challenging organisations. The later engagements have been with Danske Bank’s reorganisation of its development organisation. Now supporting Grundfos’ ambition to become more innovative, customer-centric, and a great place to work.

Heine Alsaker has a background as a (Software) project manager and experience as an Agile team coach in mechanical production organisations. In these organisations, he has held different Scrum and SAFe related roles. He is currently holding an Agile Coach role supporting Grundfos’ Agile journey.

Keywords:   Scrum Master, Competencies, Maturity

Architecting a Globally Distributed Software Development Organization for Continual Development.

Anastas Stoyanovsky (Kiavi).

Abstract. As an agile development project grows and distributes over different places and timezones, communication overhead increases. If its communication systems are not carefully designed, friction and miscommunication can cripple it to the point of being less effective than a single team working alone. Well-synchronized distributed development can derive benefits such as working hour continuity, diverse skill sets, and varied perspectives. On the other hand, with significantly differing timezones, architectural decisions often need to be made without being able to include all stakeholders or even core developers, and often without including those most experienced with a particular subsystem or component.

This report describes a case study of a working global development model at IBM Watson that was founded for a greenfield project and grew to span seven sites throughout both hemispheres.

Keywords:   global development, software architecture, communication systems, international development, remote software development

Agile product delivery in the pandemic’s remote work environment.

Vijay Iyer (ThoughtWorks Inc.).

Abstract. Introduction –

In early 2021, Thoughtworks was engaged by one of our financial services clients for a complete revamp of their partner rewards program.  The client provides a cloud based financial services platform with a variety of applications for the financial operations of all types of small and medium businesses.

By referring these applications at a discounted price, the client’s partners could earn commissions, discounts and priority service, which in turn helped them sell more.

In the last few years, the referral sales had been stagnating, leading the client to question the effectiveness of the current partner rewards program.  The goal of the engagement was to understand the shortcomings of the current program, and together build a new revitalised program that would restore the partners’ confidence again.

Our approach –

Thoughtworks heavily leverages on the lean startup principles in our agile product development engagements to ensure that the client gets the most valuable product for the money spent.   We follow the build-measure-learn loop, where we co-create small increments of the product with our client, measure the business value delivered against our original hypothesis and then plan the next increment based on our learnings.

This approach requires a great level of collaboration both with the client as well as end customers, which during normal times, is achieved by co-located delivery.  The pandemic however brought with it a unique set of challenges.

Challenges –

The pandemic introduced some significant challenges in how we would staff and execute such an engagement:

  1. The product discovery which forms the foundation of the product delivery journey is best executed in a co-located setting. Identifing the key pain points and drivers for the business, and building the hypotheses to address them, requires a lot of face time, white boarding and discussions together.
  2. The pandemic has made remote working the norm, therefore from a commercial perspective, it was very difficult to convince the client to pay much higher rates for some team members to be physically located in their home country.
  3. Lack of local resources made the learning curve for some of the business context much steeper.
  4. User research for the proposed product hypotheses required focus group sessions and 1 on 1 meetings, with a user group that is not very tech savvy.
  5. Measurement of delivered value after each release had to be more swift, and any changes had to be implemented quickly to match up to competition.

How we overcame these challenges –

As part of the experience report, I’d like to talk with examples about how our team overcame these challenges. We heavily leveraged several virtual collaboration, experience design and user research tools, but also had to improvise to fill the gaps.

Learnings –

Below are some of my key learnings from this experience:

  1. When co-location is not possible, a lot more preparation is needed to make virtual collaboration just as effective.
  2. There are a lot of virtual tools out there and it is easy to quickly get overwhelmed. As a team, we need to identify the leanest set to help us meet our collaboration goals.
  3. While the execution might have changed, the underlying principles of Agile product development still hold water and are highly effective.
  4. Despite our best efforts, remote working can never be successful without the continued and patient support of our clients in adapting to the new normal.

Who this would be useful for –

Given that the pandemic has fundamentally changed the way we work and collaborate, the learnings in this experience report would be useful for any squad trying to navigate from a co-located work environment to team that is completely remote.

Keywords:   Lean, Agile product development, Hypothesis testing, Remote working, User research, Build-measure-learn

Optimize your organizational structure for agility.

Wolfgang Steffens (kai kaku Oy).

Abstract. This report is based on my experiences across 3 different companies from the insurance and automation industry.

In all of the cases, I was called as an Agile Coach into those organizations after management had decided their organization needs to become “agile”. Prior to the decision, all organizations had conducted a Scrum pilot with 1-2 teams which did not contribute to the main product of the organization. The work they did was somewhat isolated and so the one-team Scrum approach was well fitted. Those pilots demonstrated improved productivity and even some kind of adaptiveness when it came to responding to changing requirements. Thus, management decided in those cases to move forward and copy-paste Scrum to the entire organization ranging between 120-450 developers. In all cases, management decided critical parts of the organizational structure like team scope, PO-team relationship, and team backlogs.

Each organization decided to establish cross-functional teams either through self-designing team workshops or by management decision. In all of the cases, the teams were not truly cross-functional as critical skills were missing like architectural skills, testing, Ux, domain knowledge, or deployment. Besides having dependencies between all those component teams, the teams did either have dependencies to underlying database and platform organizations, or to the application layer. In the end, they were all variations of component teams either in form of system components or full-stack teams with narrow domain scope, all with significant dependencies to others.

Management assigned one “Product Owner” per team with those “POs” typically being team leads or sub-project managers in the old set-up. Each “PO” was then, as a team lead before, middlemen taking orders, responsible for coordinating the team’s work with other “POs”, spoon-feeding their teams by writing detailed requirements, doing analysis, and talking to the stakeholders. In one of the cases, we had a set-up with 30 teams and 30 “POs” working all on the same platform which was used by several applications. A real Product Owner focuses on the business, is an entrepreneur, and all those team “POs” were far away from that.

In order to prioritize the work of the team, each of the “Team POs” created a team-specific backlog. Typically those backlogs contained every kind of work except real customer-centric Product Backlog Items covering the requirement end-to-end. In order to complete a customer-centric feature, there was a need to coordinate across multiple team backlogs. Besides the significant coordination effort, the results were that the teams only knew their own very limited area. This silo knowledge hindered the organization to shift direction easily and focus on the highest value items. Instead, teams were kept busy and worked on items of lower value from an organizational point of view. Sometimes, the teams even knew that, and yet they continued to work on low-value items since the organizational structures did not allow them to work on other items.

Those structural elements of team-specific backlogs, “team POs”, the composition of component teams, all together induce a system that is not very adaptive. Changing direction is very hard due to silo knowledge. People are very busy producing output yet less outcome. In this kind of system management adds even more teams, and the productivity goes down even further.

Only in one of the cases, I was able to flip the organization after they had worked several months in the chaotic multi Scrum-team setup. Instead of regarding a single component as the “product” by forming teams around those many narrow products, we defined the one real product from the customer’s point of view. Since there were too many teams to be directed by a single Product Owner, we introduced three customer-centric product areas which were independent of each other. We establish cross-functional, cross-component Feature Teams which could convert a customer-centric PBI into a product increment on their own. Dependencies between teams were minimized and the remaining ones were handled through well-defined APIs. This more modular approach enabled the delivery of well-tested real product increments.

Now the one real Product Owner focused on the long-term and strategic view of the product, and each Area Product Owner focused on her own Product Area, working together with the teams and prioritizing the content of the Area Backlogs. The results were mind-blowing. Besides the boost in morale which was achieved through a self-designing team workshop, in which each person could decide which Product s/he wants to work in, we saw a significantly increased level of collaboration between the teams. Now all the teams were working together to create each Sprint a product increment containing only the highest value items.

In all the cases I have experienced ignorance and lack of knowledge when it comes to the basic understanding of organizational design. Especially critical are managers since they make important decisions on the structures of organizations. None of the managers which I met in those companies had the skill of systems modeling and thus they did not have tools to understand the dynamics in their organization from all the interactions. Instead, managers copy-paste models from other companies, or naively think that copying one-team Scrum to multi Scrum-Team will work. They lack the basic understanding that their environment is complex, that they need to run their own experiments, need to find out through Inspect and Adapt what works in their organization and whatnot.

Keywords:   agility, scaling, scrum, organizational design

Agile Approaches to Policy Development

Håkan Burden (RISE Research Institutes of Sweden) and Susanne Stenberg (RISE Research Institutes of Sweden). .

Abstract. We desrcibe how we have applied agile approaches to explore stakeholder value in relation to EU’s forthcoming AI Act. While this is not the first time agile approaches have been used outside of software engineering, we think our contribution can showcase how a discipline such as policy development within international legislation can be complemented by a more agile mindset to facilitate various stakeholders to understand the impact on their agency.

Keywords:   EU regulation, Kanban, Stakeholder collaboration, XFT

Journal First

Satisfaction and its Correlates in Agile Software Development.

Martin Kropp (University of Applied Sciences and Arts Northwestern Switzerland), Andreas Meier (Zurich University of Applied Sciences), Craig Anslow (Victoria University of Wellington) and Robert Biddle (Carleton University).

Abstract. In this paper we address the topic of software development team members satisfaction with their development

process. We present an in-depth analysis of the results of a nationwide survey about software development in Switzerland. We wanted to find out if satisfaction relates to the applied

development method, and to the use of various practices, and impacts on business, team and software issues.

Keywords:   Software Development, Agile, Satisfaction, Correlation, Agile Practices

Architecture Evaluation in Continuous Development.

Magnus Ågren (Chalmers | University of Gothenburg), Eric Knauss (Chalmers | University of Gothenburg), Rogardt Heldal (Western Norway University of Applied Sciences), Patrizio Pelliccione (Gran Sasso Science Institute (GSSI)), Anders Alminger (Volvo Car Group), Magnus Antonsson (GE Additive), Thomas Karlkvist (Collaboration Maturity ON AB) and Anders Lindeborg (Malama AB).

Abstract. Context: In automotive, stage-gate processes have previously been the norm, with architecture created mainly during an early phase and then used to guide subsequent development phases. Current iterative and Agile development methods, where the implementation evolves continuously, changes the role of architecture.

Objective: We investigate how architecture evaluation can provide useful feedback during development of continuously evolving systems.

Method: Starting from the Architecture Tradeoff Analysis Method (ATAM), we performed architecture evaluation, both in a national research project led by an automotive Original Equipment Manufacturer (OEM), and at the OEM, in the context of continuous development. This allows us to include the experience of several architects from different organizations over several years.

Using data produced during the evaluations we perform a post-hoc analysis to derive initial findings. We then validate and refine these findings through a series of focus groups with architects and industry experts.

Findings: We propose principles of continuous evaluation and evolution of architecture, and based on these discuss a roadmap for future research.

Conclusion: In iterative development settings, the needs are different from what typical architecture evaluation methods provide. Our principles show the importance of dedicated feedback-loops for continuous evolution of systems and their architecture.

Keywords:   Architecture Evaluation, Continuous Software Engineering, Automotive Systems, Iterative Development

Leadership and Agile: Are You ‘In Control’?

Niels Loader (Quint).

Abstract. Leaders of organizations using lean-agile ways of working on the work floor need to adopt a new way of leading the organization. In this paper, I present a complete and reframed leadership system that allows leaders to gain a different form of being ‘in control’; a form that is compatible with a lean-agile way of working. I also describe experiences and lessons learned while implementing this leadership system
Keywords:   Leadership, Leadership System, Lean-Agile-DevOps environments, ‘In control’

Lightning Talks

Pull the Cord: Project Funding Model is Defective.

Christopher Pola (Rally Software).

Abstract. Pretend for a moment that the Project funding model is a product or service, and the intended customer is the digital knowledge economy. I argue that you would not release it to market because it is riddled with defects.

The company and the modern knowledge worker is stymied by the Project funding model; an organizations potential can be mediocre at best when this funding model is in place. The principles and practices of Lean Budgeting and a Product-centric funding model provide the following benefits:

– increase the internal capacity of the organization

– eliminates waste (overhead + costs) from internal processes around forecasting and tracking costs

– vastly improves decision making velocity at all levels (Portfolio, Program and Team) – critical because at it’s heart knowledge work is all about decision making

Product-centric funding is ‘the’ gateway to fostering and sustaining real agile pracitces, behaviors and culture; thus an enabler to better work environments, and measurable product outcomes for customers. What could be a better prerogative?

Keywords:   Product Funding Model, Traditional Cost Accounting, Lean Budgeting, Product-centric funding, Knolwedge Work, Lean Management Practices, Empowered Teams, Decentralized Decision Making, Eliminating Waste, Agile Accounting

Fostering company values

Ioannis Totlis

Abstract. How can company values be instilled in an organization? A hands-on approach to fostering company values and why it is important.

Keywords:   company values, values

#no fixed length.

David Müßig (alcemy GmbH).

Abstract. Have you ever faced the situation that you didn’t reach your goal at the end of your iteration so you took over parts of it to the next one? Or that your goal was reached half way through the iteration and you filled the remaining time with “some small stuff” from your bucket list (that was actually not soooo important)?

We faced this situation quite often, honestly speaking, reaching our goal close to the end of an iteration was rather an edge-case than the normal. And this was not only a strange feeling – it was frustrating.

First we tried to get better in setting our goals (which lead to meaningless goals). Then we approached it from the other side – we dropped the notion of a “fixed length” iteration. We set our (meaningful!) goal and worked on it until it was reached. Then we set the next goal, worked, repeated. And guess what: this was an eye opening experience. Motivation got up, cycle- & feedback time went down and the overall team happiness got up. The time we spent for negotiating what to put into an iteration, the tiptoeing around the end of an iteration – all this was gone! We faced some other issues – e.g. we couldn’t use fixed timeslots for planning meetings anymore or we set too small goals – but all of this could be handled kinda easily and the benefits we gained were just great!

Keywords:   tools and processes, coaching teams, team work, back to agile

Diversity is more than a buzzword; it boosts your products value!

Nils Hyoma (Novatec Consulting GmbH) and Kira Naehring (Novatec Consulting GmbH).

Abstract. Agility is suitable for solving complex problems. The complexity can root in missed or unknown requirements at the start of the project. Diversity can help teams to create better software. On the one hand, diversity can be more technical, like specialist knowledge in cross-functional teams. On the other hand, background diversity (like migration background, gender, age, or disabilities) can be helpful for agile teams to create more valuable and sustainable products.

Kira Naehring and Nils Hyoma will present in their lightning talk examples where missing background diversity led to some problems in products, even within some of the leading and biggest companies. Furthermore, both will give an overview of how to include background diversity in your project

Keywords:   Diversity, Background Diversity, Agility, Sustainable Value, Real-life examples

Pondering Quotes from Alice in Wonderland.

Poulomi Nath (Tata Consultancy Services).

Abstract. We all know that quotes and metaphors play an important role in coaching and training in an Agile and Transformational realm.

So picked up a children’s book and got you some quotes which is aimed at inspiring participants to get into deeper conversations around how we can empower and enable people through various techniques of involving them in knowledge sharing sessions. The target is to enhance the understanding true potential of agile delivery methods through fond childhood memories.

“And what is the use of a book,” thought Alice, “without pictures or conversations?”

Target Audience : Agile Enthusiasts/Coaches/Trainers/SMs/POs

Keywords:   Quotes from children book, Aligning fond childhood memories, Alice in wonderland

Responsibility-Based Planning and Control; it’s a magic bullet for cultivating agile behavior.

Christopher Pola (Rally Software).

Abstract. Can an agile process eliminate waste, be a solution to employee burnout, reverse the gender gap situation, and be a portal to cultivating true agile practices and behaviors?

If you scale agile and manage teams via traditional project management processes, then you are creating an operational conundrum. This talk will showcase the simple practices of Responsibility-Based Planning and Control, and the holistic benefits it provides to unleash our human potential. Improve productivity, innovation, speed and quality by adopting leaner and purpose-built practices for software development.

Keywords:   Lean Portfolio Management, Intrinsic Motivation, Behaviors, Accountability, Eliminate Waste, Employee Burnout, Talent Management, Agile Practices over Traditional Processes

Helping a Burned-out Team Produce Consistent Results.

Aina Aliieva (Bee Agile Tutoring).

Abstract. In general, all Agile coaching techniques, team mobilization, and change management operate under the assumption that team members are always in normal physical and mental conditions. Even if this were the case,  it’s well-known that introducing any kind of change is challenging, and people tend to be resistant to change or any departure from what has been done previously. Therefore, working on a project that encourages a new way of doing things inherently brings about less-than-ideal conditions for the team.

During the pandemic — lasting more than two years already — each of us has faced burn-out at least once. People might not take vacation days because they will likely spend that time at home anyway if travelling wasn’t an option. And even if they do take time off, they may still show up at work because it’s less boring than figuring out other ways to spend their time.

These days, when team members return from time off, their managers and colleagues expect them to be revitalized and energetic after being out of the office, yet they remain burned out. Others may not take vacations because they are afraid of being laid-off, as they have seen with other organizations, departments, and colleagues during the pandemic.

So, what happens if the team you plan to transform is already exhausted or burned out? How should you introduce changes when people can barely follow the old, established processes and barely manage to remain in their comfort zones? In this state, people cannot hear and follow new ideas and are resistant to everything, even if these changes significantly improve their lives. General Agile coaching and facilitation techniques will not work with such teams or even make things worse. Therefore, there is a need to develop a unique set of actions, behavior, facilitation techniques tailored to work with tired and non-motivated people.

In this lightning talk let’s discuss and outline the specific techniques, games, tools, psychological aspects, and behavior to help mentally and physically drained teams to maintain positive results.

Keywords:   Burn out, Teams, Team results, Productivity, team productivity, coaching

Learning Agility under Nature’s Mentorship.

Jui Kudav (cognizant technology solutions).

Abstract. In the Agile way of working we most of the time look at organizations, human leaders and teams for inspiration and mentoring. While this is really useful, We also need to understand that We’re awake now, and the question is how do we stay awake to the living world?  How do we make the act of asking nature’s advice a normal part of everyday improving inventing?”

In this talk lets explore how we can learn from Nature who has experienced the VUCA world for more than 3.8 Billion years

This Session is where I bring my passion as a nature observer to learn some fascinating aspects and outcomes of Agility under Nature’s mentorship . It includes an observation and reflection of different acts of nature including the flora and fauna and learn from them on

  • Leadership lessons,
  • Team Sustenance
  • Transformation journeys
  • Product innovation through Biomimicry

Keywords:   Nature Agility, Nature Mentorship, Biomimicry

The dark side of agile implementation.

Lisette Zounon (Zsquare Solutions Inc).

Abstract. We all have heard about the great agile transformation journey but the story is not always rosy. Agile transformation is hard, dreadful, and impactful on the agile coach or change agents especially when the culture of the organization or leadership is not ready for it.

In this talk, I will share a personal story of the dark side of agile transformation and how I end up in the ER as a result. Yes ER because there was a breakdown in the system, system failure that impacts my personal system and health and team success as well.

Attendees in this session will take away :

– How you can detect early warning signs of a dark agile in your organization

– Understand the anti-patterns of agile and learn to overcome them early

– Practical examples of how to take care of your most valuable asset -the people.

Keywords:   Agile, practices, Anti-patterns

The power of self-management

Pedro Cruz (Objective)

Abstract. A team with no autonomy is a team crystallized, with no movement, is a team that can’t adapt or make decisions based on their knowledge. The more autonomy the team conquers, the more adaptation, decisions and improvement they get. To become fully autonomous is to become self-managed and really experiments with empowerment.

From the psychologist Piaget we learned that the highest stage of human development is an autonomous stage. Connecting his theory with Vygotsky defends the impact of the environment on the individual’s evolution, so the best way to improve autonomy is to evolve the environment and the individual in cycles of practices of autonomy to then reach a stage of self-management.

The use of agile methods, such as Scrum, Kanban and XP are excellent ways to improve autonomy, but the introduction of it’s practices must consider the level of autonomy the environment provides to the team and the team’s capacity to correspond to the autonomous stage needed. Trying a practice with a much higher level of autonomy may slow the team’s evolution, choosing the right practice based on a certain amount of improvement needed, creates a sense of evolution that motivates and makes the improvement happen by steps.

Keywords:   Self-management, Autonomy, Empowerment

 Agile Renaissance: OKRs not Roadmaps.

Christopher Pola (Rally Software).

Abstract. OKRs bring radial focus, alignment and engagement; done properly they are a catalyst for creativity and ambitious plans for a product mission/vision/strategy. Using OKRs we can really change the game in regards to applying lean practices around backlog management; eliminating waste and customer innovation.

The Product Roadmap metaphor is something I have never fully grasp. For example, a Roadmap can only exist if the roads are already built or completely surveyed, yet often neither is the case in Product Development. Also, the estimated travel time on those existing roads depends on known assumptions, which is a luxury in Product Development. Maybe the concept of Roadmaps is wrong or needs to be enhanced so we can revive and surpass our ideas, and human achievements around on what it means to truly be agile.

Keywords:   Objectives Key Results, Product Roadmaps, Innovation, Creativity, Human Potential, Product Goals, Backlog Management, Lean Management, Lean Product Development

Diversity and Inclusion in Agile

Embedding DEI in Our Agile Organization at SimCorp: An Intersectional Approach

Elizabeth Christensen (SimCorp), Marianne Garre Fink (SimCorp) and Ender Yüksel (SimCorp).

Abstract. In this presentation, we take an intersectional approach to examine existing practices in our organization through a diversity, equity, and inclusion (DEI) lens. We will introduce our context—Product Development (PD) at SimCorp to explore and understand how agile ways of working promote both intersectionality and DEI. Our approach combines insights from practitioners in both PD and Human Resources to understand and promote existing best practices within business processes. Specifically, we examine equity in recruitment, diversity in team composition, and inclusion in ways of working. We finalize our presentation by opening up for participant discussion on how our current realities will impact DEI and the future of agile.

Keywords:   intersectionality, diversity, inclusion, equity, recruitment, team composition, agile ways of working, future of work

Unity in Diversity – Some Reflections of a Scrum Master.

Patrick Korchmar (Agile Ants GmbH).

Abstract. The presentation “Unity in Diversity – Some Reflections of a Scrum Master” will illustrate how and why the Scrum framework is particularly suited for dealing with a heterogeneous workforce. From an interdisciplinary perspective (sociology, economics, cultural studies such as anthropology o. intercultural communication, etc.), the origins and nature of the increasing diversity are described. From this, an understanding for the specific problems of diverse teams is developed, which is often missing in the Scrum community: In our fast-moving and non-committal times, how do we establish a common social framework that does not suppress the diversity and uniqueness of its members? The lecture presents two cultural techniques that contribute to mitigating this problem and thus to unleashing the innovative potential of diverse teams: (a) The Processing of Injuries; (b) The Verbalization of the Culturally Unconscious.

Keywords:   1. Diversity, 2. Diversity competence, 3. Scrum, 4. Social and Emotional Skills, 5. Globalization, 6. Digitalization, 7. Beginner Friendly

Research Papers

Benefits of Card Walls in Agile Software Development: A Systematic Literature Review.

Marc Sallin and Martin Kropp.

Abstract. Card walls are often used to visualize various aspects of the software development process. They are an essential and widespread agile practice. Despite the drawback of physical card walls, its digital version is often not considered a sufficient alternative. This paper aims to find the reason for this and suggests how to evolve digital card walls into a viable alternative. We conducted a systematic literature review and analyzed twenty-two studies. We identified which desirable effects agile teams get from card wall usage and derived a set of properties a card wall needs to achieve those effects. Furthermore, we suggested a typology of card walls to compare the benefits and challenges among them.

MoSCoW Rules: A quantitative exposé.

Eduardo Miranda.

Abstract. This article analyzes the performance of the MoSCoW method to deliver all features in each of its categories: Must Have, Should Have and Could Have using Monte Carlo simulation. The analysis shows that under MoSCoW rules, a team ought to be able to deliver all Must Have features for underestimations of up to 100% with very high probability. The conclusions reached are important for developers as well as for project sponsors to know how much faith to put on any commitments made.

Are Your Online Agile Retrospectives Psychologically Safe? the Usage of Online Tools.

Dron Khanna and Xiaofeng Wang.

Abstract. One essential prerequisite for successful agile retrospective sessions is to accomplish a psychologically safe environment. Creating a psychologically safe environment for the co-located team is challenging. Further, it becomes more demanding with online agile retrospective teams. Literature sheds little light on creating a psychologically safe online environment for conducting agile retrospectives. Our study aims at addressing this knowledge gap and asks the research question: how does the usage of online tools influence psychological safety in online agile retrospectives? A single case study was conducted with a major software company’s Research and Development team. We analysed a recorded online retrospective session of the team to identify patterns of the usage of online tools associated with the online meeting platform they used and how that usage influenced the psychological safety level of the team. Our findings show that retrospective participants are psychologically safe if they share opinions, make mistakes, raise a problem, ask questions, and show consent using online tools. Our study contributes online tools that influence psychological safety factors, corresponding levels and behaviours.

Coordination Strategies Enabling Work from Anywhere: A Case Study of two Agile Teams.

Tor Sporsem and Nils Brede Moe.

Abstract. Effective coordination is the key to successful agile teams. They rely on frequent interactions and mutual adjustment to manage dependencies between activities, which traditionally has been solved by co-locating the team. As the world is adjusting to post-covid work-life, companies are moving towards a work-from-anywhere approach where workers can choose to what degree they want to work from home or office. However, little is known about coordination in such a context. We report findings on developers’ emerging strategies when working-from-anywhere, from an exploratory case study in Norway, including eight interviews. Our study shows that new strategies for mutual adjustment emerged as teams experimented with different tools and approaches: developers chose tasks according to location, tasks with vague requirements are performed collocated while individual tasks requiring focus are best performed at home; large meetings are virtual, preserving co-located time for collaborative tasks; using virtual rooms to maintain unscheduled meetings as they communicate mental presence to teammates, lowering the threshold for intra-team unscheduled talks. The strategies can help organizations create a productive and effective environment for developers.

Roles of Middle Managers in Agile Project Governance.

Maduka Uwadi, Peggy Gregory, Ian Allison and Helen Sharp.

Abstract. Project governance is an important activity in agile software development (ASD) projects for project success. Middle managers are part of the governance structure in ASD projects. Despite the efficacy of project governance and existence of middle managers in agile teams, project governance and middle management in ASD projects are under-researched. This multiple-case study investigates the roles of middle managers in agile project governance activities within two Nigerian ASD projects through the lens of activity theory. We collected data in semi-structured interviews, observations, questionnaires, and company documents. Our findings show that middle managers performed 25 roles related to planning and coordination for project alignment and execution, continuous improvement and organisational change, agile and technical leadership, monitoring, and capability building. We conclude that middle managers are pivotal to project governance practice and the effectual functioning of agile teams in ASD projects. The study will help agile practitioners to better understand the roles of middle managers in agile project governance. Results from this work contribute to the ‘middle management in agile’ debate and offer an alternative view that may change beliefs about middle managers in agile project settings.

Building a Toolbox for Working with Psychological Safety in Agile Software Teams.

Mikkel Agerlin Christensen and Paolo Tell.

Abstract. This paper presents the design of eight tools for working with psychological safety in agile software teams, which were designed in collaboration with industry practitioners using design science.

The tools were adopted over a two-week period by four Danish industry software teams and evaluated through team interviews and surveys.

Results show that the designed tools can be successfully adopted and integrated in the practices of a software team.

Participating teams found the tool format valuable, as it allowed them

(i) to engage in discussions they were not always capable of having,

(ii) to find the right shared vocabulary to frame these discussions, and

(iii) to provide them with needed prompts to let such discussion surface.

Finally, teams unanimously reported interest in the continued use of the designed tools.

Understanding Leadership in Agile Software Development Teams: Who and How?

Johann Weichbrodt, Martin Kropp, Robert Biddle, Peggy Gregory, Craig Anslow, Ursina Maria Bühler, Magdalena Mateescu and Andreas Meier.

Abstract. The principles in the Agile Manifesto, the Scrum Guide and most other approaches to agile software development emphasize self-organizing teams, but rarely address issues of leadership. In this paper we report on a study of the nature of different aspects of leadership in agile teams. We used an established model of leadership, distinguishing transactional and transformational styles, and asked IT professionals a set of questions about the leadership they experience, both from direct supervisors (hierarchical leadership) and from the team itself (shared leadership). We determined correlation measures of these four types of leadership with the extent of agility in the whole organization. Our results show that agility is indeed related to the transformational style, but that the transactional style also plays a part, especially as shared leadership. Furthermore, even in highly agile software development, leadership by direct supervisors still plays an important role. We propose that, as software development becomes more agile, the transactional aspects of leadership may shift away from the leadership dyad between supervisor and employee into the agile team, while transformational leadership is important for both the team and supervisors. We discuss our results in light of applications for both research and practice.

A case for data-driven Agile transformations: Can longitudinal backlog data help to monitor and guide improvement journeys?

Gijsbert Boon and Christoph Johann Stettina.

Abstract. Context: Almost every organization with a strong digital capability has embarked on an agile transformation journey. But do these changes actually deliver on the envisioned transformation goals? What conclusions can we draw from measurements and observations?

Objective: The ambition of this report is to (1) assess whether tooling data can be used to guide a transformation towards improved organizational performance; (2) verify claimed benefits of agile transformations using tooling data in the presented case study.

Method: We measure productivity, time-to-market, and quality as transformation objectives by analyzing longitudinal Jira backlog tooling data within an embedded multiple-unit case study.

Results: By analyzing over 57,000 Jira issues from eight agile release trains over a period of three years, we (1) provide a proof of concept of how tooling data can be used to guide agile transformations; (2) provide empirical evidence on the assessment of transformation objectives over time and organizational layers at FinOrg; and (3) connect measurement results with available literature.

Conclusions: We may conclude that tooling data is a viable addition to guide transformations through identification of improvement opportunities on the set objectives. We connected the case study results to existing literature and identified similarities. We argue that there is a need for a measurement framework and better understanding of the dynamics between measurement and performance.

Work Engagement in Agile Teams: The Missing Link between Team Autonomy, Trust and Performance?

Marte Pettersen Buvik and Anastasiia Tkalich.

Abstract. To have engaged and high-performing agile teams are what most organizations strive for. At the same time, there is little research on the drivers of team work engagement in the software context. Team autonomy and trust are crucial for agile teams and are suggested as potential boosters of team work engagement and performance. In this study, we apply the Job Demands-Resources model to examine the role of autonomy and trust and their impact on work engagement and team performance in agile teams. We analyze quantitative survey data from 236 team members in 43 agile teams to examine how team autonomy and trust relate to team work engagement and how engagement mediates the relationship between these factors and performance. Our results show that while both autonomy and trust are positively related to team work engagement, team trust plays a more critical role than team autonomy. Teams with high team trust showed higher engagement, which enhanced team performance. Our results highlight the importance of social factors such as trust in creating conditions for high performance in agile teams through its effect on team work engagement.

Design and Validation of a Capability Measurement Instrument for DevOps Teams.

Olivia Plant, Jos Van Hillegersberg and Adina Aldea.

Abstract. This paper reports on the design and validation of a capability measurement instrument for software delivery teams that make use of the DevOps approach. The instrument is based on the results of a systematic literature review and was developed and validated by involving a total of five domain experts and conducting a field study among six DevOps team members. To this end, we used qualitative and survey-based data collection methods from participatory action research as well as design science. The resulting instrument encompasses five dimensions, covering seventeen capabilities and thirty-eight associated practices. The practices are evaluated on five capability levels. The results of the validation process indicate clear agreement of the domain experts and team members with all aspects of the instrument. As a contribution to practice, this research offers a pragmatic tool for IS practitioners which provides insight into the status of their DevOps transformation and offers directions for improving DevOps team performance. Furthermore, this research contributes to the ongoing research stream on DevOps by providing novel insights into the nature of DevOps capabilities and their potential configurations.

Towards an Agile Product Management: What do Product Managers do in Agile Companies?

Anastasiia Tkalich, Rasmus Ulfsnes and Nils Brede Moe.

Abstract. The product manager (PM) role is well established in leading technological companies, such as Google, Amazon, Microsoft, and Facebook. PMs are responsible for integrating technical, design, and business perspectives when developing software products and product portfolios. In agile methods (e.g., Scrum), similar responsibilities are linked to the Product Owner (PO) role. In contrast, in large-scale agile, one can find both Product Owners and product managers who sometimes compete. Despite the widespread adoption of the product manager role, the attention toward it in the agile academic community has been surprisingly limited. In this multiple case study, we analyzed 17 interviews with 11 product managers from four agile companies. We found that the PMs facilitated continuous product experimentation and innovation, supported the product teams, and engaged in additional activities to achieve optimal product development. Our summary of the product management activities can guide product managers working in agile companies.

A Countrywide Descriptive Survey of Agile Software Development in Brazil.

Rafaela Mantovani Fontana, Jaime Wojciechowski, Razer Rojas Montaño, Sabrina Marczak, Sheila Reihner and Andreia Malucelli

Abstract. For years, industry institutions and academic researchers have been surveying software practitioners on agile software development methods adoption. These surveys have been useful in describing the characteristics, challenges, and impacts of agile adoption, mainly in Europe and North America. Latin American practitioners miss information on the state of agile adoption. This study aims to fill this gap by describing agile software development adoption in Brazil. We collected data from 897 countrywide-distributed practitioners. We used descriptive statistics and machine learning algorithms to understand our dataset. Results show the profile of companies and teams, characteristics of agile usage, perception of success, applied principles and practices, and reasons, challenges and impacts of agile adoption. We also explore the relevance of principles in software process improvements. We contribute by mapping the state-of-the-practice of agile adoption in Brazil and by contrasting our results to previous literature, which points out how we further current knowledge in academia.

Investigating the Current State of Security in Large-Scale Agile Development.

Sascha Nägele, Jan-Philipp Watzelt and Florian Matthes

Abstract. Agile methods have become the established way to successfully handle changing requirements and time-to-market pressure, even in large-scale environments. Simultaneously, security has become an increasingly important concern due to more frequent and impactful incidents, stricter regulations with growing fines, and reputational damages. Despite its importance, research on how to address security in large-scale agile development is scarce. Therefore, this paper provides an empirical investigation on tackling software product security in large-scale agile environments. Based on a literature review and preliminary interviews, we identified four essential categories that impact how to handle security: (i) the structure of the agile program, (ii) security governance, (iii) adaptions of security activities to agile processes, and (iv) tool-support and automation. We conducted semi-structured interviews with nine experts from nine companies in five industries based on these categories. We performed a content-structuring qualitative analysis to reveal recurring patterns of best practices and challenges in those categories and identify differences between organizations. Among the key findings is that the analyzed organizations introduce cross-team security-focused roles collaborating with agile teams and use automation where possible. Moreover, security governance is still driven top-down, which conflicts with team autonomy in agile settings.

Agile data management in NAV: A Case Study.

Kathrine Vestues, Geir Kjetil Hanssen, Marius Mikalsen, Thor Aleksander Buan and Kieran Conboy.

Abstract.To satisfy the need for analytical data in the development of digital services, many organizations use data warehouse, and, more recently, data lake architectures. These architectures have traditionally been accompanied by centralized organizational models, where a single team or department has been responsible for gathering, transforming, and giving access to analytical data. However, such centralized models presuppose stability and are incompatible with agile software development where applications and databases are continuously updated. To achieve more agile forms of data management, some organizations have therefore begun to experiment with distributed data management models such as “data meshes”. Research on this topic is however limited. In this paper, we report findings from a case study of a public sector organization in Norway that has begun the transition from centralized to distributed data management, outlining both the benefits and challenges of a distributed approach.

Agile in Education and Training

Educating Agile Architects: Pouring the Foundation for any Agile Product Success.

Bobby Woods.

Abstract. Product slicing isn’t just about feature refinement! So much attention is payed to Product Teams, Product Roles and their ability to take complex systems and begin slicing them up into iterative stories of value to be delivered in “half the time”. But the roles and Product leadership aren’t actually delivering those products! Its the developers, testers and architects who are tasked with taking a large complex solution and using Agile practices to modularize the effort.Bobby Woods, Enterprise Agile Transformation Consultant with Scrum Inc., will be walking attendees through gaining answers to questions like “What do our developers and architects need to know in slicing complex systems that our Product people might be missing?”, “What technology stack slicing techniques are in use right now that we could apply tomorrow?” and “How do we ensure we are iterative in short term value delivery with feedback but still looking long term for technology outcomes that align to business and customer needs?”

Being Agile in a Data Science Project.

Renato Cordeiro Ferreira, Isaque Alves de Lima, Samara Alvarez Alves and Alfredo Goldman.

Abstract. Applying agile practices in data science requires adaptations. This paper describes challenges and lessons learned in two applied machine learning projects developed in the XP Lab course at University of São Paulo in Brazil. It compiles six suggestions for educators and practitioners who want to bring agility to their data science initiatives.

How to teach agile through a comic strip.

Luxshan Ratnaravi, Mikkel Noe-Nygaard.

Abstract. In March of 2020, we created a comic strip to teach the world about agile—we call it Comic Agilé.

Last year, we published a book with forewords by Kent Beck and Dave Snowden, which dramatically increased the agile community’s knowledge of our concept, leading to our posts on LinkedIn regularly hitting the top 10% of most engaged content among our 30,000+ followers.

We get frequent requests from companies and educators to use our material in their talks and course material, and we’re actively endorsing everyone to use our strips and visualizations for free. Our back catalogue is constantly growing with two new strips every week.

At XP 2022, we want to share with the audience why and how the format of a comic strip is a very powerful way of educating people on the wonders and pitfalls of agile. By using humor, exaggeration and provocation, and by articulating complex agile points through either visualizations or a simplified dialogue between the characters, we depict the tragicomical moments that occur when agile meets reality. These depictions of what actually happens in real life during agile transformations, based on our many years in the industry, has turned out to be a very effective way of teaching agile practitioners how to approach and accelerate the implementation of agile practices.

In this talk, we’ll break down the mechanics of how to create an educational agile comic strip and the components of it, such as setting the scene, introducing some agile theory, building an expectation and delivering a punchline in the form of an anti-pattern, misunderstanding or just plain craziness. We’ll also show and analyze some of our most popular strips as well as the agile lessons to take away from them. All of this will be delivered in a highly entertaining and dynamic manner for all audiences ranging from Scrum beginner to agile expert.

Learning outcomes:

– Why the simplistic format of a comic strip is an effective way of teaching otherwise complex agile lessons

– How the moment where agile meets reality is a learning opportunity

– How humorous visualizations facilitate a reflection on one’s own agile practices

Why eduScrum is the answer to hybrid education.

Suzanne Lagerweij.

Abstract. Suddenly, the whole world was struggling to work remotely, and worse: hybrid! In education, the challenges might even have been greater, as teachers and students both struggled to master the technology. When that was done, they soon discovered that was not enough. Providing an engaging curriculum that survives the translation to remote learning is not a simple matter of reciting a prepared lesson into the webcam.To enable remote and hybrid education, students need to work actively with the material, need to work with others to keep the social side of school alive, and need to have natural moments of feedback and coaching along the way to ensure we don’t leave anyone behind. Luckily, as we’ve found working with eduScrum in the University of Leiden, The Netherlands, an agile approach to teaching already has all those elements in place and can make the transition from physical to on-line seamless without putting additional stresses on the students and the teachers. The same principles of clarity, transparency, fast feedback and trust work well in both the working world and education.In this talk we will see how using eduScrum as the structure of learning has enabled classes to switch to on-line mode easily. We discuss why that works so well, and how that applies to remote working in general. I will show what changes should be made in both the structure of the curriculum and the way of testing, to enable an agile learning experience with trust, safety, transparency and collaboration as guiding principles. We discuss what that means for the work of a teacher (and manager?) in preparation and their role as a coach during the semester, as well as the impact for the students.

Jump-starting Agile in Your Organization.

Ankur Saini.

Abstract. While a variety of methodologies, including Kanban, Scrum, SAFe, and Lean, and associated training are widely available today for organizations looking for more agile ways to develop software. But how do you implement agile in your organization to deliver products that are fit for purpose and fit for use? Is there a silver bullet? Due to a number of reasons, often tactical implementation of an agile methodology and tools to jumpstart agile in an organization leads and overshadows the twelve principles behind the Agile Manifesto, which prevents the organization from reaping the rewards of true agility. This session presents a practical methodology based on the principles behind the Agile Manifesto for implementing and maturing agile practices in your organization based on real-life experiences from projects across two U.S. Government agencies. By examining the successes and failures along this journey, we will discuss optimizing a series of interrelated feedback loops (from product conceptualization through production deployment) that guide delivery of customer-centric products.

Keywords. Agile, Transformation, Feedback Loop, Methodology

Practice What You Teach – Exploring Motivation And Its Role For (Teaching) Agile Software Development.

Frank Schimmel.

Abstract. In this session, I will talk about the beginnings of my exploration of the relationships between motivation, agile software development and teaching, specifically teaching aspects of agile software development. I will present some insights I gained on my journey so far. I will provide a short introduction to self-determination theory (SDT), a psychological model of motivation. STD postulates that, for fostering a high-quality, resilient motivation, three basic psychological needs must be satisfied. I will link these needs to agile software development and illustrate how the ideas behind agile software development may foster such motivation. Furthermore, I will scratch on the surface of the relevance of STD for education. Finally, I will share how I used SDT for my teaching (of agile software development) at university and some ideas for directions of research this led to.## Learning OutcomesAttendees will be able to apply a SDT perspective to construct more effective learning environments and improve the effectiveness of their teaching.For this, attendees will learn how to identify where basic psychological needs of students/trainees may be especially satisfied or dissatisfied.Furthermore, they will be able to plan courses/trainings and devise and evaluate improvement experiments of courses/trainings through the lens of SDT.Attendees will be able to apply SDTto reflect on their own work environment with respect to basic psychological need satisfactionso that they can systematically improve their work environment.

Teaching soft skills.

Marianne Seppänen.

Abstract. Having only technical skills is not enough in today’s labour market. This has drawn attention to soft skills. Soft skills are cognitive abilities and social skills, such as communication skills, teamwork, creativity, and problem solving. Research reveals that engineering graduates are especially lacking in these skills. 

But how could we teach these skills to students? We studied which soft skills software engineering students learned during a project course. During this course the students worked in teams to develop software for companies. We sent them a survey and analyzed their learning diaries to find out which skills they improved and how, and which skills they consider important for their future careers.