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.

There is growing interest in learning more about Agile HR and its impact on individuals, teams and organizations.

It is important to separate fact from fiction: What are the real threats and opportunities of bringing Lean | Agile values, principles, and practices to HR? What can we expect in the future? Through anecdotal evidence and case studies, the session will explore the potential of Agile HR as well as provide guidance on how to approach the transformation.

 Issues covered in the presentation include: information on how to embrace the new talent contract, create inspiring, engaging, and fun places of work, shift to an iterative performance flow, take the issue of money off the table, support growth within an Agile enterprise.

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.

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.

Mob Programming is a development practice where the whole team works on the same thing, at the same time, in the same space, and on the same computer. It is a whole-team approach to doing all the work the team does including designing, coding, testing, and working with the customers, users and other stakeholders. This is an evolutionary step beyond pair programming and accentuates face-to-face communication, team alignment, collaboration, and self-organizing team concepts of the Agile approach to software development.

Mob Programming can be a highly effective approach to software development. There are numerous teams doing Mob Programming all over the world, including distributed teams, and there has been a great deal of positive reports of success. Please join me as I share how the concept got started, the benefits, techniques we use, and some of the problems we've faced.

[email protected] is about a lot of things. For example purpose, culture, autonomy, personal grow, attention, fun, flow, results, being yourself and friendship. How are you doing when it comes to your happiness at work? This workshop is a 90-minutes fun experience by playing the ‘serious’ game ‘Choose [email protected]’.

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.

Are you frustrated by the many trivial examples that show up when you google "refactor legacy code"? How do you translate these examples to your real-world code base? Sometimes it's just easier to give up on the refactoring and increased test coverage, reserving these techniques for the ever elusive greenfield project. To help you with this dilemma, Nayan will walk through a real legacy Java code base, and perform some safe refactorings required to bring the code under test. All of this will be done under the guidance of the Four Rules of Simple Design (Pass the tests, DRY, Reveal intent, Minimize moving parts).

[Update based on the panel review]

Inspired by Martin Fowler's introduction to micro services (https://www.youtube.com/watch?v=wgdBVIX9ifA);

The demo will introduce the "ABC"s of the transition to micro services. We will refer to the Hadoop Distributed File System open source and demonstrate to (re)design the NameNode module as a micro service. This will introduce the three primary challenges and their possible solutions as in;

1. Componentize using Services instead of the conventional componentization using the design

2. Data segregation using an event driven framework to separate the centralized data across services

3. Accessing a micro service as a web service instead of an orchestrated access; the delegate & facade patterns will be demoed to loosely couple the interfaces

The demo will conclude with a listing of the next steps in transition, which need to be considered after the primary challenges are addressed.

"The higher you go in an organization, the more your suggestions become interpreted as orders." - Marshall Goldsmith

An Architect garners a high level of authority by being an expert. People will follow their lead. But what if the Architect is wrong? They will follow right off a cliff.

How do we get people to think like the Architect? Use the principles of Intent-Based Leadership to decouple the success of your project from the personality of the architect. By creating clarity around architectural goals and by engaging people in problem solving rather than defining rules and standards we can divest control and create an organization of leaders.

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.

In his book “Understanding the Four Rules of Simple Design”, Corey Haines lays out the basics for getting people together for a day and practice coding better. Unhappily, many of us have to deal with legacy code in our daily lives, and find ourselves frustrated when we try to make legacy code better. J. B. Rainsberger has started a variation on on Corey Haines’ code retreats, making them more practical for legacy code practitioners. I’d like to extend that pattern and have retreat for those of us who work legacy code in Java often.

We will learn and practice the classic Michael Feathers dance of

1. Identify change points
2. Find an inflection point
3. Cover the inflection point (break external dependencies, break internal dependencies, write tests)
4. Make changes
5. Refactor the covered code.

By the end of the day, in addition to being tired and completely ready to put away our laptops forever, we will have gained valuable insights and practical experience with a topic no one likes to talk about - getting better working with legacy code!