Click on a workshop/session title to open up the detailed description.
For registered attendees, the latest schedule - and any changes to it - will be published in the accompanying Whova app.
All times are based on Phoenix, Arizona and given in Mountain Standard Time (MST).

What comes after Management 3.0, SAFe, and the Spotify Model? Well, it's not hard to see in which direction the world is moving: organizations that consist of networked individuals who work from anywhere, who form teams on the fly, who aim for objectives and achieve results, and make that a whole lotta fun for themselves. Such an organization can do anything!

That dreaded "we need to figure out what happened to hold people accountable" meeting is approaching, which often means people are getting their fingers ready to point. When working with humans, blaming never leads to accountability. What blaming will lead to is a loss of focus and waste of time towards the shared goal of delivering value. In this session, Tricia Broderick examines what blame in the workplace really means, the impacts of blaming and better alternatives to accomplishing accountability.

Let’s see if this sounds familiar:
You attend a retrospective where most of what comes up is a shout-out or win. If there are any topics for improvement they are largely related to external factors and fall into a “safe” category. Additionally, it is difficult to identify meaningful action items. These toxically nice retrospectives may even be painful to attend.

Most of us prefer to be nice and generally that’s a good thing. However, when our teams shift into this “toxically nice” category everyone loses. We lose our sense of empowerment, autonomy, ability to make decisions and so much more. As agile advocates, scrum masters or leaders we are ideally positioned to change this culture.

Walk away from this interactive session with an understanding of what “toxic niceness” is and new tools to empower you to change the outlook of your team.

Anti-fragility is a concept initially coined by Nassim Taleb, and its definition is deceptively simple: it means "the opposite of fragility." In other words, anti-fragile becomes more powerful when exposed to volatility, randomness, disorder, and stressors. You are an anti-fragile system if you become more assertive when everything around you is getting chaotic.

Kurt will share some real-world examples of how he applied these concepts and how you can apply them to your life and work as well. In this session, we will cover:

- What antifragility is and why it's important

- How to create personal resilience for both stability and growth

- How to use anti-fragile techniques in your career or business

- And much more

By adopting a "fail forward" attitude, we're able to bounce back quickly and prepare ourselves for future successes.

Becoming antifragile is all about learning to embrace volatility, randomness, disorder, and stressors so that they strengthen us over the long term.

Dwight Eisenhower said, "planning is everything, the plan is nothing."

One of the main things that the agile movement has taught us, is that no plan goes according to the plan. It is important that we organise, review and adapt the plan as changes occur.

With the current global health crisis many organizations have found themselves suddenly outside their plan, leading them to review their current way of working and adapt to a new way of working: remote work in agile.

Usually such large scale organizational changes are strategically planned, carefully designed and methodically implemented with help from experts. The recent transition to remote working however has happened so quickly and with so little time for deliberate planning and adjusting that the change may have created some level of added tension and chaos.

Working remotely might seem at first as simple as working from a "different" office. But soon - as you probably have experienced - people realize that they have to change the way they communicate and collaborate completely. And for many, this new way of life, the new way of work is proving to be challenging. Most people have never learned the mindset and skill set of remote communication and collaboration.

Molood has founded Remote Forever with the vision of bringing remote work to agile. In this inspirational talk, you will learn how to maintain your business agility while working remotely with the support of a growth mindset. It will challenge some of the assumptions you have about working remotely and will inspire you to upgrade your mindset and get ready to adapt to new ways of communicating with your coworkers. In the end, you will have ideas for actions you can take to be more effective at working agile remotely, as well as having a great time doing so.

My team loves working on legacy code projects. It’s all that we do. That’s why a friend of mine reached out to us for some help.

His startup was building out a universal API across a very fragmented industry with little to no interoperability or standards. Up until now, integrating with the systems in that industry had been pretty easy, because the companies that built them were willing to help.

But now he’d found one that wasn’t willing to help. There was no obvious API for getting data out of the legacy application so that it could be exposed via his company’s API. A big client for his company was riding on his ability to be able to pull this off. He remembered how much I loved a challenge and how much my team loved legacy code, so he figured we were his best shot.

The goal was to be able to read from the application’s database.

In this talk, I’ll cover:

