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.

Leading a large-scale agile transformation isn’t about adopting a new set of attitudes, processes, and behaviors at the team level… it’s about helping your company deliver faster to market, and developing the ability to respond to a rapidly-changing competitive landscape. First and foremost, it’s about achieving business agility. Business agility comes from people having clarity of purpose, a willingness to be held accountable, and the ability to achieve measurable outcomes. Unfortunately, almost everything in modern organizations gets in the way of teams acting with any sort of autonomy. In most companies, achieving business agility requires significant organizational change.
Agile transformation necessitates a fundamental rethinking of how your company organizes for delivery, how it delivers value to its customers, and how it plans and measures outcomes. Agile transformation is about building enabling structures, aligning the flow of work, and measuring for outcomes based progress. It's about breaking dependencies. The reality is that this kind of change can only be led from the top. This talk will explore how executives can define an idealized end-state for the transformation, build a fiscally responsible iterative and incremental plan to realize that end-state, as well as techniques for tracking progress and managing change.

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.

Have you spent a lot of energy and time with your teams focusing on estimation? Do you feel that everyone isn't quite on the same page? There are many challenges on teams who wish to work with an agile mindset, and negative patterns around estimation can have quite the impact on productivity and team morale.

In this workshop, participants will revisit what a Product Backlog Item represents and exactly what an estimate represents. Using this as a foundation, session participants will learn about four distinct parts of a pattern that repeats itself in organizations who may not have a strong handle on these concepts. The workshop concludes with a lightweight estimation exercise that participants can take back to their organization.

Having a better understanding of estimation is helpful, and having a simple yet powerful game to compare items relatively to one another will help break your teams of the pattern of misunderstanding the point of backlog item estimation.

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.

Our roadmaps and backlogs are usually littered with pet projects, squeaky wheels, and recent ad hoc items that gain priority simply because they are the latest shot across our bow. Impact mapping is a powerful practice that helps us identify and align our work to the most valuable business goals and mission objectives and avoid many of the common challenges that arise from an unfocused set of work priorities.

Impact maps help us visualize quantifiable benefits that deliverables should produce towards our business objectives. They allow us to focus our work on those deliverables that move the needle the most, not just deliver features. The practice is a great way to communicate assumptions, create plans, and align stakeholders as well as aid in strategic planning, roadmap management, and defining measures of success and quality.

This workshop will provide an appreciation for the power of impact mapping by walking you through building your own impact maps and the facilitation process for doing so in your own organization. You will leave the workshop having participated in a tangible example of the technique, and having gained an understanding of best-practices for facilitation with a focus on an impact map’s outputs and how they lead into the creation of actionable user stories when completed. Hands-on collaboration with your fellow attendees will help encourage your own application of this technique in your real world road-mapping and backlog refinement activities.

Many teams struggle with fitting in testing activities inside of a Sprint. They end up doing primarily development activities in a Sprint and push testing activities to run in dedicated testing Sprints following the coding Sprints or have a coding and testing Sprint running in parallel. However, in Scrum, the output of every Sprint is a potentially shippable product increment. This means the product increment should be well tested within the Sprint and ready to be delivered. Come to this presentation to learn how to tackle testing on an Agile team, what kind of tests to execute, what to automate and what not to automate, the different testing responsibilities, and when to run which tests. Leave with a testing strategy that you can start applying the next day to gradually get a team to start testing from day 1 of the Sprint and deliver a true product increment at the end of each Sprint.

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.

Tired of Agile As A Lip-service?

Feel like Lean is getting lost?

Being asked to improve everything without changing anything?

Do you want to know what you can do about it?

If so, this talk is for you! Join Trent and Matt as they use Institutional Theory to examine the current state of Agile adoption, what it means for our work today, and what it suggests for the future.

They’ll explain the increasing emphasis on frameworks, the move away from lightweight methods, and the paradoxes we’ve all observed in Agile adoptions. These developments follow clear and established patterns; they’re not unexpected. Come explore why we are where we are, and what we can do to move beyond Agile Despondency.

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.

In the last five years there has been a tremendous surge in the volume of Federal procurements calling for lean and agile solutions to complex problems.  In spite of this, many of these same Government agencies still cling to traditional waterfall models of delivery.

How do we embrace lean and agile principles while delivering under these constraints within large-scale Government agile software delivery initiatives? 

What agile approaches can be effectively used "out of the box" while others may need to be tailored to address legacy Government processes and operating environments? 

In this talk I’ll walk through each of the seven Lean principles and unveil how -- on two Federal Government scaled-agile engagements -- specific lean-agile processes and approaches were tailored for program delivery success, while remaining compliant with agency mandates.   

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