2020 used to be far in the future. Today it’s four years away. We no longer need to guess what breakthroughs await us in that magic year, the future is hiding in plain sight. The Cloud, Big Data, the Internet of Things, Virtual Reality. The question is not what the technologies of 2020 will be – that is rapidly coming into focus. The real question is: What’s important, what isn’t, and why? Should you focus on Continuous Delivery? DevOps? How do you get from where you are now to where you need to be? How do you scale? How do you keep your systems reliable and secure? This talk will discuss how software engineering is changed by the emerging digital technologies.

In the last decade or so we've seen a number of new ideas added to the mix to help us effectively design our software. Patterns help us capture the solutions and rationale for using them. Refactoring allows us to alter the design of a system after the code is written. Agile methods, in particular Extreme Programming, give us a highly iterative and evolutionary approach which is particularly well suited to changing requirements and environments. Martin Fowler has been a leading voice in these techniques and will give a suite of short talks featuring various aspects about his recent thinking about how these and other developments affect our software development.

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.

Over the past decade, innovative companies, software industry thought leaders and lean/agile pioneers have discovered simpler, sturdier, and more streamlined ways to be agile.  These modern approaches share a focus on producing exceptional outcomes and growing an outstanding culture.  Today, it makes far more sense to bypass antiquated agility in favor of modern approaches.

Modern agile methods are defined by four guiding principles:

• Make people awesome
• Make safety a prerequisite
• Experiment & learn rapidly
• Deliver value continuously

World famous organizations like Google, Amazon, AirBnB, Etsy and others are living proof of the power of these four principles.  However, you don’t need to be a name brand company to leverage modern agile wisdom.

In this talk I’ll explain what I mean by modern agility, share real-world modern agile stories, show how modern agile addresses key risks while targeting results over rituals, and reveal how the 2001 agile manifesto can be updated to reflect modern agile’s four guiding principles.

In this engaging and high energy talk, Francis Kelly will discuss and explain how SAFe, the Scaled Agile Framework leverages agile best practices, brings in the concepts of lean and principles of product development flow to achieve alignment, transparency and visibility from the teams through the program and portfolio of an enterprise to ensure value delivery and customer satisfaction, all with happy developers! 

Expect a fast paced, high energy talk intended to educate and inspire organizations to go SAFe!

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

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

On Agile teams, collaboration is the way of life. Our leaders want their team members to work closely with each other, have shared goals and even think as one entity. Why? Because we believe that collaboration leads to happier, more productive teams that can build innovative products/services.

It's strange that companies use the word collaboration very tightly with innovation. Collaboration is based on consensus building, which rarely leads to visionary or revolutionary products/services. Innovative/disruptive concepts require people to independently test out divergent ideas without getting caught up in collaborative boardroom meetings.

In this presentation, Naresh Jain explores the scary, unspoken side of collaboration and explains in what context, collaboration can be extremely important; and when it can get in the way or be a total waste of time.

Over the past decade, eXtreme Programming practices like Test-Driven Development (TDD) & Behaviour Driven Developer (BDD), Refactoring, Continuous Integration and Automation have fundamentally changed software development processes and inherently how engineers work. While TDD has seen a great adoption on server side, developers still find it hard to apply TDD for developing UI components.

In code walk-thru where Naresh will build a web commenting and discussion feature (like Disqus) in React.js, 100% test driven. He will also demonstrate how TDD will help us drive an object-functional design to strike a pragmatic balance between the Object-Oriented and Functional Programming paradigms.

Do you want to know the latest on what really drives IT and business outcomes when you're trying to rollout DevOps? This is the talk for you. Here, you'll find out that the best IT performers have the highest throughput and reliability while contributing to their organizations' profitability, productivity, and market share goals. You'll also find out what the industry is doing in things like security and containers, and a deeper look into continuous delivery and lean management practices, and how these relate IT performance and quality. You’ll love the results. This talk is great for executives and business directors because it will help you understand the value proposition of DevOps and how to achieve the best outcomes. This talk is also great for practitioners because we help you understand the practices that predict high IT performance – and arm you with the data you need to make your case to the executive suite for DevOps and resources.

A common theme runs through conferences, whether focused on MicroServices, DevOps, Lean Startup, or a myriad of other popular topics: Enabling an organization to Go Faster . I explore the need to go faster (which is hardly new), and three areas inhibitors arise: Technology choices, staid business Processes, and traditional Organization structures and roles. For each, I cite personal experiences in overcoming each.

Your app is a unique snowflake. Your tests are too… but they shouldn't be!

You know the person on every project team who cares just a little bit more about testing than everyone else? This talk is a distillation of the lessons learned I've learned from being that guy on dozens of projects.

