One of the key advantages of Agile over plan-driven approaches is that an Agile mindset acknowledges our ever-diminishing ability to usefully predict the future and focuses our efforts on managing change instead of trying to suppress it. This “new reality” has become pervasive enough to drive its own buzz word – VUCA, which stands for Volatility, Uncertainty, Complexity, Ambiguity. But beyond the hype lies a truth that Agile leaders need to understand and embrace – that certain problems really do respond differently to our attempts to manage and solve them. Why does this matter? Because problem contexts that defy straightforward cause-and-effect expectations significantly impact productivity while simultaneously presenting much higher risks to success. Even worse, applying leadership approaches that aren’t matched to the problem context dramatically increases the danger of catastrophic failure.

In this session, we’ll examine how the Cynefin framework helps us make sense of what kinds of problems we’re dealing with and how we should approach them. We will then look at ten ways in which Agile frameworks, approaches and technical practices help us manage or even reduce complexity and one where they fall short. You will walk away with a deeper understanding of how - and why - the things we do as agilists increase stability and reduce risks for our teams.

Are you - or worse, your bosses - starting to doubt this Agile thing? Are your software teams proficiently delivering every two weeks and yet it just doesn't seem to make much of a difference to the bottom line?

Most organizations begin their foray into Agile with software development and that makes sense - after all, the Agile Manifesto focuses on “working software.” Unfortunately, though, this is often also where the Agile journey comes to a grinding halt. Management confines Agile to a small box labeled “Delivery,” puts a lid on it, and everything else continues as usual. Development teams in such an environment may produce more software, faster and with better quality, but the expected impact on the organization often fails to materialize because the business value of the produced software doesn’t increase correspondingly.

In this session, we’ll take a closer look at why Agile shouldn’t end with “working software.” The most commonly used Agile frameworks don’t provide much guidance on how to manage risk and ensure the creation of organizational value, so we will draw on insights, tools and techniques from other domains to identify crucial high risk assumptions, test our hypotheses, and measure outcomes. We’ll explore how we can get past the “feature factory” focus and apply the Agile mindset beyond delivery to produce better business outcomes and organizational impact.

Want to help your data and analytics teams embrace Agile but don’t know where to start? Wondering why your data team seems to struggle with creating manageable yet valuable stories? Curious why we think Agile for data teams is a distinct challenge?

Data work is often structured more like a pyramid than the familiar “layer cake” metaphor due to the state of data infrastructure technology, common industry practices, and the heavy lift to integrate data before it can be analyzed and visualized. Prevailing Agile wisdom of cutting work into “vertical slices” thus presents significant challenges for Agilists working on data teams! Typical full-stack vertical stories in this environment can easily become too complex, interdependent, and unwieldy to fit into fixed-length sprints. Technical stories can encapsulate smaller work increments but risk becoming too abstracted from the customer’s core problems and trap the team in infrastructure work for too long. An additional impediment to traditional user stories is the highly exploratory nature of advanced analytics and data science projects where in many cases end users lack awareness of what kind of problems can even be solved and technical experts can’t initially predict which solutions will actually be possible.

This session presents successes and lessons learned from applying alternative story decomposition and writing techniques on several data products across multiple teams. Returning to one of the fundamentals of what makes Agile valuable, namely to obtain feedback on feasibility and end user value as quickly and systematically as possible, our approaches strive to ensure teams have small, independent stories while still maintaining a value focus. We discuss ways to decouple the technical stack through stubbing and gradual tightening of the Definition of Done. This technique accommodates the necessary foundational work in the background while also obtaining early feedback about the value of the eventual product delivery options. A second approach incorporates Lean Startup concepts and centers on replacing traditional user stories with testable hypothesis statements that allow for explicit experimentation and risk trade-offs towards relevant milestones such as model quality, performance, predictive reliability, etc. in the context of extreme uncertainty.

Join us as we discuss some of the friction Agilists can encounter on data teams, as well as some validated ideas for meaningful solutions.

