This event has ended. Visit the official site or create your own event on Sched.

Sign up or log in to bookmark your favorites and sync them to your phone or calendar.

Talk [clear filter]
Tuesday, May 23

13:15 CEST

Feature Branching is Evil

Why is our software industry vastly adopting Feature Branching ? "To isolate the work of the developer so he can be more productive" I was told. But does it really make your team more productive ? Are the projected benefits worth the problems it introduces ?

Feature Branching became mainstream in most IT organisations because proponents of DVCSs mostly rely on Feature Branching to sell DVCS. And probably also because of the success of GitFlow ... 
But like all powerful tools, there are many ways you can use DVCSs, and not all of them are good. Feature Branching is definitely not a good way to use them. Although branch creation is easy, this does not mean cheap in the long run. It comes with a certain cost, certainly in the context of Continuous Integration and Continuous Delivery. 
Amongst others, one of the biggest problems, is that it breaks the early feedback cycle of Continuous Integration. As long as the Feature Branch is not merged back into main line, the feature is not integrated into the application.

The evilness lies not much in the problems introduced by Feature Branching, but rather in the reasons teams are using them.

During this session we will explore the reasons for using Feature Branches, what is wrong about Feature Branching and what techniques you can use to avoid them all together.

The target audience for this session are software engineers, technical team leaders, architects, and anyone using version control systems in a Continuous Integration and Delivery context.

avatar for Thierry de Pauw

Thierry de Pauw

Thierry is an Agile Technical Coach, Continuous Delivery consultant and Lean and XP Software Engineer.He is a jack-of-all-trades with a passion to help teams create meaningful software, with a keen eye for code quality and the software delivery process, from customer interaction to... Read More →

Tuesday May 23, 2017 13:15 - 14:15 CEST
Ballroom C 1st Floor

13:15 CEST

Lean Code

Software development is full of waste. I have constant anxiety that I'm investing my time and energy into the wrong design. And I don’t think I’m the only one. So what processes could reduce that waste? Through validated learning, Lean methodologies have helped reduce waste in manufacturing and product development. Maybe Lean can help software engineers too. 

Lean Startup has a lot in common with Extreme Programming. They have very similar philosophies on value, waste, and responding to change. Of course, XP focuses more on engineering, while Lean Startup focuses more on product management. A bigger difference is that XP emphasized emotions, while Lean Startup emphasizes numbers. After exploring the combination, I’m convinced that bringing XP and Lean Startup together leads to sustainable innovation for software design. 

XP is a disciplined form of agile software development. Lean Startup is even more disciplined and goal-oriented. The heart of Lean is build-measure-learn experiments. We want to find out as early as possible whether we are going in the wrong direction. If we are, then we pivot. XP engineers can apply Lean by transforming the red-green-refactor cycle into a build-measure-learn cycle. We can think of our designs as hypotheses and our stories as users.

In order to foster good software design, XP needs the goal-oriented discipline of Lean. Kent Beck’s advice to “make the change easy, then make the easy change” is validated learning via pain. We don’t all experience pain the same way, though. In order to coordinate our design efforts, we need a shared understanding of “the easy change.” Once we have a clear goal, different opinions on how to get there become opportunities to learn. By experimenting and measuring the outcomes we can continuously improve our designs.

This talk explores one way to apply Lean principles to XP. I will share my experiences and the challenges I have encountered. I want the audience to come away from this talk eager to find new ways of blending the humanity of XP with the rigorousness of Lean.

avatar for Desmond Pompa Alarcon Rawls

Desmond Pompa Alarcon Rawls

Software Engineer, Pivotal
Software is my never-ending detective story. Come talk to me about the similarities between software architecture and org structures, putting problems before solutions, how to decompose a problem, the politics of dependency inversion, and why software engineering is hard.

Tuesday May 23, 2017 13:15 - 14:15 CEST
Belvedere 12th Floor

13:15 CEST

Learning to Read the Label on the Jar You're In

The problem: Your team is made up of people from different national cultures, and getting to know and trust each other is a slow process. Whether your team is working in the same office or across an ocean, your progress is in jeopardy unless real collaboration starts happening soon. You're concerned that stereotyping and other negative feelings will grow as schedule pressures increase unless you can find a practical, simple idea that you can use to help individuals "build bridges" across to each other. 

In this session we will start with a brief overview of 5 dimensions of national cultures as presented in the book "Cultures andOrganizations" by Geert Hofstede and Gert Jan Hofstede. The book quantifies cultural attitudes based on five cultural
axes, namely:
1. Power Distance 
2. Individualism
3. Masculinity-Femininity
4. Uncertainty Avoidance
5. Long / Short Term Orientation

Here are a few examples of how cultural differences might affect an agile team:

Someone from a highly individualistic culture might want to build their skills far above the others, not taking time to bring others along. They see this as standing out as a leader. A team-mate from a more collectivist culture may see it as self-centered showing off.

Someone from a high power distance culture does not want to voice opinions in estimation sessions until they know their manager’s opinion on the topic because to be in disagreement with their manager is disrespectful, no matter who is right.

