Digital proficiency is no longer just "nice to have" for banks; it is a requirement for successful customer engagement and long-term growth. In 2010, the company adopted an agile approach to software development and delivery - launching products in rapid iterations and adjusting them based on customer feedback. The shift to agile helped the bank clarify its development strategy and its customer value proposition. It also prompted ING to redefine its employee value proposition by shining a bright spotlight on the high-quality engineering talent required to lead digital innovation.

We've digitized our processes to make transactions clear and easy for our customers. We've invested heavily in channels and touchpoints with our customers, introducing mobile and other technologies so that we can offer our services 24/7, anytime, anywhere. We've invested in analytics and in getting a 360-degree view of customers to better empower them to make important decisions about their financial assets. And we've introduced agile ways of working - in particular, a DevOps model.

If you are interested in learning more about our transformation and vision behind it, this session is for you.

Agile, OOP... are like good hygiene in the kitchen, it results in meals with consistent quality and predictable prep and service times. It doesn't result in great meals nor substantially impact the ROI! Lean Thinking clearly shows that the only way to make a significant impact is to improve the value chain by improving flow. If everyone is following best practices no one has competitive advantage. Major improvements in the value chain depend on continued disruptive innovations. Innovations leverage people and their ideas. We use case studies to illustrate the different business and technical innovations and their impact. We conclude with a discussion of how to build and leverage an innovation culture versus a sprint death march when dealing with high value time to market projects.

Genuine agility is enormously effective in helping us achieve our dreams. The trouble is, Agile has grown into a complex tangle of roles and rituals, frameworks and tools, processes and certifications. We need a return to simplicity. Modern Agile is here to help.

Designed for people in many domains (not just IT), Modern Agile is defined by four guiding principles:

• Make People Awesome,
• Make Safety a Prerequisite,
• Experiment & Learn Rapidly and
• Deliver Value Continuously.

Understanding and deeply practicing these four principles will help you get better results faster.

In this talk I’ll share how these four principles power world-famous companies and how they can help you work with greater speed, simplicity, safety and success.

You have a great idea and you want to build the product and launch it in market as soon as possible. Before anyone else can launch it. Great! But building the product takes time, money and opportunity cost. While building and launching a successful product, several things can go wrong:

• Have you really understood the core problem from the user's point of view?
• Will your users like the user experience?
• Have you validated your core-loop which makes your product very engaging?
• Is your business model flushed out and validated?
• And so on...

So how do you minimise these risks? 

In this 90 mins workshop, you will run some real tests with real users to de-risk yourself and gain validated learning.

Having a clear purpose in both life and work is essential to happiness. And, science and business support this view. Companies with a clear purpose perform better than companies without. Purpose is increasingly seen as the key to navigate the volatile and complex world we live in. And, people with a purpose in their live longer and are healthier. However, finding your purpose, your personal and companies purpose, is not an easy task. In this workshop we discuss what purpose means and key elements of a sustainable and meaningful purpose. We elaborate the four steps to identify the company purpose and how to build your business around it.

As we reflect back on our numerous struggles with making Agile Teams more efficient and operate like well-oiled machines, we are often overwhelmed with wondering how we didn’t learn the lessons faster or earlier.  Life is too short to learn from just our own mistakes – we have to learn from others’ mistakes as well.

In this session, Dipesh will be drawing upon more than a decade of Agile experiences in multiple organizations across nine countries to share stories and challenges of transitioning into an Agile Leader, while also focusing on what we in the Agile community are struggling with most.

There has been a lot written about techniques for creating great Agile teams.  Dipesh will take these theories a bit further, and look into how Leaders can build great teams, not by using a new method or management style, but rather by understanding their own Agile team dynamics and behaviour.  

You will learn about the assumptions and challenges surrounding self-organizing Agile teams and how to build a stronger team of Servant Leaders.

If you are a leader or an aspiring leader of an Agile team, this session will provide clear implications for where to focus your efforts so that you do not worry about the wrong things. You will be inspired by knowing how to establish trust within the teams that is required to embrace uncertainty and ambiguity while confidently making better decisions.

