Agile is not just a process change, its a mindset change for most. With faster time to market, better feedback and highly functioning teams, the Agile mindset opens our eyes to a better way of working as humans on large complicated and complex problems. Combining it with the concepts of Lean Startup, delivers another leap in team capacity and capabilities. It also opens the possibilities of using agility for more than just software development.

Do you wonder how can we drive innovation in a disciplined way to tame our world's toughest problems? Can we apply the lessons learned from Agile and Lean Startup? Over the past three years, we've been able to apply agility at a new level, beyond business impact. Through our corporate social responsibility effort, "Rally for Impact", we aim to apply the agile mindset to mobilize citizen engineers to serve our communities and protect the planet. I want you to consider this growth path for yourself and your agile teams.

Let's open the worlds mindset to a better way to empathize, explore and execute in these complex times.

A culture is the set of shared attitudes, values, goals, and practices that both describes and shapes a group. The unique challenges of creating software have demanded totally new types of corporate culture. In response, we have created Agile, Scrum, and XP and many other cultural disciplines. These represent the birth of culture engineering and, although significant, are primitive compared to what will follow. Jim McCarthy introduces "culture hacking," a kind of cultural engineering that focuses on protecting personal freedom, extending openness, and embodying rationality. In the near future, a system made up of shared commitments and interpersonal protocols for hosting cultural innovations is likely to become available and standardized, leading to enormous personal and collective cultural and productivity gains. Happily, these gains will be based on culturally designed nobility of purpose, and a potent and virtuous cycle will continue to emerge, whereby profit derives from ennobled behavior. This cycle will lead to an era of widespread and abundant greatness - an era of unparalleled magnificence.

In 2002, Secretary of Defense Donald Rumsfeld introduced us to the concepts of known knowns, known unknowns, and unknown unknowns. But he left out Unknown Knowns, things that we know without knowing it. And it turns out that these Unknown Knowns are actually the biggest category of knowledge - tacit knowledge.

As developers, we work with knowledge: knowledge of the problem domain, knowledge of our tools, knowledge of our techniques, and knowledge of each other. So getting good at accumulating tacit knowledge is important.

This talk will look at how we are poorly served by most of the current ways we are taught to be better developers. Can we do better? Only if we stop talking and start showing. Let's see why.

A major challenge in agile development is the ability of test teams to keep pace with ongoing development while simultaneously ensuring that new development has not created regression failures. This case study from Halliburton shows how together with two globally distributed outsourcing partners they developed a comprehensive test automation strategy for their agile teams that effectively leveraged both in house and outsourced activities. This approach resulted in a significant quality improvement from prior releases.

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.

One in three women will be raped or beaten in her lifetime. Half of the seven billion global population are women so that means one billion women alive now will, or have been, beaten or raped or beaten. Women and children are disproportionately affected by war and occupation as well. And yet numerous studies illustrate how uplifting women's work and leadership can strengthen the whole society and economy. Women are at the forefront of global campaigns challenging militarism and violence, and working to redirect resources into health care, education, green jobs and other life-affirming activities. What can we learn from these women and their successes thus far? How can the technology sector support this crucial work? How do these social movements stay agile to rapidly respond to breaking news while building a long-term progressive movements for deeper social, economic and environmental justice? As Arundhati Roy said, "Another world is not only possible, she is on her way. On a quiet day, I can hear her breathing." In this talk, Rae Abileah will share visionary examples of women-led work for peace and justice and explore the paradigm shift needed for equality, human rights, and justice for all.

Most products fail. Not because we fail to build what we set out to build, but because we waste time, money, and effort building the wrong product.

In this talk, I'll share our lean product development process that utilizes continuous customer feedback loops to ensure you don't go astray and instead build products people (will) want.

What you'll learn:

- How to track your your feature lifecycle on a validated learning kanban board
- How to use qualitative testing techniques for early validation during the design and test phases
- And then follow up with cohort based quantitative metrics to verify you have built something people wanted.

The fundamental problem with software methodologies is that none of them work. What's decisive is not which one you adopt, but what you do to continue to innovate around your processes. In this wide-ranging talk, I'll discuss why command-and-control leads to risk management theatre, and why this makes things riskier and more painful. I'll present the essence of innovation culture, how it works at scale, and present some tools (including the Improvement Kata) to help you think differently about how to grow great software.

As the popularity of Agile methods have grown, so have the misconceptions or myths associated with Agile also grown. These myths get even more glorified when we talk about them in the offshore or distributed context. And to make matters worse, you can throw in a fixed-price contract spanner into the engine.