We'll take each cultural axis in turn (as time allows), and you'll find out where your culture ranks, and with a pair you'll explore how to handle an important Agile team communication topic. Even if all cultural axes cannot be covered, you'll have enough understanding to use Hofstede's book to do further explorations.

Our own culture can contribute to problems if we are unaware of how it affects our behavior, and of how our behaviors are perceived by others. Cultural diversity in a team can be trouble just waiting to be triggered, or it can be a real strength. The difference is simply awareness and readiness to make adjustments.

avatar for Nancy Van Schooenderwoert

Nancy Van Schooenderwoert

President, Lean-Agile Partners, Inc.
Nancy was among the first to apply Agile methods to embedded systems development, as an engineer, manager, and consultant. She has led Agile change initiatives beyond software development in safety-critical, highly regulated industries, and teaches modern Agile approaches like Mob... Read More →

Tuesday May 23, 2017 13:15 - 14:15 CEST
Ballroom B 1st Floor

15:15 CEST

Building the Right Things Right? We Can Do Both With Continuous Business Goal Validation.

There is a lot of focus on software craftsmanship and automation. We can build and deploy software very quickly with current technologies. However, it’s the post-deployment stage that worries me. How can we be sure that this new functionality has the impact the business needs? In other words: are we building the things right or are we building the right things? We think you can do both with continuous business goal validation.

When making software products we made a lot of assumptions about how functionality will help us in reaching business goals. But we rarely see those assumptions being validated afterwards. We mainly run back to the backlog and start on the next feature.

We found out that there is much overlay with impact mapping. In a sense continuous business goal validation is the automation of impact mapping. Where impact mapping is a great way to define products, business goal makes sure your assumptions are being validated. Not once, but as long as the functionality is alive.

By measuring those assumptions, not only once after going live but automated and over time, when the software is being used we can really learn a lot. Do users really use this functionality as expected? Did this new feature affect the usage of an older one? In short: did we make the right assumptions? This way you can keep your product as small as possible but most effective. Remove or change functionality and keep waste to a minimum. 
This is what we call continuous business goal validation…or is it validated learning?

How to:
While setting up projects or define features in ongoing customer relations setting up impact maps and/or business canvas models are a great way to have a concise view on what the expectations of the software are. This should be the start of any phase and should be done in a cooperation between business and IT or customer and supplier depending on the situation. Afterwards it is clear which problems we are going to solve for who and not the least: what are the goals we want to reach?

Business goal validation then makes it possible for a product owner to clearly communicate with stakeholders about the business goals and the results of the validation. “Yes we assumed together that the effect of this was X but we found out that this assumption was wrong. Let’s find out why and get it right”. It clearly helps the stakeholders and the product owner to define the right functionality and validate these continuously instead of detailed discussions about functionality.

We will explain how to go from inception, objectives (input-output) and outcomes and validate if goals are reached. Which choices are there to be made if a measurement fails or passes? We will show that this is an ongoing process where customers and suppliers continuously validate if they are really building the right things right.

avatar for Hylke Stapersma

Hylke Stapersma

Software craftsman, codecentric Netherlands
Hylke is a software craftsman who is working as a consultant for codecentric and he is a contributor and maintainer of a small number of open-source projects. He is passionate about sharing ideas and knowledge on everything related to software development and delivery.
avatar for Niels Talens

Niels Talens

Agile Consultant, codecentric AG
In the end there is only one thing that really matters in software development: delivering useful high quality software. Things that certainly can help in this matter are agile, Scrum, automated testing, continuous delivery, devops and so on. The bigger picture. That’s what I’m... Read More →

Tuesday May 23, 2017 15:15 - 16:15 CEST
Ballroom D 1st Floor

15:15 CEST

Choose Your Own Agile Adventure

Everybody wants to be a Scaled Up Lean Startup Enterprise nowadays. But do you have what it takes to be on the edge? And should you even be trying?

At every conference you hear many great ideas. And you would probably like to implement some of them back at work. And yet, is this really the right moment? And have you considered if the rest of the organisation can keep up? Or even wants to?

In this talk we present a way to navigate the different practices available from the Agile community. Inspired by the Agile Fluency™ Model, we show you how to start with the issues you face today, find the direction you’re aiming for, and identify the Agile practices that will help you get there.

In practical terms, we’ll describe the kinds of situations, problems and issues that can be encountered, discuss what different reactions can be depending on the stage of fluency we’re aiming at, and what practices and skills might help progressing from there.

avatar for Karel Boekhout

Karel Boekhout

Agile Coach, Hedgefields
Karel Boekhout is a no-nonsense Agile coach, operating in and around The Netherlands, with a passion for innovative methodologies like Mob Programming, the Guide Board and the Agile Fluency™ Model.
avatar for Wouter Lagerweij

Wouter Lagerweij

Agile Coach
I love spending time with teams and organizations to figure out how to improve the way they make software, and make it more fun.To make that happen I use the knowledge and skills gathered in over ten years of experience applying Agile processes and practices from XP, Scrum, Kanban... Read More →

Tuesday May 23, 2017 15:15 - 16:15 CEST
Belvedere 12th Floor

15:15 CEST