- the different approaches that we took
- the one we really wanted to try because we thought it would be fun
- the approaches that we needed to try before we could attempt the fun one
- the excitement that we felt while working on it
- the grind toward completion once the big technical hurdle was crossed
- the sense of achievement when we got a read-only solution built
- the hope that we’d get the green light to start working on a read-write solution
- the disappointment when the plug got pulled and we weren’t authorized to proceed any further

It was a fun journey, and I’d love to be able to share it.

Has an agile phrase been used as a weapon against you? Have you noticed how Agile phrases get thrown around but fail to ignite a deeper discussion about what they really mean? Many Agile tropes have gone wild causing apathy, mistrust, and in the worst cases demoralization. Ironically, this is the very opposite of what Agilists are intending and leaves them wondering why results are not happening. In this session, expect to unpack several Agile tropes and their harmful impacts through real-world stories. We will examine how message timing and delivery can be just as important as the message itself. Walk away with a renewed excitement and the important part you play in the narrative.

One of the more popular ways to reflect in the Agile world is the retrospective. Unfortunately, retrospectives can become focused on the past, become dull and repetitive, and sometimes get shortened or even cancelled. In this session, we'll explore ways to get the most out of the time the team spends together at the end of each Sprint and completely move away from the idea of looking back at what went well or what didn't go well. There will be breakouts with Mural and you'll be able to try a variety of retrospective ideas including "team coaching," "team with the best results ever," and "upgrades and advantages."

Participants will walk away with a new perspective on how regularly reflect and make real changes, a method for tracking retrospective action items, and a variety of Mural templates they can use with their own teams.

During the height of Covid, I had an opportunity to witness an HR team operating in a manner causing extreme discomfort within the entire organization. Upon deeper examination, I am super grateful for witnessing this huge window of opportunity to overcome by tackling this question “how might we design our HR organizations to serve us in a Post-Covid world?”

Checking your own organization quickly, do you find

- your HR team has an “us” versus “them” mentality and behavior?
- yourself creating your own job descriptions without HR input, or having to create policies and procedures without HR guidance, or perhaps correcting HR errors?
- financial concerns trump actually doing the thing that needs to be done, such as rewarding a deserving employee with a promotion and raise.
- your HR team completely forgets who they serve. (The test of this is how often you hear “how can I serve you?” from your HR department.)
- you find yourself avoiding the HR department like the plague.

If these 5 points resonate with you, please attend this workshop to co-create exactly what we want from our Post-Covid HR departments.

The outcome of this workshop will be the detailed how-to for HR departments, spelled out clearly, so that they can become
- concerned with all employees’ welfare
- proactive - reach out and offer help
- actually serving their teams
- playing a key role in making your workplace the best place to be.

“The job of QA is not just to do testing — it’s to build quality in.”

How often have you heard that sentence? And how often has it been followed up with solid practices for actually building quality in? Test-Driven Development (TDD) is one of the foundational practices of high-quality product development. Popularized nearly 20 years ago, TDD is an important skill for high-quality software development. If you want it to be easier to build high-quality code, then you need to understand TDD.

In this session, Richard will discuss and demonstrate TDD. For those feeling extra collaborative, he'll invite you to run the keyboard by remote controlling his computer as the mob performs TDD. He'll also touch on and relate TDD to other aspects of code quality including refactoring, code smells, and when and why to use mob programming.

Who this for:
- Anyone who wants to know more about test-driven development and how it can help your team deliver awesome products faster
- Team Leaders, Managers, Scrum Masters, Product Owners, and Developers

You’ll leave with an introduction to solid skills, including:
- Technical agility as a foundation of business agility
- Test-driven development (TDD)
- Extreme Programming (XP)
- Refactoring and refactoring patterns
- Code smells
- Mob programming

What people are saying:
- This isn’t just for a developer. It is inclusive to the non-developers to take part in the creative side of coding. -Senior UI Engineer
- I learned many new techniques in just one day that I can use Monday morning when I return to the office. -Pontus Strand, Consultant
- Richard gave us a great hands-on intro to mob programming which really got me thinking–great session! -Will Nicholson, Technical Architect
- A fantastic and uplifting day learning TDD and mod programming. I’ll definitely be imitating this back @ work! -Ben Ansell, Software Engineer
- An amazing opportunity to gain an understanding of Agile technical skills -Darrel Ward, Software Engineer
- Highly enjoyable -Jirawat Utayaya, Software Engineer
- Coding right is more important than writing code. -Richard Crissafulli, QA Engineer

