The way we’re working isn’t working. At best, people act with chaotic complacency, at worst creative problem solving and critical thinking are punished - resulting in burnout, anxiety, depression, apathy, helplessness, and hopelessness. In short, not for humans. Our businesses, organizations, departments, teams, and people cannot innovate, adapt, or evolve. 

Today’s leadership and organizational norms limit peoples’ ability to make valuable contributions.  We are at an inflection point where we each have a choice.  The future holds promise! The path forward? Together, we can nudge towards a System of Compassion.

Technologists created Agile to deliver software more quickly, predictably, and successfully.   Traditionalists argue that agile is for tech-only. 

In this presentation, Alan Zucker argues that Agile is everywhere.  The values and principles are organic and align with natural ways of working.  Its practices are broadly applicable across professions, industries, and business domains.  All organizations, from non-profits to high-tech, can benefit. 

The Manifesto of Agile Software Development presents a set of values and principles for delivering working software quickly and providing value to customers.  Small changes extend the Manifesto and make it universally applicable.  All knowledge work domains and even some traditional ones can benefit.

Agile practices and tools enable and empower all.  Examples demonstrate how practices can be applied to traditional industries such as the military, construction, education, and non-profits.  Agile provides a framework for solving complex problems with creativity and innovative thoughts.  They allow us to harness our energies, improve our focus, and achieve greatness.

Great testing starts as soon as your client comes to you with an idea.

Good testing uses TDD, BDD, Automation, and other accelerators. Great testing starts in the way we think about the new Epic, how it breaks into MVPs, how we develop our architecture. The more we think about how to test our solution, the more resilient and robust that solution will be.  Agile tells us to “inject quality” throughout the delivery process. We use testing to demonstrate that quality. The more we craft our solution to make testing easier and more effective, the faster we can demonstrate that quality, and get to production bug-free.  

In this presentation, we’ll talk about “injecting testability” throughout the pipeline. We will explore decisions and techniques in architecture, solution design, data management, and – yes – test environments, that make testing robust, easier, and more effective.

Want to know a secret? That “transformation” your company is working on will likely not be transformational. An even better-kept secret is that it probably doesn’t matter! But, for now, that large-scale, likely-to-fail change probably does impact you.

This session will briefly cover what a transformation is and why they are generally needed. Then we’ll discuss the five main reasons most large-scale change efforts typically fail to meet expectations. Finally, we’ll provide a few tips for surviving a “transformation” and a couple of practical tools that might even allow you to make some use of them!

Language is powerful and can paint a picture, lift people to happiness or dive us into despair.  Transforming our language can be an amazing way to shift our own mindset and that of others. What can you do to change your own internal dialog to embrace a new mindset? Why not extend the same language to help teams and others transform?

In this talk, we’ll cover a variety of language topics that can be incorporated immediately, including:

• Language of a Fixed Mindset, Growth Mindset, and Agile Mindset to enhance Agile Transformations
• Clean Language to help teams uncover root cause issues instead of focusing on symptoms
• David Marquet’s (author of Turn the Ship Around) focus on Leadership Language to help management transform into leaders
• Power Questions to help people see the future and the advantages of Agile transformations

Many individuals who have worked as part of an initiative to implement off-the-shelf systems have heard that agile approaches can’t work - that agile only works when building solutions from scratch or adding functionality to these systems. We believe, and have seen, that agile approaches are actually preferable to traditional waterfall in these instances, and the differences between proprietary and customization of commercially available system development have more in common than not.

Maturity is a leading indicator for Performance which leads to Outcome delivery. We crunched the numbers and analyzed the data across 46,000 team members in our enterprise customers (4,616 Agile teams) and found some fascinating insights on what specific competencies drive high performance. Our team has always believed there’s a correlation between qualitative metrics (defined by maturity) and quantitative metrics (defined by performance or flow). A few years ago, we moved to gather both qualitative and quantitative data. Once we felt we had a sufficient amount to explore, we partnered with the University of Nebraska’s Center for Applied Psychological Services to review the data through our AgilityHealth platform. The main question we wanted to answer was: What are the top competencies driving teams to higher performance?

We analyzed both quantitative and qualitative data from teams surveyed between November 2018 and April 2021. There were 146 companies representing a total of 4,616 teams (some who took the assessment more than once) which equates to more than 46,000 individual survey responses.

The results of our analysis identified the top five input drivers for each of the performance metrics in the TeamHealth assessment, along with the corresponding “weight” of each driver. These drivers are the best predictors for the corresponding metrics. 

By focusing on increasing these top five predictors, teams should see the highest gain on their performance metrics. 

Is your team losing its way during backlog refinement? Does refinement contain “hidden” work difficult to account for? Is a Definition of Ready weakly applied? Do you even have one?

Borrowing lessons from the Kanban method, we look at how to visualize a team’s backlog refinement process using a backlog refinement board – ultimately allowing a team to make work more visible to better meet its Definition of Ready. Benefits include improved understanding of work items, an “unhiding” of work, an appreciation for “where” refinement work resides – leading to greater confidence the work item has truly met the DoR prior to sprint planning.

We’ll examine how to identify the team’s refinement steps, how to turn those steps into a visual board, discuss whether a refinement board should follow the same cadence as the sprint board, and team interaction with the board. We’ll conclude with some real-world examples.

In this session, we will look at estimation techniques that many Agile teams use.

This session starts off by exploring the concept of estimation via time based estimates (such as hours and days) compared to relative sizing (like story points, Fibonacci, t-shirt sizes).  We will explain what relative sizing means and the advantages and disadvantages of relative sizing and time based estimates.