How to Stop Hating your UI Tests

Test automation projects can have a bad tendency to go awry, most especially when higher-level automation (e.g. via the UI) is involved. At some point, automated tests just become too hard to understand, extend and maintain.

This doesn’t have to be the case though. In software development, there are systematic methods and patterns for addressing recurring challenges – and similar approaches also exist for test automation.

In this talk, I’ll first go on a short rant about all that is wrongly understood or implemented in UI testing, then I’ll present a structured, systematic and tool-independent approach for automating UI tests. The approach and the patterns that result from it haven’t simply been invented from scratch, rather they build on and expand patterns and methodologies well-known from software development and web-testing for example.

During the talk, I’ll show examples to illustrate the structures I describe. Anyone involved in automating tests (whether they are programmers or not) can profit from learning and applying these patterns in their teams.

avatar for Alex Schladebeck

Alex Schladebeck

Alex is the head of Test Consulting at BREDEX GmbH and is also Product Owner for Jubula, the open source test tool. Within both roles, shes responsible for making sure that customers needs are satisfied, be it in terms of quality assurance services for their projects or features for... Read More →

Tuesday May 23, 2017 15:15 - 16:15 CEST
Ballroom C 1st Floor
Wednesday, May 24

11:00 CEST

Think for Impact - the Journey From XP to Cloud to Product
  • You have some XP practice in pockets and high performing teams, but scale is tough.
  • Things are changing - there's a mass move to Cloud & you need to keep engineering discipline.
  • Teams need to be Product-focused and think in Platforms, not projects. Self-awareness is important - what are you bringing to the table.

How about creating a definition of your engineering approach to share good practice & enable engineer collaboration (using Kotter and also an anti-fragile approach to knowledge - encourage challenge). The business customer needs us to be responsive, disruptive, reliable and professional - call it an "iron square" of the industry today. Our engineers need to be able to tap into knowledge & support networks instantly. This is important for any engineering department in a large company - do you know what your value-proposition is?

Engineering also have significant Cloud Challenges - microServices, polyglot, emergent architecture, 12 factor, Cloud First, build to scale..etc... Things are moving fast.

The LIT.method is our approach (which can be replicated) and we have been inspired by some of the HSD & Cynefin approaches to balance alignment and autonomy. The perfect pull system for a 500+ person organization.

The grass-roots Roll-out was via openSpace, lean coffee & conversation. We made a conscious decision to flip top-down comms and practice radical transparency.


We build for end-Customer Impact & align with the internal-Customer, but need to retain XP discipline - Customer focus & collaboration is everything. We decided to make it real and share real experience, not theory or abstracts (with a solid system of principles as a foundation). We found that working engineers don't need high-brow principles or theory, just techniques and experience they can use today. The LIT.method() is the way we have accelerated collaboration with a clear goal of "internal-customer" satisfaction (via a high standard of engineering).

We did not use any scaling frameworks (but we inter-operate with several), we have real business on the line so have been very pragmatic, we are presenting real results, metrics & experiences. We have used Hypothesis & Product thinking to inform our approach (which has taken many turns).

avatar for David Anderson

David Anderson

Director of Technology, Liberty Mutual
As Director of Technology with Liberty IT, working on many Liberty Mutual key systems, David has exposure to a wide range of technologies and techniques covering Architecture, UX, Dev, Test, DevOps, Analytics & Cyber-Security. A life-long programmer, David brings deep technical knowledge... Read More →

Wednesday May 24, 2017 11:00 - 12:00 CEST
Ballroom D 1st Floor

11:00 CEST

Zero Defect Front Ends

Are you tired of hunting down bugs in your code? Honestly, why are you still doing this instead of simply writing code, that has zero bugs, all the time?

Meet Elm, a purely functional programming language that compiles to JavaScript. One of the most interesting properties of the language is a very strong guarantee: The compiled code will have no runtime errors at all!

With this, you can finally have a code base that is verifiably free of defects. Large refactorings are no longer scary with this level of confidence, which benefits the long term maintainability and adaptability.

However, this talk is not only about Elm: We will take a close look at Elm's high level concepts in a broader scope, that is, stateless functions, immutable values, unidirectional data flow and Elm's architectural model for applications. We will then discuss how these concepts make it easy to write high quality code consistently, and how these benefits can be translated to other programming languages as well.

avatar for Bastian Krol

Bastian Krol

Developer, consultant and coach at codecentric. Interested in functional programming and web technologies, Elm, Haskell, JavaScript...

Wednesday May 24, 2017 11:00 - 12:00 CEST
Ballroom C 1st Floor

13:30 CEST

How Software Developers Can Transform Organisations

Aligning organisational and technical boundaries with the organic boundaries of a problem domain to create autonomous teams enables organisations to innovate faster by making decisions faster, implementing ideas faster, and getting customer feedback faster. Guided by the strategic principles of Domain-Driven Design, software developers can play a key role in leading the transformation of their organisation towards greater autonomy.