Smart people are logical and objective, aren’t they? They (we) look at the evidence to help make the best possible decisions. We are not influenced by hype or emotion and as a result our behavior reflects the best the world has to offer, isn’t that true? Cognitive science now tells us that these beliefs about ourselves and others (especially scientists) are wrong. We tend to make decisions based on intuition or emotion and then justify those decisions later with logic, a process called rationalization. The most influential element in our environment is not scientific evidence but stories. We love stories. Research shows that we are more likely to buy a product or embrace a process because of a friend, colleague, or relative and ignore evidence that might go against that decision. Are these bad things? Is there anything we can do about it? We have a long history of being influenced by stories and it has helped us survive. Linda suggests that the real answer is we need both approaches -- stories and emotion + evidence and logic. Both approaches have flaws and benefits. Linda will share the research and tell her own stories to try to convince you and try to help us do a better job of making decisions.

Stakeholders have made a request. Features (or components!) are defined. Stories are in the backlog. We are ready to develop our new product. Or are we?

If these are the typical steps your teams or organization takes to build a delivery pipeline then you’ve probably missed key steps enabling Product Discovery and a purpose driven understanding of what you are trying to build.

Product Discovery may appear time consuming and unnecessary, however an initial investment into some practical discovery techniques will help get you closer to building the right product and delighting your customers through a learning mindset.

Join this session to learn why Product discovery makes sense and leave with some simple techniques that can be easily facilitated to invoke thoughtful insights into the why behind your Product.

Is it time to move away from a definition that declares a project must have an end? How do we describe developing software that is under continuous update forever? Agile methodologies can support a never-ending backlog. Are development teams ready to do the same?

We examine continuous updates vs. version releases, advantages and disadvantages of both, and industry directions. You brainstorm with peers about the utility of incorporating additional perspectives into your toolbox and learn how other organizations are accomplishing this. Working with peers and using current research, you create strategies to help your development teams embrace and succeed with this vision of software development.

You go back to your company with fresh insights and new ways to look at when "complete" is not required, and strategies to help your team incorporate this current reality when it is appropriate. You will have research-based information that supports strategic implementation of this emerging trend.

Today, top performing agile teams exist in organizations worldwide. However, in many of these same organizations, those very same teams are hamstrung by legacy bureaucratic management - the remnants of a waterfall approval-based governance approach. Issues with delivery across multiple silios, non-value adding process red tape, and antiquated PMOs persist. So, we continue to struggle with reaping the full benefits of agile methods, and fall short of business agility.

True end-to-end, business agility requires a bimodal approach: continued care and feeding of agile teams done in parallel with a systematic middle-management transformation away from stifling bureaucracy. The Agile Value Management Office (VMO) is rapidly gaining traction as the preferred way to accomplish this through:

· A team of teams organizational construct and approach for light-touch governance

· Adaptive planning and experimentation with small-batch Minimal Marketable Products (MMPs) for end-to-end flow

· Up-front and continuous integration of legal, audit and other business-critical functions for true risk management

Join Sanjiv Augustine to explore how these have liberated managers, unshackled agile teams and resulted in positive customer outcomes. Through key case studies, we’ll see how these have also ensured critical management, oversight, and governance.

Are you a Scrum Master having trouble navigating conflicts? Perhaps you're a Product Owner who has to negotiate scope and timelines with stakeholders. Maybe you're an Agile Coach who desires to improve dependencies across teams. Confronting problems is inevitable in any Agile role. Servant leadership comes with the expectation of influencing and negotiating with others, typically without a position of authority. This can be extremely difficult, especially in emotionally charged or high-stake situations.

In this talk, we present 6 tips for negotiation from the best in the business: FBI hostage negotiators! If you can master the art of influence and negotiation, you can resolve differences without escalating into damaging conflicts, collaborate better across the organization, and help your teams avoid wasted time and spin.

You've seen the promise of Agile done well. Not some hyped up, fairy-tale dream of agile, but some real, meaningful improvement based on applying ideas from the Agile community. And yet, most of the time it doesn't feel like that. People seem skeptical, irrational, or just "stuck in their ways". Great teams get broken up. A key leader moves on to "another opportunity". A promising idea gets killed in the round of budget cuts. In this session we'll explore Parker Palmer's concept of the Tragic Gap, how it's different than Ineffective Idealism and Caustic Cynicism, and why any great leader needs to be willing to stand in that gap every day. Finally, we'll give you a few key tools that will help you build a routine to do this without burning yourself out in the process.

