Speaking 2018-10-28T18:10:02+00:00

SPEAKING

For your conference or corporate event I offer speeches in different lengths.

– You can hear me speak on the following upcoming events.
– Find here some recordings of my past presentations.
– If you’re looking for more in-depths sessions, I provide the following trainings.

I’m happy to customize to your audience the content and/or language (deutsch/english) on the following topics:

Topics

Speeches on: Scaling Agile

Agile Software Development in the Large
A lot of people still believe that agile software development is for small teams only. However, the agile value system and the principles behind as stated in the agile manifesto don’t argue about team or project size. Furthermore the projects I’m working on are typically large, distributed and mission-critical. Therefore, several years ago I took the challenge and tried agile software development in the large. Meanwhile I made the similar experience on many large projects: Also large and even distributed teams can benefit from a value system that is beneficial for small teams.
In this talk I want to show how to scale agile processes to teams of 300. In fact, the same techniques are also relevant to teams of ten or more developers, especially within large organizations.

Supporting Architecture in Large-Scale Systems
In order to welcome changing requirements (even late in development) agile development should enable the architecture to incorporate these changes and therefore to emerge over time. This implies not finalizing the architecture upfront. Moreover, in small agile teams it is assumed that there is no dedicated role for an architect – instead the whole team should be responsible for the architecture. In large-scale agile development the requirement for an emergent architecture still holds true. However, it is difficult if not unrealistic to expect e.g. 300 project 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 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 large-scale environments that take the degree of complexity into account.

Scaling Agile Principles
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 session 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 session 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.

Agile Software Development in a Large and Distributed Environment
Agile development isn’t any longer considered to work for small and collocated 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 session we will 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 session 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 and / or when working in a distributed environment. 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 or to a distributed setting.

The session is based on the necessity of large-scale and distributed 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. In fact the two trends – distribution in terms of globalization and Agile – can even complement each other.

Agile Development within the Corporation

Every agile approach takes place within a given context – the corporation. Agile product or project development, especially within large corporation are facing here specific challenges provided by the larger framework. The common departmental structure is often experienced more like a burden than support. As well the organization’s structure (yes, and of course as well its culture) can be experienced as being more or less helpful. Yet still, in order to become successful the agile undertaking has to deal with these challenges.

In this session, I want to explore how departments like Legal, Marketing, Sales, yet as well Quality Control, or Operations can support and how can they hinder agility. Despite the challenges, the focus is on leveraging the departments in order to become successful. Thus, involving everyone who is affected early on and making them part of the agile approach is crucial. This session is based on my experiences working in large and distributed corporations.

Speeches on: Distributed Agile

Agile Software Development for Distributed Teams
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.

Overcoming Cultural Differences by Focusing on Similarities
One of the challenges global teams are facing, is overcoming cultural differences. Yet, these differences have their origin not only in geography and language, but also in strategies, politics, values and history. A company, no less than the broader society, shapes a culture that influences its employees behavior. A distributed team needs to leverage this and jointly develop a project culture and keep the project history alive for emphasizing the common culture. This session points out techniques that have helped to create a common culture in different global projects I have been working on.

Applying Agile Development Practices in Distributed Teams
For a distributed team it is even more important to pay ‘Continuous attention to technical excellence and good design’ as the Agile Manifesto requests. Yet, how to implement the typical agile development practices like pair programming or collective code ownership in a distributed setting? Moreover are there any differences or things to watch out for when applying “easier” practices like unit testing or refactoring? In this session I want to focus on the impact and application of agile development practices in distributed teams and how such a team can ensure its technical excellence.

Agile Software Development in a Large and Distributed Environment
Agile development isn’t any longer considered to work for small and collocated 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 session we will 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 session 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 and / or when working in a distributed environment. 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 or to a distributed setting.

The session is based on the necessity of large-scale and distributed 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. In fact the two trends – distribution in terms of globalization and Agile – can even complement each other.

Agile Teams: Self-Organizing, Collocated, and Distributed
Agile development requires teams to self-organize. However, this doesn’t happen by chance. Teams have to be set up in a way that allows them to self-organize. And moreover, if you work on a large project with more than one team the team structure should still enable self-organization. The same is true for global development. In this session we will cover the essentials for building productive self-organizing teams for small and collocated and as well for large and
distributed settings.

Learning Outcomes:

– Understand what characterizes self-organization and the evolution of an agile team
– Understand what kind of communication and collaboration ensure a team’s agility
– Learn how teams can be agile in large and distributed environments
– Understand how both – developing business functionality and ensuring conceptual integrity of the architecture can be supported

Speeches on: Change and other Challenges

Complex Projects aren’t plannable but controllable – Learnings from Beyond Budgeting
Science has finally approved it: Forecasting complex projects is a deception. Moreover, forecasts hinder innovations. Daniel Kahneman, Nobel Prize Winner in Economic Sciences and psychologist verified in many cases, that forecasting of complex projects is impossible. Yet still, we keep losing time trying to do exactly that. Beyond Budgeting came empirically to the same findings and offers a concept for controlling corporations without budgets. Additionally Beyond

Budgeting provides advice
for controlling even long-term complex projects. Agile methodologies generally recommend developing a long-term plan on a coarse-grained level only and coming up with detailed short-term plans iteratively. In this talk I want to provide insights in the latest scientific research and show as well how Beyond Budgeting and Agile principles can be combined so that even complex projects remain controllable.

Learning objectives:
– Understand why forecasting complex projects is impossible
– Become acquainted with the core ideas of Beyond Budgeting
– Understand how Beyond Budgeting can be applied on Agile projects

Understanding and Changing Complex Systems with Human Systems Dynamics

Both our work life as well as our private life is based on interpersonal collaboration and communication. The dynamics that are created based on these interactions are often perceived as being complex. Understanding what’s happening at a specific moment and what can be changed in order to alter the dynamics requires to comprehend what marks these dynamics: – Containers, which are holding the system, – Differences, which are indicating the diversity of the individuals, and – Exchanges, which happen between and within systems. Human System Dynamics (HSD) provides a model which enables an in-depths understanding for these dynamics plus simple tools which allow to experiment in order to make a difference in a complex system. In this talk, I will explain the fundamentals of HSD and offer some of the tools that can be used right away in many different situations.

Overcoming Cultural Differences by Focusing on Similarities
One of the challenges global teams are facing, is overcoming cultural differences. Yet, these differences have their origin not only in geography and language, but also in strategies, politics, values and history. A company, no less than the broader society, shapes a culture that influences its employees behavior. A distributed team needs to leverage this and jointly develop a project culture and keep the project history alive for emphasizing the common culture. This session points out techniques that have helped to create a common culture in different global projects I have been working on.

Speeches on: Agile within the Organization

Company-wide Agility with Beyond Budgeting, Open Space & Sociocracy
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 the whole company. Yet implementing company-wide Agility isn’t straight forward, it asks for combining principles from the Agile Manifesto (inspecting & adapting), Sociocracy (creating equivalence), Beyond Budgeting (flexible budgeting & relative targets), and Open Space (passion bound by responsibility). By showing how such a combination can look like, Jutta will reveal a path toward company-wide Agility.

Sociocracy: Leveraging Agility in Your Organization
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.

Toward a learning organization with agile development
XP and Scrum exist meanwhile for more than 20 and the Agile Manifesto for more than 15 years – it’s about time to draw some conclusions. After in the late nineties the early adoptors – as usual – collected their experiences, nowadays increasingly the big industrial companies and consulting firms are the ones, who commit themselves to agile development. – With diverse pros and cons as a conclusion. Although the original euphoria is still recognizable, idealism had to give way to pragmatism. Therefore, more and more people recognize that it’s neither enough to leave agile development to the developers only, nor to apply it to one single project in a company.

Agile approaches will lead to sustainable improvement, if regarded as a part of a greater whole, which requests better interpersonal skills, taking more responsibility and therefore understanding the idea of a learning organization as the key to success.

Agile Development within the Corporation
Every agile approach takes place within a given context – the corporation. Agile product or project development, especially within large corporation are facing here specific challenges provided by the larger framework. The common departmental structure is often experienced more like a burden than support. As well the organization’s structure (yes, and of course as well its culture) can be experienced as being more or less helpful. Yet still, in order to become successful the agile undertaking has to deal with these challenges.

In this session, I want to explore how departments like Legal, Marketing, Sales, yet as well Quality Control, or Operations can support and how can they hinder agility. Despite the challenges, the focus is on leveraging the departments in order to become successful. Thus, involving everyone who is affected early on and making them part of the agile approach is crucial. This session is based on my experiences working in large and distributed corporations.