Instead of naively chopping up a system into arbitrary small pieces and calling them ‘microservices that implement bounded contexts’, or merely thinking cross-functional teams will suffice, deeper - more nuanced design skills are needed. All domains are different - there is no flowchart that guides teams into knowing exactly how to break up a large system into smaller pieces that minimise the costs of handovers and shared dependencies.

Strategic Domain-Driven Design introduced the concept of subdomains; things that change together for business reasons. Accordingly, teams that own things that change together for business reasons will own more decision making and have more autonomy.

Traditionally, Domain-Driven Design has encouraged use of language as a way to identify the boundaries between things that change together. Whilst language is still a key heuristic, there are many others, in particular the flow of work through an organisation. Subsequently, by supplementing the design of teams and services with the the goal of eliminating bottlenecks in an organisation, Theory of Constraints provides a powerful mindset for determining good microservice and team boundaries.

avatar for Nick Tune

Nick Tune

Sociotechnical Thinker, Independent
Nick is passionate about delighting users, creating business impacts, and crafting quality software, placing an equal focus on improving both the delivery capabilities and alignment of an organisation. He specialises in transformation projects, having worked with high-profile organisations... Read More →

Wednesday May 24, 2017 13:30 - 14:30 CEST
Belvedere 12th Floor

13:30 CEST

One Small Step for Man, a Giant Leap for Agility & Autonomy

A lot has been written and said about the added value of feature teams. Feature teams reduce the complexity and waste of external dependencies, have more focus on delivering real customer value and bring more autonomy to the people involved in the delivery of the product every single day at work. Organizations aiming to reach true Agility in the market better transform their component teams to feature teams soon!

It’s all easier said than done though; especially for the organizations that were around way before the Agile era. ING Bank is one of those organizations where most teams were built around components for many years. But ING Bank is also an organization that understands the necessity of being able to respond fast to the demands of the customer and has therefore progressed in the transformation of their old way of working to an Agile way of working. Forming feature teams, including business and IT, is an important challenge and step in this transformation.

Where do you start if you would like to transform existing component teams into effective feature teams while keeping the ship afloat? What steps do you need to take and who do you involve at specific parts in this process? Do we actually see improvements in the current status yet?

Maurice van Wijk and Nienke Alma, Agile Coaches at ING Bank, have been closely involved in a challenging, but also inspiring journey from component teams to feature teams. The road from preparations, how to get all parties on board, the needed steps and sessions ending in self-selections and kick-off of newly rising feature teams. In this presentation they will explain what approach they have followed and share their experiences. You will explore together with them what worked well and may work for you, what could be done differently in the next journey, and their next steps.

avatar for Nienke Alma

Nienke Alma

Agile Coach, ING
Nienke Alma is a people oriented Agile enthusiast with 12 years of experience as Agile coach, trainer, Scrum Master, tester and test manager. She currently works as an Agile Coach at ING in the Netherlands.She has special interest in team dynamics. Getting the best out of individuals... Read More →
avatar for Maurice van Wijk

Maurice van Wijk

Agile Coach, ING Netherlands
I am an Agile Coach within ING. Work for ING since 2010 & IT as a Manager/Coach with experience for 10 years. In the lead of implementing new departments and new technology, and have been an energetic part of change and innovation within several companies Expertise : Agile, Agile... Read More →

Wednesday May 24, 2017 13:30 - 14:30 CEST
Ballroom B 1st Floor

13:30 CEST

Tackling 16 Years of Legacy Code With Mob Programming and LEGO®

Picture the scene. You've joined a new team that work on the most important product in the company. There's just one catch. The code base is using 2002 technology and the attitude has been "get it done" since then.

Things need to change fast. To reduce the amount of work in process you adopt mob programming - where the whole team work on only one task together on one computer - and start creating a culture of safety over fear. Things start to feel better but you can't help but feel that your being distracted from your goal.

In this case study you will learn about how a team can go from individuals to a mob. You'll also hear how the most powerful improvement tool the team found was to use Lego to represent time spent. After this you'll know about mob programming, making problems visual with Lego and how that combination doubled the productivity for this team in six months.

avatar for Joe Wright

Joe Wright

Arnold Clark
Joe Wright is a tech lead that specialises in helping legacy teams with monolithic codebases. He targets the culture of teams, removing anything that they fear while improving the technical capabilities of the team. Joe is an ex-ThoughtWorker, organiser of the CodeCraft conference... Read More →

Wednesday May 24, 2017 13:30 - 14:30 CEST
Ballroom C 1st Floor

13:30 CEST

The Alignment
Aligning business and IT has been a popular yet empty meme for decades. So empty that many implicitly gave up. However, gathering all the key people in the same room in order to outline a model and a possible strategy is only the beginning of the journey.
“Alignment” - whatever that means - can be achieved only if wrong mental models are abandoned in favour of a deeper understanding of our ecosystem.

avatar for Alberto Brandolini

Alberto Brandolini

Alberto Brandolini is a 360° consultant in the Information Technology field. Asserting that problems cannot be solved with the same mindset that originated them, Alberto switches perspective frequently assuming the architect, mentor, coach, manager or developer point of view.He’s... Read More →

Wednesday May 24, 2017 13:30 - 14:30 CEST
Ballroom D 1st Floor