Conflict happens. According to research, as much as some of us may try to avoid conflict, employees spend approximately 2.8 hours each week involved in it. That’s because conflict, though it can be uncomfortable, is an essential part of progressing, bonding, and developing real trust as a team.

Instead of backing away from the potential discomfort or anger involved, what would happen if teams embraced conflict as an opportunity to learn and grow together? We introduce an intentional practice and template for establishing a conflict protocol as a key strategy for navigating workplace conflict. People create conflict protocols so that when conflict arises between them, they already have agreed upon guidelines for communication and practices for addressing the conflict.

You will collaborate in small breakout groups to explore and design the perspectives, principles, and practices your “team” will rely upon to navigate disagreements and effectively address conflict while maintaining healthy relationships. As a result of attending this workshop, you’ll gain tools and strategies to reframe conflict as an opportunity to improve and build relationships, create a safe space to handle conflict, and draft a conflict protocol.

We strive to make good decisions as we work to deliver amid change and uncertainty. Still, it's easy to lose sight of the deeper goals - improving outcomes, reducing risks, and optimizing investments. What should we measure? Are our goals still valid? Are we still headed in the right direction? And, how can we do this at the organizational level?

Through a set of interactive exercises, you learn about the elements of Evidence-Based Management (EBM) and how they improve decision-making in complex situations. Using discussion and the online whiteboard tool Mural, Mark guides your discovery of EBM and its value to you.

In this session, you:
- Learn four Key Value Areas (KVAs) and the balance needed for sustained success
- Explore how empirical loops can be applied to strategic goals
- Re-frame measures as empirical evidence that enables deeper questions for better decisions

Come learn how to make better decisions and continuously improve toward strategic goals and objectives.

Over the last 100 years we have moved from horseback to electric vehicles, from pony express to email, and from industrial age to information age. However, in all that time education remains the same. We sort students by grade level and organize schools in assembly line fashion just like we did in 1920. It is time for education to address the current needs for our students.
By empowering teachers to focus on meaningful outcomes and iterate those solutions we can bring innovative instruction to our students. Through transparency and autonomy students will learn relevant skills and be excited about the experience.
You will be empowered with practical action steps and a listing of resources you can use to encourage agile transformation in the schools your children attend or in the community in which you volunteer. The team also explains how you can support formal agile training for educators.

No matter what kind of applications you are building, you have to be far, far better at digital development than you were with the first digital age. To compete, we must learn how to integrate Artificial Intelligence, Big Data, and Cloud into our enterprise strategy and throughout our Value Streams.

We Agilists have long held that we are in an age of VUCA - volatility, uncertainty, complexity and ambiguity. Given what we have been through in 2020, and are still going through, even that feels a bit outdated. Harvard Business Review "ups the ante" on VUCA and tells us we are living in a time of 3-dimensional change. It's perpetual - occurring all the time, it never lets up. It's pervasive - unfolding in multiple areas of life at once, you can't escape it. And it's exponential - accelerating at an increasingly rapid rate, and humans aren't built for exponential. In other words, it is not likely that you will be getting off the change bus anytime soon and it's almost impossible for you to see what is coming next. Feeling any discomfort yet?

In such conditions, how can we best survive, and possibly even thrive? This is the territory Lyssa Adkins, Agile & Leadership Coach, will help us navigate. She will lead us through a process using the Edge Theory of Change so that each of us can consider what "edge" we are on, and how we can find comfort in the middle of discomforting change. We will also explore how we can count on Agile to create stability. This will be a hands-on keynote and you will leave with insights for yourself and ways of working with others as we make the best of our ride on the change bus.

Are you attracted to the idea of allowing people to move towards the work they find most motivational, allowing them to decide for themselves what they work on and which team they are part of? Perhaps you’ve read Heidi Helfand's book - Dynamic Reteaming - and heard of organizations that have run team self-selection events, and while that’s sounded to you like the right thing to do, you’ve thought “that’ll never work here”?

