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.