15:00 CEST

Coffee Break & Poster Session
Critical Success Factors of Agile Software Development: Review Study
Abdullah Aldahmash, Andy M. Gravell, Yvonne Howard

avatar for Ademar Aguiar

Ademar Aguiar

University of Porto

avatar for Abdullah Aldahmash

Abdullah Aldahmash

University of Southampton
avatar for Silvia Bordin

Silvia Bordin

PhD candidate, University of Trento
During my PhD I have collaborated with small Agile companies to help them adopt user-centred design techniques.
avatar for Torgeir Dingsøyr

Torgeir Dingsøyr

chief scientist, SINTEF
Torgeir Dingsøyr has studied teamwork and learning in software development, as well as development methods for large software projects and programs. He is chief scientist at the SINTEF research foundation, which is recognized as one of the leading research environments in the world... Read More →
avatar for Ivana Gancheva

Ivana Gancheva

Research Scientist, SINTEF
Ivana is a an organizational coach and researcher, passionate in helping companies achieve business agility. She also organizes and speaks at conferences.
avatar for Tomas Gustavsson

Tomas Gustavsson

PhD Student, Karlstads universitet
Started out as an IT consultant in 1996 and have since worked as project manager, lecturer, author, publisher and CEO but decided to wholeheartedly work within academia and began as PhD student in the fall semester of 2016. I focus on large-scale agile development, specificially within... Read More →
avatar for Herez Moise Kattan

Herez Moise Kattan

University of Sao Paulo
Herez Moise Kattan received his Technical degree in data processing from Paula Souza State Center for Technological Education, Sao Paulo, in 1996, his Bachelor degree in analysis of systems from Paulista University, Sao Paulo, in 2000, and his Master of Science degree in computer/software... Read More →

Wednesday May 24, 2017 15:00 - 15:30 CEST
Ballroom A + Foyer 1st Floor

15:30 CEST

Metrics to Guide: Changing Measures Along the Way

Metrics are useful tools, yet dangerous. Measuring the wrong thing can steer us in the wrong direction without us even noticing. And even the right metric can cause stagnation when we need to progress to the next challenge. 

Inspired by the Agile Fluency™ Model, in his talk we discuss how the stage of fluency determines what types of metrics you should focus on. And how we need to change that focus as we progress to a different stage.

We’ll discuss how you can start with the basic metrics from Scrum or Kanban, such as velocity and cycle time. Then you can progress through to the type of delivery focused metrics from Continuous Delivery. Finally, we arrive at business focused metrics appropriate for product teams.

avatar for Karel Boekhout

Karel Boekhout

Agile Coach, Hedgefields
Karel Boekhout is a no-nonsense Agile coach, operating in and around The Netherlands, with a passion for innovative methodologies like Mob Programming, the Guide Board and the Agile Fluency™ Model.
avatar for Wouter Lagerweij

Wouter Lagerweij

Agile Coach
I love spending time with teams and organizations to figure out how to improve the way they make software, and make it more fun.To make that happen I use the knowledge and skills gathered in over ten years of experience applying Agile processes and practices from XP, Scrum, Kanban... Read More →

Wednesday May 24, 2017 15:30 - 16:30 CEST
Ballroom D 1st Floor

15:30 CEST

The Science of Hiring: What You Don't Know CAN Hurt You
The biggest success of industrial psychology over the last 100 years is the development of decision aids that can provide a predictive edge when making choices for selection and development of people. At the same time, industrial psychology's greatest failure has been its inability to convince organizations to stop using ineffective processes and use science and technology instead. Have you ever complained about recruiters not bringing you great candidates? Have you ever hired or promoted someone that didn't work out? This session will review what 100 years of research has uncovered and show you how to bring your hiring and promotion practices into the 21st century.

avatar for Tamsen Wassell

Tamsen Wassell

Principal, Wassell Enterprises, Inc.
After 30 years of organizational development consulting, I refocused my practice on helping people and organizations happier and more productive. 100 years of behavioral science studies have resulted in the development of predictive tools to match people with jobs that they will... Read More →

Wednesday May 24, 2017 15:30 - 16:30 CEST
Ballroom B 1st Floor

15:30 CEST

Thinking Independently Together

Diversity is great, right? The more the better. That is what we are of tought. 
However, does diversity really deliver on its promise? Is there such a thing as too much diversity? Can diversity sometimes become an objective on it's own? Do we sometime sacrifice other important outcomes on the alter of diversity? 
Futhermore, diversity is supposed to be a good thing. It is a value that we should all adopt, right? However, isn't a common culture the 'glue' that holds the team together? Is that the opposite of diversity?
This talk is an attempt to give an honest look at these questions, and provide answers  and insights rom my own experience.
I explore the limits of diversity. When is diversity good, and when get it be detrimental.