The traditional wisdom of having long-lived, stable teams means that deliberate reteaming might sound unwise. You might be anxious that if you gave people agency over which team they were in, nobody would want to work on Team X. Or everyone would want to work on Team Y? Or Team Z will be left with people who did not have the skills to really succeed with Z?

Well, that’s exactly how Redgate, a software company in the UK, felt in 2018.

This is the story of why and how we took the plunge, deciding to run our own self-selection reteaming process. Chris will share what happened, what went right and what went wrong, and how that first attempt has lead us to making reteaming an annual event that’s popular with senior management and our software development teams.

Chris hopes attendees will be inspired to try a self-selection process that works for them, building on the following take-aways:
* Learn about "reteaming", the principles of self-determination and the value of providing staff with autonomy, mastery & purpose
* What holds us back from self-selection both as leaders and participants
* What happened when Redgate Software ran their self-selection process (Spoiler: Good things)
* How to plan and run a considerate self-selection process - physically and remotely
* Tools and techniques to apply to your process

Every Scrum Master knows the definition and rules of the Sprint Review from the Scrum Guide inside out. The team presents what has been achieved - the current increment - and gains valuable feedback. So everyone gets an outlook on the goals and can then adapt them together and collaboratively. But the review has potential for much more. It is also worth looking at the original intention behind the framework.

Ken Schwaber and Jeff Sutherland, the founders of SCRUM, had a pretty good idea of ​​what they wanted to achieve with the framework. Ken and Jeff were motivated by the following statement when developing SCRUM:

"Encourages developers to go into the field and listen to what customers and dealers have to say." (Takeuchi and Noaka, 1986)

But doesn't a traditional meeting prevent collaboration between developers and users? Developers and users often withdraw after the meeting and then wait for feedback until the next review. No, it doesn't have to be like that.

The review can be used for much more than just a demonstration and an outlook on the following sprints. By observing and analyzing the participants, valuable helpers for identifying requirements and supporters during a transformation can be obtained. But the absent also ran the starting point for further action. A systemic approach is used to search for reasons for absenteeism and to find solutions.

Agile projects can only really show their strengths with collaboration between developers and stakeholders. With the right stakeholders, gained from the review, the right structures can then be selected in order to achieve ideal results with optimal use of time. These include, for example, a design studio, domain storytelling or event storming.

In their lecture, Katja Hegein and Nils Hyoma will report on their experience of a project in which disruptive software was successfully introduced in an agile manner. Many critical stakeholders were involved and, through collaboration, became supporters of the new solution.

Event storming is a process for modeling a business domain from the perspective of the business experts. It has been used by many with great success. Event Storming can help your team:

• Build an understanding of a domain
• Define the scopes and interactions of the components of a system
• Rapidly discover unknown-unknowns
• Expose the intricacies of the business domain
• Identify the areas of greatest risk

The artifacts produced in this process are useful to both the business experts, to help document their domain, and the engineers building systems for that domain.

In this session, we will explore the process of Event Storming. We will define the goals and expected outputs of the process, and walk through a simple example so that you are ready to bring this important process into your organization.

Many work teams have become closer than ever during the pandemic period, meeting regularly and providing much-needed support. But research shows that valuable connections beyond the team have faltered: people bemoan the loss of casual interactions with colleagues from other departments in corridors and cafeterias.

A key issue is that many work calendars are a monoculture: near-endless drifts of online meetings, often with the same people, discussing the same stuff. This Zoom overload leaves people exhausted, crushes their productivity, and disconnects them from their wider working network.

As “back to the office” becomes a reality, making time and space for the growth of a more varied ecosystem is essential. We need a “rewilding” of informal verges and greenways, where cross-pollination can happen - without more meetings.

In this session, you’ll learn to:
- Reduce the need to hold another meeting, whether in-the-room, remote or hybrid
- Evolve communication techniques that enable richer collaboration outside of meetings
- Create time and space for your best work to flourish.

Manual testers are struggling to keep up with the demand for more frequent product releases, and the need for automated tests is evident. The journey for a manual tester to learn automation can feel overwhelming. Training classes and books can be great for introducing new concepts. But how can learners integrate building new testing skills into their daily work?

Busy testers need a strong vision of What’s In It For Me to take the many steps to learn automated testing. Allison and Bhawna share six qualities of strong manual testers that can support them through their learning journeys. In this interactive session, attendees connect theory to practice through an exploration of adult learning principles and the steps Bhawna took to learn automated testing.

