Over the last few years, as agile has gained traction inside the enterprises, we've seen many scaling frameworks have sprung up. These scaling frameworks claim to retain the core agile values & principles and aim to provide a simple yet comprehensive way to scale agility across the organisation. There have been several success case-studies that have been published. We also hear and see many horror stories of failed scaling attempts. 

In this panel, let's have a critical view of the entire scaling framework eco-system.

Today companies are expected to be flexible and both rapidly responsive and resilient to change, which basically asks them to be Agile. Yet, doing Agile (the mechanics) is different from being Agile (the mindset). The mindset lets you apply flexible Agile patterns not only for software development teams but for whole company. In this workshop, we will examine what being Agile really means and how it can be implemented by combining principles from the Agile Manifesto, Sociocracy, Beyond Budgeting, and Open Space. We’ll draw on everyone’s experiences to show the path to transforming our companies into agile enterprises - from Board to janitor, offering concrete tools and methods that participants can apply right away.

At the core of lean product delivery is -of course- the continuous delivery of a product. Yet, how does this impact the architecture, especially when welcoming changing requirements (even late in development)? Basically, the architecture should be enabled to incorporate these changes and therefore to emerge over time. This implies not to finalize the architecture upfront.

For a small team being jointly responsible for the product delivery AND the architecture this is often already a challenge yet even more so for a large team. But, also for large-scale agile development the requirement for an emergent architecture holds true. However, it is difficult if not unrealistic to expect e.g. 300 team members to decide jointly on the architecture.

Moreover, the role of and support for the architecture depends not only on the degree of the size of your development effort but as well on the degree of complexity of the system. 

In this session I report on my experiences using different models for supporting an emergent architecture in different (mainly large-scale) environments that take the degree of complexity into account.

Sociocracy is a way for groups and organizations to self-organize. Based on four principles only (self-organizing teams, shared decision making based on consent, double-linking, and electing people to functions and tasks), sociocracy provides a path for existing organizations toward empowerment and self-responsibility on all levels. It enables managers to become agile leaders. Different to comparable models, sociocracy allows companies to start where they are – with their existing organizational structures and the like. It seems to be a perfect fit for organizations which are in the need to be agile truly (due to market pressure), beyond their IT departments and software teams.

Moreover, on the team level - sociocracy provides a means for the Scrum Master and/or coach to enable self-organization.

The necessity of rapid change is the topic number one nowadays. This regards on the one hand organizational change that we need to create and promote in order to stay in business, to respond to market pressures, and to be innovative. On the other hand this respects change that we face as organizations and individuals.

During this workshop I want to provide answers –using both theory and practice– to the following questions:

• What’s happening with affected persons during a change?
• According to complexity theory there is no resistance to change. So why is change still hard and how can we introduce change smoothly?
• What is fundamental to every change?
• What needs to be considered for implementing change successfully?

In order to answer these questions we will make use from the insights from different change models.

On the one hand there are meanwhile not many projects left that are made at home without outsourcing, off- or nearshoring. On the other hand more and more projects discover the success factor of agile development which requests - among other things - an emphasis on face-to-face communication.

In this course attendees will learn about the key success factors  for distributed (and maybe even large-scale) software development. The focus will be on how to apply agile processes in a distributed setting and how to establish and preserve a common development culture. Participants will learn how to adapt both simple agile practices like a Daily Scrum (also known as: daily stand-up meeting) and more complex practices like a retrospective to a distributed environment. 

Attendees will understand that also distributed (and large) teams can  benefit from a value system and from principles that are beneficial for small teams. In fact the two trends - distribution in terms of globalization and agility - can even complement each other.

The necessity of rapid change is the topic number one nowadays. This regards on the one hand organizational change that we need to create and promote in order to stay in business, to respond to market pressures, and to be innovative. On the other hand this respects change that we face as organizations and individuals.

During this workshop I want to provide answers –using both theory and practice– to the following questions:

• What’s happening with affected persons during a change?
• According to complexity theory there is no resistance to change. So why is change still hard and how can we introduce change smoothly?
• What is fundamental to every change?
• What needs to be considered for implementing change successfully?

In order to answer these questions we will make use from the insights from different change models, Human Systems Dynamics (HSD), and Fearless Change.

Agile development isn’t any longer considered to work for small teams only. Also large teams, projects and organizations are asked to focus on delivering value. So the question arises, how to adhere to the agile principles when applying them in the large.

In this workshop we want to use the agile principles as a guideline for scaling. This is basically by understanding agile as a value system, a mindset, a culture – and not as a tool. So be prepared to being asked to think for yourself and to balance forces based on your own needs and requirements instead of finding a recipe that assumes that one size will or can fit all (organizations, projects, products, or teams). Thus, this workshop is not about providing or defining a framework for the enterprise or the organization, scaling scrum or using other existing methodologies at different organizational levels. It is about examining the agile principles according to their effects and application when scaling up. For example, we will discuss what a principle such as "self-organizing teams" means when it is applied to a team of more than 100 developers or to the enterprise level.

The workshop is based on the necessity of large-scale Agile to give and get frequent feedback in order to deliver the highest business value to the customer at all times besides learning and getting better continuously.

Fred Brooks once stated so wisely "How does a project get to be a year late? … One day at a time." Lean Development and queuing theories offer help so that this won't happen. The suggested remedy is to implement a steady flow in order to achieve maximum productivity. However, most teams and organizations are far from reaching that goal and moreover it is often unclear which approach leads to what kind of delay. In-depth examination shows how generally accepted concepts such as Definition of Ready, Clean Code, or experts in a team can lead to costs of delay. In this session Jutta presents simple tools and methods for uncovering hidden costs of delay. These tools and methods can be applied in various contexts: In small and large teams as well as in co-located and distributed teams. Using an agile approach will help to make these cost visible.