Worry not! In this fun-filled activity, we'll collect facts from the participants that they believe are true and then we'll declare them as confirmed or busted after an interactive (heated) discussion.

Estimating software projects has proven to be particularly challenging. Over-running schedules happens frequently in our industry. Todd will look into some of the reasons for these challenges by exploring a number of myths of software estimation and then setting out to validate or bust these myths.

Software projects are known to have challenges with estimation, uncertainty, risk, and commitment - and the most valuable projects often carry the most risk. Other industries also encounter risk and generate value by understanding and managing that risk effectively. Todd Little explores techniques used in a number of risky businesses - product development, oil and gas exploration, investment banking, medicine, weather forecasting, and gambling - and shares what those industries have done to manage uncertainty.

Projects were invented as a vehicle for managing civil engineering projects. But software has completely different characteristics from, say, a bridge. In this talk I'll explain why the use of projects causes significant dysfunction, and how to build innovative products and services at scale based on lean principles.

Everyone has acronyms, mnemonics, and a list of rules to guide their everyday software design. In order to get the most out of these age-old gems, one needs to deliberately practices them. Rules are a good way to remind ourselves of these gems.

Corey Haines emphasies his design guidelines in form of the "4 Rules of Simple Design." Attend this talk to understand the four rules and their importance in everyday programming.

10 years ago I was introduced to Extreme Programming. Since then, I've been an avid practitioner, applying the techniques and values to my life as a software developer. Over that time, I've bounced between many extremes, learning and reflecting on the value that I get when building systems both for myself and for others.

In this talk, I'll share some of those learnings and how my life as a software developer has changed with the times.

There are as many types of agile coaches out there as there are flavors of ice cream.  And, their levels of leadership maturity and skill can vary just as widely.  It can leave one fretting, "What am I really getting when I bring in an agile coach?  And, how do I 'grow' my own?"  In fact, what are the "must have" skills of an agile coach and how can you tell if your coach has them?  The Agile Coach Competency Framework is one big clue to answering these questions. Over the past two years, this framework has guided the development of hundreds of agile coaches. Agile managers and champions also use it to obtain "truth in advertising" to hire the right coach at the right time.  We will explore this framework and provide lightening-talk-style case studies that showcase how it has been used in the real world.  You'll leave with ideas and actions to help you become a more savvy purveyor (and/or developer) of agile coaches.

Creating a Global Engineering Culture

Scrum, XP, and Kanban have been proven to provide step changes in productivity and quality for software teams. However, these methods do not have the native constructs necessary to scale to challenges of building enterprise class software systems. What the industry desperately needs is a solution that moves from a set of simplistic, disparate, development-centric methods, to a scalable, unified approach that addresses the complex constructs and additional stakeholders in the organization- and enables realization of enterprise-class product or service initiatives via aligned and cooperative solution development.

In this talk, Dean Leffingwell describes how to accomplish this with the Scaled Agile Framework, a publicly - accessible knowledge base of proven Lean and Agile practices for enterprise-class software development. He approaches the problem from the perspectives of Lean thinking and principles of product development flow, illustrating how these core principles help deliver business results at scale, while keeping the development system - and the enterprise - lean and responsive to rapidly changing market needs. And since winning is more fun, he’ll also describe some of the personal benefits that come when teams master the art of delivering better enterprise-class software, at an ever faster pace.

It is easy to envision a more Agile enterprise, yet we have found as a community it is quite difficult to accomplish. The transformation process goes on in many dimensions and unless we have a framework that helps us see from each of those perspectives, our efforts are much more likely to fall short. Based on Michael Spayd's upcoming book, Coaching the Agile Enterprise, this session will (literally) walk you through each of the four fundamental perspectives and the power and limitation of each. We will explore together approaches that are suitable to each perspective and how to activate them in your team, division or organization.

Experimentation and the scientific method are very valuable for validating business opportunities. The Lean Startup and Lean UX are driving new thought patterns in the software development world. However, despite all the new thinking on product, rarely do organizations apply these techniques to their processes, opting for inefficiently adding more steps ad nauseum until productivity has ground to a halt. We’ll cover the following topics:

• What are processes, and why do we need them
• How processes affect delivery and productivity
• Scale and process inefficiency
• Process experimentation techniques
• Designing productive processes

Do you adopt Agile all at once or one step at a time? What do you do after your adoption finishes (does that question even make sense)? What result should you expect at 30, 90, and 120 days? How do you get that? Is TDD the same on 20 days as at 360 days? Does it differ only in skill, or is it a completely different practice? We answer all these and a lot more. We show what you should expect for the first 2 years.