You will learn the factors that contribute to a successful learning journey and a worksheet to map your next steps. Join Allison and Bhawna to discover how to optimize your learning time!

Combating the “Great Resignation” – Shifting your approach to Retention using an Employee-Centric Experience Process (THIS IS THE FULL TITLE - it would not fit in the space provided)

The “great resignation” is not only impacting organizations - consider the impact that it is having on Agile teams. It takes time, energy, and money to build high-performing, self-led Agile Teams. What if leaders and managers approached employee retention in a different way?
Agile organizations are customer-centric by nature, but what is the impact when we also become employee-centric? We may be able to keep our most valuable assets by simply shifting our mindset by taking the same approach with our employees as we do with our customers.
Join Christina Maines as she shares case studies on what employee-centric organizations do to ensure that employee satisfaction is met. She will discuss the effects that the pandemic has had on organizations large and small when it comes to employee retention and what she has found to be major contributors based on her research and personal experience having changed jobs unexpectedly in early 2021.
Attendees will walk away with proven methods that will aid them in shifting their culture to an “employee-centric” culture, including:
- Using value propositions to better understand employee frustrations
- Identifying ways to alleviate employee frustrations, from the employees perspective
- Developing a plan to retain employees and keep Agile teams intact

In Certified ScrumMaster (CSM) courses, Scrum myths are busted. One such myth is that the Scrum Master must be the note-taker for everyone. Nope! Coaching doesn’t mean scribing. The Scrum Guide notes that the Scrum Master is a true leader who serves the Developers, the Product Owner and the Organization. Serving doesn’t mean being a secretary.
Join this session with Angela Johnson, author of The Scrum Master Files to learn:
• How Scrum Masters disempower Developers when they scribe notes for them
• How Scrum Masters take everyone’s learning opportunity away when they become the admin
• How Accountability is greatly reduced when the Scrum Master micro manages administrative tasks
• And what to do to prevent these dysfunctions instead

Part 1: Problem: In most companies today, one of the main struggles around delivery of work, is truly not understanding the steps necessary to complete work and the lack of transparency around the current state of the work in the workflow

Part 2: Mike and Rebecca show how Kanban can be used to bring visibility and transparency through both creative and non-traditional ways to help your team focus and deliver with excellence.

Part 3: Learn the practices and principles of Kanban; the measurements that can lead to improvement; how the Kanban board can make bottlenecks visible; and provide questions to ask so you can better understand how Kanban can help. Mike and Rebecca discuss the 6 steps to Getting Started with Kanban to help everyone with their Kanban journey.

2020 introduced the largest remote work experiment ever. Vaccines to counter Covid-19 and new policies to safely work together emerged. Hybrid remote seemed the obvious solution as we moved into 2021. But was it a solution or another forced experiment? Does remote still seem like a better option or a temporary fix? We’ll explore why some organizations have chosen remote work, some of the key principles that need to be in place to make remote work successful, and when being face-to-face still provides the better option for certain types of work.

LIVE is an interactive and unscripted conversation with your hosts and panelists — exploring an array of topics around humanity and agile. The panelists will come from the audience. The topics covered will be that of the issues on the hearts and minds of the voices present. All will be invited to join in the discussion.

Have you ever been in a situation where your choice not to speak left you feeling like you were stuck with a decision you didn't agree with? Have you ever spoken up only to find out later someone felt pressured or railroaded by you?

Assertiveness is the art of speaking boldly and with compassion, speaking confidently and with humility, and speaking up while not speaking over those around you. We will discuss the key tools to help you work out this balance and build your emotional intelligence in conversations so that you can be confident in your communications.

Learning outcomes:
Self-assess where you fall on the spectrum from Passiveness to Assertiveness to Aggressiveness.
Understand and analyze the underlying motivators of the actions of people in these stances.
Assess a personal or professional situation in which you wish you had been more assertive.
Design how you might deal with that situation again if you could turn back time.
Create a plan for improving communications in the future.

We work on products and projects, yet there is often a lot of confusion on what they are and how they relate. While the definition of the project is quite well defined, we often don't use it or contrast it with product(s). This session explores the definitions of each and how they relate to each other - and explains them in simple and easy to use ways (we address services as well). We look at the common issues and challenges that organizations create with their traditional approaches to funding and structure, which often constrain success when shifting from project to product approaches. Finally, we analyze the reality of what product people have to deal with when they have multiple stakeholders requesting more than is possible (so always). Product people have the tough job of making choices, since everything people can think of can’t be done - being able to explain it in clear terms is critical.