This is a rapid-fire session that covers 15 systemic problems that plague most teams' test suites, presented form an angle you probably haven't considered before. Best of all, it'll equip you with preventative measures to avoid or mitigate each of them.

Automated unit testing is commonly considered an essential part of writing reliable, bug-free software. But writing automated tests introduces a number of challenges of its own. Naively-written tests are complex, brittle and hard to understand. This increases their cost-of-ownership and reduces the value they provide.

In this talk, Gerard Meszaros examines some of the key pitfalls and shows us how to improve the quality of our automated tests. He shows us how we can make our tests shorter, clearer and cheaper to prepare by refactoring a long, complex test into a short easy-to-understand test. Then he goes on to show how we can apply the same concepts to writing new tests quickly and cheaply.

Test automation is a core enabling practice on Agile projects. But test automation is difficult! Most applications are not designed to support easy test automation. Join Gerard as he leads us through applying Systems Thinking to understand why our current way of organizing our team roles and responsibilities may be the root cause of this difficulty and what you can do to address them. (Spoiler alert: the problem is trying to automate tests after the software is built!) He provides examples of good "executable specifications" that can be used to drive both functionality and testability into the application. And he describes the life-cycle of an executable specification starting with a feature idea, progressing through a non-executable example all the way to a satisfied, executable example.

What do these items have in common? Most speak of cross-functional collaboration, and a few outright refer to XP as the best set of current working technical practices. This talk assumes you've got the XP/Scrum iterative development engine running, maybe even with DevOps and continuous development going.

What’s next? Wouldn’t it be worthwhile to talk to people that will use the solution? Even on some internal thing like a Salesforce integration? What outcomes really matter to your users? Given that unused features (which there seems to be lots of) provide no value, what’s the least amount that can be done to assure what gets released, gets used?

The Scrum/XP development engine is the delivery track. How you’re learning to quickly deliver the right outcomes, the fuel for that engine, is the discovery track. Coined by some as Dual-Track Scrum, these tracks are meant to run in parallel for each and every Scrum team, all the time.

Why would you want to do that? As one CTO in the health care industry put it to me, he had a few people on a product innovation council, and has a few hundred in product development. Building more, at a faster rate, with Scrum to him seemed a waste of time if nobody used it. Ideas were also stalling in the council’s New Product Introduction process. He saw dual-track as a better way to serve the customers and their needs.

Discover the possibilities of Agile Marketing and the power of applying Agile outside of IT. We’ll explore a case study of Agile applied to Marketing and discuss the benefits of aligning your organization’s use of Agile across departments along with the mindset shift necessary. Instead of focusing on who you can sell to, the focus is shifted to truly connecting with who needs your product or service most while leveraging rapid iterations for maximum output. Discover the value of split testing, inspecting and adapting, and applying an iterative process to your Marketing department. Agile Marketing allows you to adjust your focus and streamline your company processes aligned with Sales and Marketing to attract and service your ideal clients with exponential results.

To get full benefits of continuous Delivery, all components of the software being developed need to be delivered at the same pace. Components of the software development like databases need different techniques to be managed . Techniques that that would have to cater to changes being deployed to the database along with code and at the same time be enable the database to handle multiple versions of the application software.

Agile meetings do not always go smoothly. Especially when you work in a geographically distributed team or get moved from one team to another. How can you discover what might be going on when things go awry? This session will have a brief simulation of a meeting. Three volunteers will play agile roles with typical challenges we experience. As a group we will share observations about the interactions, and what we thought we understood, but may not have. This session introduces the Satir Interaction Model and a broader understanding of how we might correct mis-interpreted behavior and commenting. 

Agile transformation means introducing change. If you work for an organization that hasn't changed in a while, introducing new approaches can feel like a lot of work and even more pain. This applies to any "not fully” or “not quite agile" organizations. Large IT groups often fall in this area, but it can happen anywhere when change is scary or seen as a high risk in the culture. This session introduces the Satir Change Model of human behavior with the addition of choice points and ways you can intervene. Change can trigger chaos, yet choice offers opportunity. Where could you look for new options? How can we guard against reverting to old ways and move to new learning and practice?

At Stack Overflow, we are a remote-first company. That means no matter where you are in the world, if you are a great developer, we want to make sure you’re treated just like you’re in our headquarters in New York. How do you build agile teams when most people are remote? We take this to an extreme: get my first-hand account of what it’s like to work full-time as an engineer at Stack Overflow traveling to 22 cities in 7 countries in three months. You’ll learn what it means to build a truly remote culture, what tools we use to make it possible, and how we do standups, iteration, and communication in a truly international engineering team.