Agile is an incremental and iterative approach to delivering value to our customers. But too often we assume it’s really all about ways to slice work into smaller batch sizes and that both approaches are fundamentally equivalent. However, there is a crucial difference and this lack of awareness is a major contributor to projects and teams that are AINO (Agile In Name Only)!

In this session, we will discuss how to differentiate between incremental and iterative approaches, their strengths and weaknesses, and why you really need both. We will explore the many ways in which iteration shapes the core of Agile practices, how it supports and enables the benefits of agility, and how understanding its awesome power is a key step in moving from “doing” Agile to truly being agile. In addition, we will take a close look at the practical implications of when to use each approach by discussing real world scenarios, highlighting common Agile anti-patterns and (re)examining familiar story slicing patterns.

You will walk away with both a better understanding of one of the most important underlying principles of agility and immediately applicable insights for your daily work!

Agile is an incremental and iterative approach to delivering value to our customers. But too often we assume it’s really all about ways to slice work into smaller batch sizes and that both approaches are fundamentally equivalent. However, there is a crucial difference and this lack of awareness is a major contributor to projects and teams that are AINO (Agile In Name Only)!

In this session, we will discuss how to differentiate between incremental and iterative approaches, their strengths and weaknesses, and why you really need both. We will explore the many ways in which iteration shapes the core of Agile practices, how it supports and enables the benefits of agility, and how understanding its awesome power is a key step in moving from “doing” Agile to truly being agile. In addition, we will take a close look at the practical implications of when to use each approach by discussing real world scenarios, highlighting common Agile anti-patterns and (re)examining familiar story slicing patterns.

You will walk away with both a better understanding of one of the most important underlying principles of agility and immediately applicable insights for your daily work!

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.

Wouldn’t it be nice if there was a way to combine design thinking, visual facilitation, cause-and-effect analysis, quantified business goals, surfacing of value assumptions and direct traceability from goals to features in a single approach?

There is! Gojko Adzic’s Impact Maps are both a tool and a method that helps multiple stakeholders gain consensus on which features or actions will most likely help us achieve an organizational goal. In the process, we can decide which user groups or personas to target first, derive epics/user stories, identify the underlying assumptions that need to be validated using testable hypotheses, and determine leading indicators to get early feedback whether we are moving in the right direction.

In this workshop, we will look at how to build an Impact Map with a group of stakeholders and how to get the most value out of it. Best of all, you will go create your own sample map so you will walk away with hands-on experience!

The Agile community has long proclaimed that “prioritizing by value” in combination with early learning not only results in a front-loaded value curve, but in overall higher project value compared to a traditional plan-driven approach. In addition, a relatively small number of features usually delivers the bulk of a product or application’s ROI, whereas other features fail to address real customer needs and thus don’t deliver much value at all. The crucial difficulty, though, is to identify those rock star ROI features among the vast range of possible things a team could build.

In this session, we will discuss approaches such as feature buckets, impact maps, and testable hypotheses to categorize and validate features so we better understand how they support different stakeholder goals and what “good enough” looks like. While “the more, the better” applies for some features, it is wasteful if applied across the board, so we will also conduct a short activity using the Kano model to explore the impact of customer expectations on the ROI profile of different features.

Does your organization find it hard to determine “the right thing” to build? You are not alone – studies show that even in very high performing organizations only 10-35% of initial ideas actually generate business value. Agile development should make it easier to obtain early customer feedback, but in most organizations Agile approaches are limited to software development teams with little connection to the rest of the business. In addition, Agile methods by themselves offer few guidelines on how to translate organizational goals and customer needs into the backlog’s content and relative priorities in the first place. As a result, there is a significant, but often underappreciated risk that Agile teams end up very efficiently building “the wrong thing right.”

In this session, we explore how Lean Discovery and experimentation can expand the scope of Agile’s “inspect and adapt” feedback loops to systematically identify and validate critical assumptions about our product’s value proposition. Based on the Lean Startup and Lean UX approach to product development as a series of hypotheses about customers’ behaviors and value perceptions, we discuss ways to derive testable assumptions from organizational goals to enable validated learning. Finally, we explore the implications of this approach on project planning and budgeting to support increased business agility.