Over the years I have tried to build teams that are diverse enough to avoid the groupthink trap, yet able to work together towards achieving a common goal. Sometimes I succeed, sometimes I failed, but I always learned something.
As a senior technical architect at Cisco that leads a team of software architects, I will draw on my professional experience to offer insights on the benefits of diversity, the traps of groupthink as well as value and challenges of working with technical teams across the world. I will discuss the Agile approaches which helped to achieve the goals effectively and those that did not work quite so well. 
I will start the report by asking some questions, followed by a discussion of how they are answered within the organization I work for. For example, what is the main driving force behind the goal to create diverse teams? How many faces does diversity have? Lack of gender diversity in technology space is a well-known issue, cultural diversity is targeted by many other professional fields. But is it really all we look for? How about diversity of skills, mindsets, social experiences, attitudes?
I will make the connection between diversity in teams and diversity in agile processes, looking at interactions, challenges and dynamics in varied and conforming teams.

You might not agree with everything I have to say. That's fine. Hopefully you will be provoked into giving some deep and honest thought of these issues.

avatar for Avraham Poupko

Avraham Poupko

Senior System's Architect, L&T Technical Services
I am an Architect and leader of a group of Architects in L&T's Center of Excellence in Jerusalem. I am fascinated by the ways by which people get together to create software. The idea of minds joining to create something "abstract" such as software is one of the great wonders of... Read More →

Wednesday May 24, 2017 15:30 - 16:30 CEST
Belvedere 12th Floor

15:30 CEST

Fake It Outside-In TDD

In the context of bigger systems classic emergent design can result in losing a lot of time by letting similar responsibilities emerge again and again. In contrast the London School of TDD works Outside-In using mocks. It shines whenever the objects' responsibilities are quite clear upfront. An alternative I’ve developed over the last year is "Fake It Outside-In TDD". Instead of mocks fake data originating from the test assertion become your primary design driver. On an incremental destructuring journey down the call stack the data morphs more and more into structure. Design therefore develops "Outside-In" but on a "green bar" in the refactoring phase as opposed to London Style on a "red bar" when writing your tests. The remaining real "logic" is tackled with regular unit-test level TDD. The approach hits the sweet spot

  • when there is little complexity in the interactions,
  • when the structure is complex or
  • when design skills aren’t very sophisticated yet or when teachability of TDD is important.

The session starts by explaining the different TDD approaches including the "Fake It Outside-In" variant. In a mob-programming session we then try out the new approach, followed by a discussion of our observations and opinions regarding the approach. The session ends with a comparison of the respective TDD approaches’ strengths and weaknesses.

avatar for David Völkel

David Völkel

Senior IT-Consultant, codecentric AG
I am a TDD maniac and co-organize the Softwerkskammer Software Craftsmanship Meetup Munich.

Wednesday May 24, 2017 15:30 - 17:00 CEST
Ballroom C 1st Floor
Thursday, May 25

11:00 CEST

Make the Agile Transition Work! And What HR Can Do to Support It...

During an agile transition the change of mindset, leadership behavior and the shift of responsibilities to many are key elements. Usually a company would work very hard on delivering this message, training people and make sure, they understand this new philosophy. But when it comes to daily business, the employee needs to see structural and process changes, too, to receive guidance and boundaries. Furthermore, they need to see that the agile transition is something that not only takes place in mindset but also happens in reality. He needs to feel safe when acting based on the new philosophy. Feeling safe is something that they will only experience when the new definitions, rules, guidelines and boundaries are also made explicit. Quite often those structural and more tangible changes will only follow after a while. During this period confusions and fallback into old habits may arise. 
And here the contribution from HR can and needs to start! Become involved and proactive: Understand what agile transition means and immediately start changing old systems and processes. Develop and offer new tools whenever needed to support the new way of working and thinking. Emphasize the wanted behavior and work methodology in guiding the teams through three stages with your new tools. 
The speech will describe the benefit of the listed three phases and concrete tools and guidance on how to implement them:

  1. Sharing (feedback) is caring
    a. Throw away your old manager – employee dialogues
    b. Implement team feedback 
    c. Let the teams do their feedback dialogues themselves
     Team feedback for social competencies
     Team feedback for technical and skill competencies
    Learn how to and helpful tools

  2. Reduce hierarchical thinking
    a. Throw away processes that the manager usually owned
    b. Let the team take ownership
    c. Implement team review and team approval processes
     Vacation planning
     Team training budget
     Recruiting and onboarding new employees through the team
    Learn how to and helpful tools

  3. Break with old (or common) rules
    a. Throw away old processes for salary raises/adjustments
    b. Standardize and objectify salary adjustments procedures
    c. Build them on team feedback and benchmark reviews
     Team Bonus
     Merit Money
    Learn how to and helpful tools

avatar for Maike Goldkuhle

Maike Goldkuhle

HR Business Partner, Avira
I worked as Global Director of HR at a company that decided to transform their classical working technology teams into agile working and cross-functional business teams. During this transition the CTO decided to take out all manager roles of the newly set up teams. During that time... Read More →

Thursday May 25, 2017 11:00 - 12:00 CEST
Belvedere 12th Floor

11:00 CEST