Increasing Productivity by Uncovering Costs of Delay
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.

Introducing Agility into an Organization or: How to become Agile
According to Forrester Research 14% of the enterprises both in the USA and in Europe apply an agile approach and another 19% consider to get started with agile. A lot of companies want to become agile because they regard agility as a promising development approach, not only because the Standish Group is recommending agile development processes for avoiding project failures. Yet, many teams are uncertain about how and where to start in order to become agile. Moreover, transitioning to agile often has an impact in many dimensions that are difficult to foresee. In this talk, Jutta provides insights in how to get started with agile, what pitfalls to watch out for in the transition phase and as well how to ensure that the agile mindset will be preserved.

Get over it! – Overcoming Organizational Shortcomings with Agility
Industrialization is especially well known for division of labor and tasks, as well as for streamlining and (pseudo) predictability. As a consequence this has created concepts like multi-projecting, mixing-up estimation and planning, and ignoring (social) values. The agile value system relies on the one hand on interdisciplinary teams working on complex tasks self-responsibly and on the other hand on plans that can change fundamentally. Agility leads most notably to sustainable improvement, if respected as part of a bigger movement – a movement that requires acting more and more responsibly, asking for higher social competence and last but not least regarding the idea of a learning organization as a key success factor. In this respect, agility is one piece of a puzzle of the third industrial revolution.

Speeches on: Agile in General

Stories about the Transformation toward Agile
Many teams, projects and organizations have meanwhile started the transformation toward an agile approach. Yet even more plan to do so. A lot of companies want to become agile because they regard agility as a promising development approach: Some because the Standish Group is recommending agile processes for avoiding project failures but even more so because an agile approach seems to be a better fit to the increasing market demands of today.

Yet, transitioning to agile often has an impact in many dimensions that are difficult to foresee. Moreover, many teams and organizations are uncertain about how and where to start, what pitfalls to avoid and what kind of opportunities to look out for in order to become agile. In this talk, Jutta shares “war stories”, including successes and failures about the transformation toward and integration of agile.

Typical Pitfalls in Agile Software Development
Many teams, projects and even organizations are following meanwhile an agile process. However, not always successful. If you’re looking behind the scenery, you will find out that although the agile practices like pair programming or test-driven development are used properly, the agile value system is not implemented. This is due to the fact that the practices can support agility but they can not establish agility. This leads to an expectation mismatch regarding acceptance and success of agile development.

With her experience in helping projects all over Europe to establish the agile value system, Jutta will point out what to look out for when applying agility.

Increasing Productivity by Uncovering Costs of Delay
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.

Agile Teams: Self-Organizing, Collocated, and Distributed
Agile development requires teams to self-organize. However, this doesn’t happen by chance. Teams have to be set up in a way that allows them to self-organize. And moreover, if you work on a large project with more than one team the team structure should still enable self-organization. The same is true for global development. In this session we will cover the essentials for building productive self-organizing teams for small and collocated and as well for large and distributed settings.

Learning Outcomes:
– Understand what characterizes self-organization and the evolution of an agile team
– Understand what kind of communication and collaboration ensure a team’s agility
– Learn how teams can be agile in large and distributed environments
– Understand how both – developing business functionality and ensuring conceptual integrity of the architecture can be supported

Introducing Agility into an Organization or: How to become Agile
According to Forrester Research 14% of the enterprises both in the USA and in Europe apply an agile approach and another 19% consider to get started with agile. A lot of companies want to become agile because they regard agility as a promising development approach, not only because the Standish Group is recommending agile development processes for avoiding project failures. Yet, many teams are uncertain about how and where to start in order to become agile. Moreover, transitioning to agile often has an impact in many dimensions that are difficult to foresee. In this talk, Jutta provides insights in how to get started with agile, what pitfalls to watch out for in the transition phase and as well how to ensure that the agile mindset will be preserved.

Short Bio

Jutta Eckstein works as an independent coach, consultant, and trainer. She holds a M.A. in Business Coaching & Change Management, a Dipl.Eng. in Product-Engineering, and a B.A. in Education. She has helped many teams and organizations worldwide to make an Agile transition. She has a unique experience in applying Agile processes within medium-sized to large distributed mission-critical projects. 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: Finding the Real Value in your Project Portfolio’.

Please look also at my recordings (webinars and videocasts).