Wouldn’t it be nice if there was a way to combine design thinking, visual facilitation, cause-and-effect analysis, quantified business goals, surfacing of value assumptions and direct traceability from goals to features in a single approach?

There is! Gojko Adzic’s Impact Maps are both a tool and a method that helps multiple stakeholders gain consensus on which features or actions will most likely help us achieve an organizational goal. In the process, we can decide which user groups or personas to target first, derive epics/user stories, identify the underlying assumptions that need to be validated using testable hypotheses, and determine leading indicators to get early feedback whether we are moving in the right direction.

In this workshop, we will look at how to build an Impact Map with a group of stakeholders and how to get the most value out of it. Best of all, you will go create your own sample map so you will walk away with hands-on experience!

Does your organization find it hard to determine “the right thing” to build? You are not alone – studies show that even in very high performing organizations only 10-35% of initial ideas actually generate business value. Agile development should make it easier to obtain early customer feedback, but in most organizations Agile approaches are limited to software development teams with little connection to the rest of the business. In addition, Agile methods by themselves offer few guidelines on how to translate organizational goals and customer needs into the backlog’s content and relative priorities in the first place. As a result, there is a significant, but often underappreciated risk that Agile teams end up very efficiently building “the wrong thing right.”

In this session, we explore how Lean Discovery and experimentation can expand the scope of Agile’s “inspect and adapt” feedback loops to systematically identify and validate critical assumptions about our product’s value proposition. Based on the Lean Startup and Lean UX approach to product development as a series of hypotheses about customers’ behaviors and value perceptions, we discuss ways to derive testable assumptions from organizational goals to enable validated learning. Finally, we explore the implications of this approach on project planning and budgeting to support increased business agility.

The Agile community has long proclaimed that “prioritizing by value” in combination with early learning not only results in a front-loaded value curve, but in overall higher project value compared to a traditional plan-driven approach. In addition, a relatively small number of features usually delivers the bulk of a product or application’s ROI, whereas other features fail to address real customer needs and thus don’t deliver much value at all. The crucial difficulty, though, is to identify those rock star ROI features among the vast range of possible things a team could build.

In this session, we will discuss approaches such as feature buckets, impact maps, and testable hypotheses to categorize and validate features so we better understand how they support different stakeholder goals and what “good enough” looks like. While “the more, the better” applies for some features, it is wasteful if applied across the board, so we will also conduct a short activity using the Kano model to explore the impact of customer expectations on the ROI profile of different features.

“Agile doesn’t have a brain.” This quote from Bill Scott, ‎VP, Business Engineering and Product Development at PayPal, is provocative for sure, but it highlights the perception that in most organizations Agile is primarily applied as a downstream engineering approach. As such, it isn’t inherently concerned with optimizing product design and user experience, the biggest drivers of customer satisfaction. The feedback cycles that form the basis of Scrum provide verification and validation of stakeholder needs only as they are expressed in the backlog’s user stories. Even if a sufficiently empowered and accessible Product Owner is available, agile methods offer little guidance on how to translate organizational goals and customer needs into the backlog’s content and relative priorities in the first place. As a result, the danger persists that agile teams end up very efficiently building products that implement an incomplete and subjective perception of the wants and needs of both the organization and its customers.

In this session, we will explore how Lean thinking expands the “inspect and adapt” loops of agile development and helps systematically determine which features and design choices really provide the greatest organizational value. After a brief introduction to Lean concepts, we will discuss how Lean approaches product development as a series of hypotheses about customers’ behavior and value perception and builds on Agile’s rapid iterative delivery of working software to test these assumptions. Finally, we will examine ways to derive testable assumptions from organizational goals, such as the Lean UX Hypothesis Statement template and Gojko Adzic’s Impact Mapping.