Creating an Agile Learning Experience for 200 Managers
Introducing agile methods into teams is a relatively well known process. If you give people a lot of freedom, support them with trainings including material teams can book, and allow communities of practice to grow and flow and exchange experiences, then Scrum and Kanban teams will spring up everywhere and will try to get better continuously by improving and cross-learning. Getting the managers into the same boat is much more challenging: in their daily work, they do not constantly experience the difference between the current state and previous state, so they are prone to fall back into old behavior patterns. Last year we organized an event for about 200 managers of our product development organization, intended as a wakeup call for the development organization. The event was planned and facilitated with the massive help of the in-house agile community, and was rated “the best event ever” by some of the participants. By doing this, we helped managers to start moving into an agile direction and prepare themselves for the changes to come. This is a mix of a short talk about our event, its goals, methods and outcomes, and a workshop on exchanging what others did in this respect, what worked elsewhere, and how you would go on with this target group. Target group are people who have at least started to facilitate agile transitions, working with managers and teams.

avatar for Christina Busch

Christina Busch

ScrumMaster, Agile Coach, DATEV eG
avatar for Andrea Heck

Andrea Heck

Agile Coach, Datev eG
Andrea has been working as an Agile Coach for the development organization of DATEV eG for nearly two years. She facilitates large scale transitions, communities of practice and learning on all levels. Her superpower is keeping the topic of change constantly on the agenda. She... Read More →

Thursday May 25, 2017 11:00 - 12:00 CEST
Ballroom B 1st Floor

11:00 CEST

Driving Customer Collaboration by Linking Vision to Team Execution

At Intel, we are faced with some hairy challenges: how do we create a clear line of sight from the highest levels of strategic vision to a concrete expression of a feature? How do we effectively prioritize work across the portfolio so we can allocate resources appropriately? And how do we make the voice of the customer come alive in the backlog to deliver more compelling products?

Our approach has been to progressively refine strategic value through a set of interactive, light-weight workshops translating executive intent into concrete work. By including a cross-functional set of executives at the start, defining an economic framework, identifying the job to be done and facilitating more conversations and interactions at different levels of the organization, we've been able to spend less time on non-value added activities and more time on product development. Along the way, we were able to reduce organizational WIP, understand what's really important to our business and ultimately create a more engaged organization.

This talk aims to give you a practical view of how we go from portfolio-level vision to team execution. Through a series of targeted, light-weight activities, this talk gives you a taste of each of the activities we leverage and how we get compelling results. Along the way, we'll illustrate the problems we faced, show how progressive refinement across our portfolio helped us solve them and demonstrate the benefits we gained as a result. 

At the end of this session, you'll be familiar with a set of tools and practices that will help your organization align strategy with execution. You'll do more of the things that matter and less of the things that don't. Albeit not a silver bullet, an intentional approach to progressive portfolio refinement supports business agility across the enterprise.

Thursday May 25, 2017 11:00 - 12:30 CEST
Ballroom D 1st Floor

13:30 CEST

Marriage of UX and DevOps

UX and DevOps: 2 movements that still don’t understand each other. Don Norman and Jakob Nielsen say “In order to achieve high-quality user experience in a company's offerings there must be a seamless merging of the services of multiple disciplines, including engineering, marketing, graphical and industrial design, and interface design.”

They both want to be driven by customer insight, not guesswork; to be the subject of continuous evaluation, feedback, and rapid iteration; to require increasing collaboration among teams; to focus on accelerating release cycles. However, they rarely communicate to each other.

What does continuous UX evaluation look like? How do we meet users expectations? What does it look like to merge UX into DevOps practices? I’ll answer these questions and discuss the similarity of Lean UX and DevOps processes and how they can work together to bring better experiences to end users and team members.

avatar for Virginia Cagwin

Virginia Cagwin

UX Consultant, Slalom Consulting
Virginia Cagwin is a UX Consultant for Slalom Consulting that practices Lean UX methods to help teams gain shared understanding, focus, and communication. Virginia started her design career has a graphic artist working on brands such as McDonalds, Dunkin Donuts and Baskin Robbins... Read More →

Thursday May 25, 2017 13:30 - 14:30 CEST
Ballroom B 1st Floor

13:30 CEST

Scaling Agile Done Right

Scaling up software projects can be quite difficult, especially if it is done focusing on the wrong aspects - most companies give too much weight to formal structures and processes (eg mandating the use of SAFe, LESS or other frameworks), and not enough weight to other aspects that would give a bigger bang for the buck: eg removing friction (providing the right tools for the job), improving communication channels, setting clear goals, delegating responsibility and accountability, etc.

In this session I'll share my experience in successfully helping companies to do the right thing in some quite large projects, and I'll offer some tools that you will be able to use right away in your projects.

The session, among other things, includes:

  • a description of what needs to be done right before scaling up
  • strategies on how to decide when to add new people to a team and new teams to a project
  • things to consider when deciding the structure of the teams (eg feature vs component teams)
  • how to use simple rules to create incentives for the teams to collaborate productively

avatar for Giovanni Asproni

Giovanni Asproni

Lead Consultant, Zuhlke Engineering
Software architecture and design, methodologies (including, but not limited to large scale agile), programming.

Thursday May 25, 2017 13:30 - 14:30 CEST
Belvedere 12th Floor

15:30 CEST

Collaborative Governance in Distributed Agile Organizations