From there, we dive deeper into story points and will conduct an estimation simulation with story points using the planning poker estimation technique.

The session then delves into how to calculate and properly use velocity and how velocity is often misused.

We conclude this session with thoughts on how to stabilize your team’s velocity.  Some teams often struggle with stabilizing velocity and we will walk through a checklist on how to stabilize velocity.  We conclude with techniques on how to get started with relative sizing.

Coming out of this session, attendees will:

1. Understand when to use time and when to use relative sizing for estimation
2. Know how to perform estimation as a team
3. Identify velocity and how to stabilize it
4. Know how to get started with relative sizing

Digital revolution, artificial intelligence, virtual work...change is accelerating. Technology is seen as the key to success. Every company is now a software company. NO! Every company is STILL a people company!

This talk is perfect for team members and leaders alike as it highlights the real differentiator in Agile ways of working, PEOPLE. Through 3 human-centered, transformational stories (Product Team Mobbing, Customer Success Leader Learning Journey, & Marketing Evolution) along with a few interactive exercises attendees will hear how Agile principles and practices are broadly applicable to everything from team building to culture change.

Agile was brought into existence by people that cared, and Agile has continued and evolved because people still care. Agile transcends industry and functional area. It could care less about title or tenure. It does not differentiate between a business that has been around for 10 decades or 10 days. Agile is about connection and community, so let's talk about people helping people.

How might you answer the question “when will it be done?” What about “how long will this take?”

These can be critical questions in helping decide if we should do something, along with starting a conversation with customers and stakeholders.

Since we don’t have a crystal ball, we don’t know exactly what the future holds. But all hope is not lost. There is an option.

Kevin will share an introduction to how flow metrics can be collected and then used to improve predictability and allow for effective forecasting. He’ll share some real-world examples of how powerful this data can be, how it can be introduced within an organization, and how it can be used to help teams improve discussions with their stakeholders and customers.

“I just don’t know what else I can do, man. I’ve tried everything.”

Roger had my attention. The only emotion he'd shown me before now was *I’ve got this, I don’t need your help*. The development team he led just would not deliver fast enough. And, at first glance, it did look like he had tried everything in his power as their manager.

But before long, Roger's team became known for their quickness, all but erasing their old reputation.

Wait, what happened? Come hang with me for an hour, I'll tell you all about it.

Software is a game of insight. And stories are the best way we have to share our insights with each other. By sharing them, we elevate our work, our industry, and our lives as software professionals.

I've got stories to tell you about the teams I've worked with. You'll see yourself and your team in theirs. You'll ride the ups and downs with them from the safety of your chair. You'll walk away with the lessons they lived. And you'll probably realize how many stories you have to tell, too.

In 2014, Ron Quartel had a vision of teams using processes based on Open Space Technology to self-organize around work.  Starting in 2016, I was part of an amazing experiment of 40+ people who self-organized and dynamically reteamed around our work, using two-day iterations to produce amazing high-quality applications for a large healthcare insurance company.  Our process became what is now called Fluid Scaling Agile (FAST).

In his book, The Art of Agile Development, James Shore called it: "One of the most promising approaches to scaling I've seen".

Let me share why it was the most amazing, highly productive, cohesive team that I've ever been on, and the lessons that I carry to every team since.

In many organizations product ideas often lack customer or business validation. Products or features tend to be a manifestation of a HiPPO (highest paid person’s opinion) or blind feature matching of a competitor. Likewise, product strategies are often pithy phrases, uninspiring targets, or contain too many goals to be actionable. Neither of these needs to be true! Using lightweight, evidence-based approaches that guide product discovery with demonstrable outcomes is key to finding customers and generating business value. Once a product idea has been refined, a well-designed and deployed strategy will provide focus, alignment, and purpose for an entire organization. Attendees will be introduced to key concepts and provided with practical tools that allow product leaders to guide product discovery and create meaningful product strategies. Participants will be introduced to a Product Strategy canvas that focuses on the deployment of a successful strategy.

“We don’t have time for learning but we want to deliver value fast. And by the way, we need to develop new skills and attract talent but we have limited to no budget!” Huh!

The culture of the Agile community is based in part on an ethos of responding to change and growing to meet new challenges with innovative ideas and structures.  However, this fast paced environment can lend itself to a proliferation of jargon and buzzwords, unfamiliar and meaningless to those who aren't in the know.  In fact , it's this use of language that tends to create such strong divisions between people in corporate settings, creating stumbling blocks for those trying to move quickly.

By identifying the difference between language that doesn't drive value and the words that do, understanding that people can become divided through this type of speech, and ultimately settling on a more simple, direct, and honest conversational style, you can turn a confusing conundrum into an opportunity for cohesion and community.

There are a lot of companies talking about or working on becoming a “Product Organization” - but what does that really mean? How do structures, roles, responsibilities, and key business processes change? What are the impacts on a company’s operating model or overall organization design? If you have similar questions, you’ll probably enjoy this session!

This session will provide a practical definition of a product organization and contrast it against other common organizational modes. Next, we’ll explore the many terms and concepts used by proponents of product organizations. Then we’ll go a little deeper into some major changes to the organization design, specifically how strategy, structures, roles, portfolio, and key processes. Finally, we’ll wrap up with some of the typical pitfalls that can have a negative effect on becoming a product-driven organization.

The world is changing at an incredible pace. The way we learn, the way we work, and the way we communicate are all changing. The way we learn is changing from books to video and from audio to text. The way we work is changing from traditional offices to flex offices and from being on-site to remote.