Technical Debt has become a catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code. These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions. What is technical debt? What is not technical debt? Why should we care? What is the cost of misunderstanding? What do we do about it? Doc discusses the origins of the metaphor, what it means today, and how we properly identify and manage technical debt.

By working with some of the most successful tech-product companies, I realised that code is NOT an asset, it's a liability. We should strive hard to minimise code. In 2011, when I started to hack on ConfEngine, I questioned my belief in TDD. I had also started playing around with APL style Array-Programming and Functional Programming. I felt, may be, I was getting a bit too dogmatic about TDD and automated tests in-general. As a thought experiment, I decided to build ConfEngine without ANY automated test. At first, it was really scary not to have the safety-net of automated test (something I took for granted for almost a decade.)

As I scaled ConfEngine without any automated tests, I had certain interesting realisations:

• How to embrace Simplicity and Minimalism WITHOUT automated tests
• Why Throwing Away Code frequently helps you achieve a better decoupled-design and how this helps in better experimentation
• Fear of Refactoring WITHOUT Tests is over-rated (Good IDE and safe-refactoring techniques can take you a long way)

ConfEngine grew from a pet-project to a 8 member product team. It has over 60K users and has done financial transactions worth over half-million USD. And we continue to push forward without ANY automated tests. Its not perfect, but it has certainly helped me challenge my dogma around TDD.

Background: In 2001, I stumbled upon the Test Infected paper. For the next 2 years, I struggled to really apply the test-first concept on real projects. Finally in 2003, I felt that I had fully internalised TDD and was able to apply on almost all projects. Then I started playing around with FIT and FitNesse, using ATDD on some of the projects. In 2006 I published "Avatars of TDD" paper in which I explained various styles of TDD and its design implications. Until 2011, I was a very big advocate of TDD, ATDD and BDD. I still like those practices, however I would not recommend it in all projects.

Getting software released to users is often a painful, risky, and time-consuming process. The practice of continuous delivery sets out the principles and technical practices that enable rapid, low-risk delivery of high quality, valuable new functionality to users. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers and IT operations, teams can get changes released in a matter of hours—sometimes even minutes—no matter what the size of the product or the complexity of the enterprise environment.

In this workshop, Jez Humble presents an in-depth guide to the principles and practices behind continuous delivery and the DevOps movement, along with case studies from real companies and ideas to help you adopt continuous delivery and DevOps within your organization. You’ll start by learning the value proposition and the foundations that enable continuous delivery, followed by an introduction to the pattern at the heart of continuous delivery–the deployment pipeline. The training then dives into the key development practices of continuous integration and comprehensive test automation. These lessons cover change management, agile infrastructure management, managing databases, architecture, and the patterns that enable low-risk releases. They conclude by discussing the culture and organizational change patterns of high performing companies. After taking this training, you will understand not just the principles and practices that enable continuous delivery and devops, but also how they are implemented in high performing organizations. With this knowledge you’ll be ready to transform your organization’s software delivery capability to get high quality solutions to market fast, while reducing the risk of the release process.

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.

As developers, we often shy away from making changes to existing (legacy) code base due to the fear of breaking existing functionality. While we've enough industry wisdom on how to refactor large monolithic applications, its usually hard to find team members, who can champion the cause. For many folks, refactoring code without having automated tests can be scary. And quite often, it ends up being an egg-and-chicken problem, .i.e. to write tests one needs to refactor the code. But to refactor the code, we first need tests. Even if we break the egg-and-chicken problem, where do we start and how do we visualise the progress, becomes a big challenge.

This hands-on workshop will equip you with the necessary tools, technique and skills to confront legacy code. It teaches you how to use various safe-refactoring strategies, while breaking dependencies and writing first few scaffolding tests to guide your excavation. These techniques are very useful to get existing code safely under test for refactoring. You will also learn how to use these techniques in conjunction with TDD to breathe new life into large existing code bases.