Product owners face a challenge: potential new markets are vast and full of unknowns. Current thinking in successful product management recognizes the importance of learning about potential customers
and adapting product decisions to reflect those insights. However, many exercises and workshops
geared towards product owners treat target products and markets as a fixed, concrete objective—failing to include any market feedback

Dicey Markets is a product owner simulation designed to reflect many of the forces driving product owners, including unknown information about the market, competitive pressure, and technical debt. The simulation
emphasizes the role of rapid regular feedback in creating successful products in the face of uncertain markets.

The patterns for implementing Scrum at the team levels have largely been set, but what about dealing with Agile and Scrum across multiple teams. Is the answer just magical words like scaling, or SAFe, or LeSS? What are the core concepts and successful patterns? Is it just one big group hug?

In this session, we will explore core concepts around implementing Agile concepts across multiple teams. The session starts with a simulation that explores distributing people across teams (which will actually NOT involve any hugging). From there, this session dives into:

• Prioritization across multiple teams
• Product Ownership across multiple teams
• Dependencies and team alignment
• Communities of Practice
• Communication and collaboration across teams
• The role of managers
• A quick look at scaling methods

Coming out of this session, attendees will have an understanding of core concepts and fundamental helpful practices in implementing Agile concepts across multiple teams.

For a long time multitasking has been considered a must-have skill when, in fact, it makes us less productive and more prone to error. But even with plenty of studies and papers supporting that idea, it can be hard to convince managers and stakeholders that we should be taking on less at a time. In this lightning talk, we'll run through one very quick, lightweight simulation (Multitasking is Evil) you can use to help make that case and show that lowering work in progress is the way to go!

Are your solutions to recurring issues having only minor improvements? Are some of these solutions actually making things worse in the long run? When answering yes to these, typically, we are trying to solve the issues with too narrow a view. Oddly we think we are addressing it at sufficient level but usually not. In order to see the entire picture we need a common language that will enable us to understand an entire complex adaptive system (e.g. organizations, teams, individuals). Join us as we learn a language called System Modeling (aka. Causal Loop Diagrams).

With this language we will be able to have rich dialogue to gain a full understanding of the entire complex adaptive system so that we can create solutions at the fundamental level and not the symptomatic level. Addressing system issues at the fundamental level will significantly improve the system. Symptomatic solutions may give the appearance of improvement in the short term but typically make things worse in the long run. Unfortunately we usually pick the symptomatic solutions because they seem obvious and we don't realize the long term impacts because of feedback delays that could take weeks, months or even years to realize.

Imagine you were hired to provide consulting assistance for a new team just starting out with Kanban. The team has been struggling with their implementation and is looking forward to your expert guidance, support, and advice. It’s your first day and you just walked into the team room to look at their board. You want to make smart observations and thoughtful interpretations so you can have meaningful conversations with the team members. The team starts assembling in the team room for the daily standup and you plan on making some comments afterwards.

What comments would you make? What thoughtful questions would you ask?

This interactive presentation provides a detailed look at how to interpret and thoughtfully observe Kanban Boards to better understand the work of your teams. We will start with an overview of the Lean Kanban Method and then proceed through a series of interactive exercises that give you an opportunity to review and interpret various Kanban boards. The exercises will increase your understanding of Kanban systems and provide opportunities to practice interpreting various board setups so you can have thoughtful and meaningful conversations with your teams.

Everyone wants to know which Agile metrics really count, and why. But a lot comes down to context: who's asking, what decisions are on the horizon, how you communicate, and so forth. Add scale, and you've got a major challenge.

David Bujard, Dante Vilardi and Nate Conroy have spent the last few years trying to figure how to make agility measurement effective at a big federal program. In this talk they will discuss lessons learned from numerous experiments -- those that produced results, and those that didn't.

David and Dante are Agile coaches who support a transformation program at USCIS.

Good retrospectives (you know, the ones that actually lead to real change?) rest on three pillars:

1. people,
2. process, and
3. follow-through

What makes retrospectives so difficult is that if any of these three pillars starts to crack, it's next to impossible to succeed. Ultimately, getting the right people in the room, utilizing a good process to facilitate the conversation, and following-through on the learning outcomes depend on having an organizational culture that encourages learning, transparency, feedback loops, and continuous improvement.

If this sounds like your company already, then great! This talk is not for you. For everyone else, join us to explore the current trends of employee engagement, how they overlap with agile retrospectives, and the true opportunity each team member has to improve the quality, speed, and outcome of their work. 

Many UX designers struggle to work within a Scrum environment and see Scrum as a framework mainly for developers. Working in time-boxed Sprints and delivering small pieces iteratively and incrementally might force designers to focus on a single story at a time. This in turn can lead to tunnel vision, losing focus of the big picture and resulting in a fragmented user experience. Come to this presentation to learn where design fits in Scrum and how to apply design principles in Agile environments and work effectively with Scrum teams to produce a great user experience.

Most organizations are embracing the desire to be lean, at least espousing the desire.  But what does lean mean in different contexts? Is embracing lean as a startup different than lean delivery as a midsize company or a large organization or a government agency? 

This talk will explore what it means to be lean in various sized organizations, what is the same and what is different about lean implementations based on the size of the organization.

Confused about Continuous Integration vs Delivery vs Deployment? Not sure how to take the next step towards Continuous Deployment?

In this session, Nayan will remove the confusion around the "Continuous" terms. He'll then show you how to go from Commit to Production with no manual steps, while remaining confident that your production system remains stable. We will do this with a variety of open source tools -- from traditional build & integration tools to modern deployment environments & monitoring. You'll leave the session inspired and ready to build your own Continuous Deployment Pipeline when you get back to work.