We create organizational structures and processes in order to make better decisions. Having lived with the complex bureaucratic systems in companies for decades, many businesses have started to experiment with delegating the decision making power to lower levels of the hierarchy and are therefore creating more flat governance structures.

We expand our business to new locations to reduce cost and deliver value to customers faster and more efficiently and also benefit from new markets. Having distributed organizations introduces a new set of challenges to how we communicate and work together. Many companies create new structures and processes to address these challenges.

We chose to create software in an agile way in order to build software incrementally and deliver value to the customers in every iteration instead of all at once at the end of a project. Agile software development requires a mindset that promotes servant leadership, self- organizing teams and collaborative organizations. Many companies find it challenging to create the management structure that supports an agile way of working especially when the organization is geographically distributed.

  • How can you in your current role influence your organization to become agile while being geographically distributed?

  • How can you benefit from the distributed organization instead of finding ways to avoid or fight it?

  • How can you create a more collaborative governance in your corner of the business?

  • How can you form a group of influencers inside the organization to drive this change in governance throughout the entire company?

avatar for Molood Noori Alavijeh

Molood Noori Alavijeh

Agile Coach, Softhouse Consulting / Remote Forever
Talk to me about remote work and agile. I believe remote work is the future of work. Therefore I advocate for remote work and geographically distributed teams in the agile world. As an agile coach, I am on a mission to help people in agile organizations to experience freedom... Read More →

Thursday May 25, 2017 15:30 - 16:30 CEST
Ballroom B 1st Floor

15:30 CEST

How We Approached the Disruptive Change of Everything We Were Used to and Felt Safe With!

In 2014, Ericsson split its very large Business Unit Networks in two (still very large) business units, as a response to the fast change the market was experiencing in how the core network products were shifting to cloud based, virtualized technical solutions. Internet of Things also started to take off, with new customer segments and new partners. These are truly disruptive changes, that affects how we do business, how we sell our products, and has a huge impact also on how we develop our products and cooperate internally and externally.
We realized early that in this new reality, we needed a SW Development System that was set up to manage constant rapid change, that was optimized on deliver high quality products fast, and with a healthy balance between aligned and autonomous methods and tools, based on Lean, Agile and DevOps development philosophies as well as Applied Systems Thinking.

This talk is to share the experiences we made while running one of the largest change programs at Ericsson, defining and deploying our SW Development System.
The program, “World Class Development” ended up having executed around 15 different workstreams of different sizes, addressing as many aspects of a modern SW development system, including core flow activities as Continuous Analysis, Continuous Integration and Continuous Delivery and Deployment (what we at Ericsson call Continuous Everything), as well as supporting activities such as Performance Management, Quality Management and Development Environment Management.

You will learn how we attacked the task given: “create a state of the art development model”. How we managed the program inspired by time boxed SW development methods, managed change over a very large operation, including how we worked with deployment over 13 geographically distributed Product Development Units, all with their own level of maturity, technologies, and needs.
Of course we will proudly share what we did brilliantly, but also share mistakes we did, logical/tactical as well as practical.
As we are now running the second phase of our program, WCD 2.0, we will invite for a discussion on the different topics presented, for participants to comment on and discuss what we could have done differently. To help us improve, but also to allow for an active dialogue on experiences.

So this talk is not about managing rapid change in our SW, but rather how we manage rapid change of everything else that help us deliver our SW!

avatar for Jonas Wigander

Jonas Wigander

Change Program Manager, Ericsson AB
Change management, large scale System and SW development, PLM for SW, Continuous Everything and DevOps, Agile and Lean.

Thursday May 25, 2017 15:30 - 16:30 CEST
Belvedere 12th Floor

15:30 CEST

Merge Hells, Feature Toggles to the Rescue

In this age of software eating the world Release Early, Release Often is applicable for everyone and Continuos Delivery is right for everyone. The first step towards Continuous Delivery is having a right Continuous Integration where every commit is integrated and confirms the readiness "to deploy". It is hard to achieve Continuous Integration without Mainline Development or Trunk Based Development and Feature Toggles. The Feature Toggle technique is often rarely spoken even though it is simple.

But feature branching has been popular for long, and everyone knows about the “merge hell”, a common issue because of long-lived branches or infrequent integration. How do you continuously merge, test and release software with great confidence without spending too much time on merging and fixing conflict issues? That is where Mainline development, one of the key practices of Continuous Delivery, comes into the picture and Feature Toggle works in conjunction with the same.

Feature Toggle [also referred as Feature Flip, Feature Switch, Feature flag] is a simple technique which allows you to turn on or off a feature through configuration. Feature toggles give you the flexibility to toggle features in specific environments i.e. turn on a feature in testing or staging servers and turn it off the same in production. This also helps to rollback features, as rolling back is as simple as turning off the feature and deploying.

avatar for Leena S N

Leena S N

Head of Engineering, Multunus
Pragmatic & Passionate Programmer, Lean Thinker, XP Evangelist who hooked into Continuous Delivery. Mother of 2 Lovely Angels.

Thursday May 25, 2017 15:30 - 16:30 CEST
Ballroom C 1st Floor