Do you know when you should pivot? What about your ideas, are they being listened to? In fact, even when you are proven right after a horrible launch, do you have that sinking feeling that everyone knew this was a bomb, but just didn’t know how to say it?

Being a change agent in an organization, especially one where a product is in flight, is hard. While teams may be happy to talk about strategy and even know what it looks like, the idea of understanding when something fails and HOW to move forward when it does escapes teams. There isn’t a shared language that helps them figure this out.

This leaves teams holding their ideas close to the chest. Their fear: an unsure political environment and unclear data will make their insight useless. This leads to “business as usual,” where everyone smiles on Zoom even while initiatives are headed to disaster.

Enter Survival Metrics, a framework that helps teams use what's important to the company (think - “values”) and operationalize them as metrics that make change much easier. In effect, teams get a dashboard-like artifact that is understandable to various teams inside of your organization. This helps clarify action steps, makes values very clear, and surface incentives that help teams pivot in a fast, politically safe, and data informed way.

I will present building a good software testing life cycle and achieving quality in software projects from scratch. It is a real life story. After attending start-up company, we managed to build the QA processes and faced the storming and performing stages as the team. I will share this journey.

After starting a new project, the initial planning is done and the very first development activities start. But as we all know, all products are tested, which means at some point (ideally soon after the development activities start) testing activities also start.

So, from the start of the testing till maturity, there is a long and tricky way. In this talk, I discuss what kind of challenges are experienced and how we can cope with them.


  • Uncertainties
  • Hidden information
  • Missing guidance
  • Complex and complicated systems under test
  • A lot of deployments and limited resource
  • Adaptation problems in the team


  • Information mining: Walk through and explore the system, Customer Surveys, Requirement Analysis, Specification Benchmarks
  • Define processes: Bug Life Cycle, Test Case Life Cycle, Workflows: Code Review Guideline, Acceptance/Exit Criteria
  • Decide Tools: Issues, Tasks, Tests, Results, Code
  • Maintain Tests: Coverage, Suite Management, Markers
  • Automation: Implement the skeleton: Flexible enough for further improvements, Robust and open for RCA, Reporting
  • Define Levels and Subsets: Priorities for the executions

    Proposed approaches can be applied by any organization by adapting according to the related work to achieve time and cost reduction

Proposed approaches can be applied by any organization by adapting according to the related work to achieve time and cost reduction.

If your organization is going agile, you’ve probably asked yourself these questions at some point. How do I know if we’re agile? Why should I care if it’s going well? Why aren’t we seeing the benefits we expected? How come we’re going slower? Because you’ve invested a lot of time and money into your agile transformation, it’s important to know and track how successful it is.

Our session helps you determine whether or not your organization is truly becoming agile. Ann Kahraman and Tracy Walton from Isos Technology discuss example scenarios, how to tell what’s working and what’s not working, what agile at other organizations looks like, and help you conduct an agile self-analysis through polls and breakout rooms.

You leave with an initial self assessment of the state of agile at your organization. And if you’re not where you want to be, we provide guidance for you to create a preliminary action plan to move your agile initiatives forward.

How can you make time for real innovation and improvement?
How do you know what to automate?
How do you escape process prison?
How can you get everyone aligned to make a difference?
How do you get from where you are to your next performance target?

This is an introduction to 4 valuable mapping techniques and models that build clarity, alignment, and confidence in teams using a combination of collaboration, visibility and measurement.

I'll introduce 4 powerful maps: Outcome, Value Stream, Dependency, and Capability, that you can co-create with your teams to uncover hidden insights and opportunities. I'll show you how to take those insights and create a powerful roadmap of actions and experiments to dramatically improve flow and deliver continuous value.

Flow Engineering builds on the lean practice of Value Stream design and improvement as a framework of techniques you can use right now to reveal your biggest opportunities to eliminate hours of friction every week, so you can invest in what's next.

Use it to improve your:
- Development process
- Planning and shaping
- Delivery/Data/Testing/Analytics/Logging Pipeline
- Employee/Customer Onboarding
- Support/Failure Recovery/Incident Management
- Workflow of choice
…and start spending more time on what's next