Leaders of development teams want to be able to adapt their existing product to innovative ideas and shifting market conditions. This is often the reason organizations "go Agile," yet this flexible ability to deliver rich business value is often frustratingly out of reach.

Agile teams and their management are also familiar with the value of individual development practices. For example, Test-Driven Development's ability to catch defects early, and to provide the team with the ability to confidently extend the product. What Rob has found by working with a number of teams, each for six months or more, is another much greater--and more rare--source of business value resulting from diligent attention to software craftsmanship and the resulting two-way trust that forms between Development and Product.

You will hear a handful of surprising (but real) first-person tales, each detailing a time when changing market forces, dramatic pivots, disruptive technological changes, or insightful requests were managed by the delivery team within a single two-week sprint. Each of these "Black Swan User Stories" (Rob's term for powerful, risky, and unforeseen user-stories) resulted in multiplying user productivity, opening whole new markets, or delighting and retaining critical customers.

What we found in each case was that rapid completion of our Black Swan User Stories was the result of diligent, disciplined application of a few Agile technical practices; and that this resulted in the concrete realization of organizations' long-held expectations for Agile software development.

Are you sometimes overwhelmed by the never-ending stream of Agile teachings you’re supposed to know and have at your fingertips to address every possible situation in the proper Agile way?

Sure, Agile is a “mindset” and you’re supposed to “own your process” but the reality is, that’s not how we teach or learn or usually even talk about Agile. Instead, we are bombarded with ever more retro formats, technical practices, prioritization techniques, facilitation tips, and other snippets of wisdom that we should all know before we can be considered good Agilists. And if your job title is Scrum Master or Agile Coach, the range of things you’re expected to master only expands.

In this session, Mathias Eifert will share how he found his footing in a vast sea of loosely connected Agile rules, processes, techniques and tools by recognizing that a small number of fundamental concepts can help with finding answers that are “good enough” as a starting point to tackle most new contexts or problems. Together, we will examine how many established Agile approaches can be traced back to these essential concepts and hopefully help each attendee a little further along on their journey from rules-based Agile to fundamental understanding.

In this lightning talk, Richard Cheng will share a story from his Motley Fool days in regards to the 5 things to look for in a Product Owner:

• Bandwidth
• Power
• Knowledge
• Interest
• Vision

Is your Product Owner available to the team, empowered to make decisions, knowledgeable in their business domain, engaged in the product and leading the way for delivery of value? This session does a deep dive in the these ideas.
The session starts with a brief Seinfeld video to demonstrate the importance of Product Ownership. The session then discusses 5 key attributes to look for in a Product Owner:

1. Bandwidth
2. Power

3. Knowledge
4. Interest
5. Vision

After that discussion, we will have an interactive exercise to identify what a Product Owner does day to day. The debrief will identify the balance a Product Owner must have between working with stakeholders, end users, customers AND working with the Scrum team AND product backlog refinement.

The session concludes with the presenter sharing a Product Owner persona sheet. This persona sheet measures product owners across the 5 attributes mentioned above and presents a narrative on their core strengths and risks.

Do you want to write great User Stories (a.k.a. small features that are part of a product) that provide the vehicle for conversation and confirmation that we build the right thing? Do you struggle with completing stories (of business value) that are potentially shippable within a fraction of an iteration/sprint? During this session we will do a quick refresher on User Story formatting to include Acceptance Criteria. The reason for the refresher is that over the last few years, despite people using User Stories, I have experienced their usage far from the intended purpose.

After the refresher, we will learn at least 2 techniques for splitting stories in this interactive workshop.

One of the struggles I have seen when organizations transition to Agile in relation to the Agile principle "Customer Collaboration Over Contract Negotiation" is: When and how do I involve the right customer.

Goal of this presentation:

• Provide tools on how to involve different types of stakeholders
• Tool to identify different types of stakeholders

In the presentation I will explain the 2 step process of:

• Step 1: map out the players for a value stream, product, or feature(set) in a simple 2x2 Stakeholders Matrix (influence/power and interest)
• Step 2: Learn about the tools and techniques to involve players in each quadrant based on their specific strength or opportunity

“Going Agile” is a big cultural change for most organizations and it’s significance, impact, and the effort required for successful implementation can often be underestimated. There are many benefits to be gained by adopting a more Agile approach, including quicker feedback loops, more focus on value, and higher levels of collaboration. However, for Agile to succeed in the long-term it’s essential to set expectations up front and to balance the amount of change with the amount of disruption it will cause. In this session, we will look at how David Anderson intentionally built change management principles into his Kanban Methodology and explore other change management techniques the Agile community can leverage when helping organizations transition to Agile.

Are you struggling with delivering a potentially releasable working product every iteration? Ever wonder what one of biggest reasons we have difficulty getting things done at the individual, team and organizational level are? Do you keep doing something even though you know it reduces your productivity and lowers quality? We are going to run an exercise that highlights one of the major culprits that you have all experienced and probably continue to experience. The exercise will likely ignite a little (or big) fire in your belly that will help you become more productive and improve the quality of your work. From this, we will discuss ways to improve this at the individual, team and organization levels.

So you are considering getting a coach to help you in your transition to Agile. Or perhaps you are an Agile practitioner considering becoming an Agile coach. What do these Agile coaches do? What makes them different?

This session will enter the foyer of the house that describes what coaches do and considerations one can have when they think about coaching (including hiring one). Prepare to be challenged and to learn a bit of what it takes to be or work with a coach; it has little to do with courses or certifications, though they may help. In covering what coaches do, one can now begin to think along the lines of what the skills one may need to improve.