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.

Who says you need "stable" teams in order to build a successful software company? While the addition or removal of one person from a team means you have a "new team", there is a myth out there about "stable" teams. When your team compositions change it doesn't mean you're doing it wrong - it could be the secret to your success. Different companies have thrived through reteaming - the act of moving people around teams in different ways. In this talk I'll go over the what, why and how of reteaming and will share stories from different companies who are living this reality.

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.

There are now several frameworks designed to address the demand for “big agile.”

In this talk Jez will explain the flaws in such frameworks, why they so often fail to produce the desired effects, and what we should do instead. He will also address some common organizational obstacles to moving fast at scale: governance, budgeting, and the project paradigm - and discuss how to address them. Warning: this talk will include liberal use of real, statistically sound data.

Many people agree that one important outcome of Behavior Driven Development is a set of regression tests to demonstrate the desired behavior and ensure that it is maintained over time. Then they often struggle to do so in a manner that remains maintainable as the system and the test code grows larger. Sometimes they even abandon their tests and start over, repeatedly.

In this session we'll examine the evolutionary history of an application and its test suite. We'll stop at various stages in its life to consider the choices we might make to address growing complexity.

We'll work using Cucumber-JVM and Java in order to be accessible to a large audience. You can apply these concepts in other languages and test frameworks. Rather than depending on having enough laptops set up, we'll use mob programming to enable everyone's participation.

If you'd prefer exploring on your own machine, bring your laptop loaded and ready to go.  Clone the code repository from https://github.com/gdinwiddie/EquineHoroscope to get the code and its history.  Unzip http://idiacomputing.com/pub/EquineHoroscopeJars.zip in the same directory for the dependencies.  (Download sample at https://leanpub.com/EvolutionaryAnatomy/ for even more detailed instructions.) I'll be using Eclipse, and the instructions are tuned for that, but you can use any Java IDE.

Bonus: Participants will receive a coupon for a free e-book on the material.

Better. Faster. Cheaper. Many IT organizations are constantly seeking the "best" practices that will deliver those characteristics, and the fact that they continue to search indicates they haven’t found them yet.

It could be they are looking in the wrong place. Most efforts around achieving better, faster, cheaper center around becoming ultra efficient.

Effectiveness may just be the better target.

Join Kent McDonald to explore the difference between efficiency and effectiveness and learn three simple, yet powerful, techniques that he has found can help teams be more effective. You’ll learn how to:

• Build a shared understanding of the problem you are trying to solve
• Establish clear guard rails for distributed decision making
• Measure progress based on outcome, not output

Along the way he’ll share stories about how he has used these techniques and help you figure out when these techniques may work in your situation.

You may be able to get faster and cheaper with efficiency, but in order to get better outcomes, you need to be effective. Come to this session to learn how.

As with everything else related to agile, the nature of the Product Owner role, and whether it is needed or all, depends a great deal on context. As teams discover this, it leads to some common questions:

• What do Product Owners Really Do?
• Do we even need Product Owners?

Join Kent to examine the Product Owner role and attempt to answer the above questions. He’ll  share his experiences and give you a chance to share your perspectives with each other. By the end of the session, you'll have more insight into the Product Owner role and how it applies (or not) to your situation. After all, the only consistent answer to the above questions is “it depends”.

As companies introduce agile practices, the Business Analyst role is often left by the wayside. The title does not even exist in Scrum or other specific agile implementations, leaving many Business Analysts wondering where they fit in. But fear not! The skills of a good BA are even more valuable in an agile environment!

Join Diane Zajac-Woodie as she tells the tale of a new agile team, struggling with no formal training, a resistant corporate culture and unwilling team members. She shares how this team benefited from the communication, collaboration & facilitation skills of an experienced BA. She then highlights specific shifts that Business Analysts can make in order to help their own team’s transition. These include using story maps and writing executable requirements, just in time.

Embracing their new roles, BAs can also encourage team members to cross role boundaries. This leads to new skill acquisition and a more cohesive team, which ultimately leads to higher quality software.

“Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime.” ~Proverb

You might have heard of IDEO. IDEO is known as a pioneer of human-centered design or putting people at the center of their work. This approach has come to be known as Design Thinking. Design Thinking in a nutshell is about empathy, experimentation and learning fast.

When we think of an agile transformation, we don’t necessarily think of human-centered design. Most agile transformation I have seen begins with an enthusiastic leader (most likely in Technology) who is trying to change the culture and shift the mindset to improve product delivery and time to market. In the quest to do this, the leader might mandate certain practices for the organization to start doing. This can cause a lot of pain and heartache in the process and usually lead to mere results and disengagement.

What if there was a way to unlock creativity and critical thinking across the organization? This is where design thinking can help in accelerating an agile transformation.

“Success is not delivering a feature; success is learning how to solve a customer’s problem.”  ~ Scott Cook, founder of Intuit*

If this is true, then the next question is: what is your customer’s problem? Unfortunately there’s no magic trick to figure out what customers need. But there is a simple technique that can help you gain insights and build empathy for them.

Empathy mapping is a simple activity that you can facilitate with stakeholders (or anyone responsible for delivering products and services) to build empathy for your end users. It allows you to explore what your customers see, hear, say & do, as well as consider what they think and feel. This leads to insights about their pain and potential wants.

Because this is done collaboratively, using silent brainstorming, everyone on the team contributes to a shared understanding of the customer. So not only do you build empathy, but you also create alignment within the team and among stakeholders. And that can only help you be more successful. 

*as quoted in The Lean Startup, page 66