Teams using Scrum sometimes struggle with operational or emergent work blowing up their sprint plans. As DevOps delivery is increasingly used by organizations the need of Scrum teams to accommodate operational work also increases. After all, it does not matter how interesting that new feature is if production is down. By combining the disciplines of Scrum and Kanban teams can find that happy balance of planned work and emergent work while still maintaining discipline and continuous improvement.

As an example, we will build up a hybrid process for a hypothetical team to discuss the reasoning behind differing combinations of practices that could be used. I will review 3 categories of a hybrid ScrumBan delivery methods that are typically seen in the industry.

We often talk about what the Product Owner Must "DO" - they must own the Product Backlog, they must manage the product backlog and the priorities, they must refine the backlog, they must answer the team's questions.

What 6 characteristics are in a great Product Owner’s DNA? We will explore how to help a Product Owner go from good to great!
There are the 6 basic elements that make up the DNA of a great Product Owner. Innovative Product Owners are:
1. Engaged – Your best POs are engaged and ready to step to the task at hand, whether it is demonstrating value to the delivery team or to the business stakeholders.
2. Available – Being physically available is only half as valuable as being completely present in the moment and dedicated to their duties and responsibilities.
3. Decisive – There is no room for the wishy-washy in the PO role. A great PO will see an opportunity and seize it before it’s gone.
4. Empowered – Although this may seem external, an effective PO exhibits strength and confidence, which in turn helps executive stakeholders to trust them and give them the power to enact change.
5. Knowledgeable – This goes without saying—almost. Many people parading as PO are merely project managers who were assigned the role without having any clue of what it entails.
6. Foresightful – Seems like a funny word, but it’s powerful. Not all opportunities or warnings are immediately obvious. A foresightful PO takes subtle cues, regardless of where they come from, to make decisions.

Based on these DNA elements we will see how to share yourself or your Product Owners on each element. We will see where your PO’s need to focus on to become more effective.
When using these elements what would an effective PO do? What is your PO doing now? How can our PO use these elements to be more effective in creating value in the product, in engaging with customers and stakeholders and in working with the Scrum Teams.
We will wrap the talk with a conversation to address questions around the role of the PO.

"Never had a Pull Request over 300 LoC that didn't look good to me" is, sadly, a reality of so many teams in our industry.
Fortunately, some other teams recognized the value of applying the Small Batches idea from Lean to the PRs.

But, what if I told you that teams doing small PRs with async code reviews, actually have way lower throughput than teams doing big PRs?

I got this surprising systemic insight by analyzing tens of thousands of PRs across a bunch of repositories.
On the bigger PRs side of the spectrum, we tend to lose quality, while on the smaller PRs end of the spectrum we lose throughput. We're forced to make a trade-off between speed and quality.

But! There's a parallel universe of ways of working where you get to have your cake and eat it too. Where you can have both throughput and quality. Universe called co-creation patterns (Pair and Mob programming).

Join me on a journey where I'll show you the data invalidating the assumption that two or more people sitting at the same computer will hurt team's throughput and why the opposite is actually the case.

When a decision is made, it often involves subsequent changes that impact people, processes, and technology. Unfortunately, many changes forget about the impact they will have on the people within an organization. Regardless, the treadmill of change within organizations continues without relent, often creating resistance and a bottleneck of changes.

To get these changes unstuck, we need to take a different approach to change. By better understanding our change ecosystem, we can empower co-created change practices and establish a pull change system instead of pushing change on people. If we focus on making progress over planning for perfection when implementing change, we can begin our journey to becoming a change resilient organization.

Join me in this interactive session as we discuss how organizations can reverse the treadmill of change failure and instead build a resilient approach to change that unlocks change purpose and alignment through adapting to change complexity, generating meaningful dialogue, and building intrinsic motivation for change.

Many companies struggle with their product and tech organization because they experience slow delivery and see few outcomes. We all need to understand that crafting good software is no longer enough to be competitive in the modern digital landscape. Building digital product is what we need! It is way different than building software but is much more effective, much more rewarding and much more fun! How can we do that?
The main difference is that building products means building relationships, communication channels and engage the right discussions. In this session we will discuss the difference between building digital product and writing software and how, very often, we do not achieve our goal because we approach a product development activity with a software development mindset and we fail in building the product development community.