Agile is about the ability to inspect and adapt to change. Can we become adaptable agile leaders? You don’t need to change your title. You might not need to change where you sit in the organization. You will need to change your mindset to have the courage to lead.

Johanna will discuss how you can develop an agile mindset, seeing and living the “art of the possible.” We’ll discuss how your mindset influences your change artistry tools, and maybe even what you call yourself. We’ll see how to learn from small successes and continue to make progress, as you change yourself and your organization. You can start your change by changing your mindset to be one of change artistry and leadership.

One of the 12 principles of the Agile manifesto states that “The best architecture, requirements, and designs emerge from self-organizing teams.” Why is that? and what exactly are self-organizing teams? How does a team become self-organizing? Teams that have always been used to command and control cannot suddenly become self-organizing overnight. Come to this session to learn what self-organizing really means. Understand the attributes of a self-organizing team and some of the challenges you face in getting your team there. Understand how to find the right balance between team learning and team empowerment vs. control? Leave with techniques to help you build and foster high performing self-organizing teams.

It can be difficult for developers to find the motivation to write automated unit tests.  This workshop introduces a simulation that can demonstrate the value of automated unit tests to identify and localize defects.  In the simulation, participants will play the roles of programs and tests.  We will discuss barriers to creating and maintaining unit tests, and how this simulation addresses those barriers.

Theme: Games for Learning, Code and Test

  (We have not published slides for this workshop.  "Slides" link below is to representative slides from other presentations.)

Many team challenges can be tracked back to cognitive biases: our judgement gets anchored, we think we're better than we are, and we are our own favorite reference point. And even though we're encouraged to "think outside the box," there are conditions where we have a bias against creativity. If that's not a recipe for a tough team environment, I don't know what is.

Improve your game by learning about bias! You'll leave this session with strategies for identifying and mitigating bias on your team. 

Retrospectives are the core of agility. And yet they are the scrum ceremony that is most frequently skipped. Many teams like the idea of the retrospective but find them boring, or worse ineffective.

This talk aims to re-energize retrospective facilitators and participants. Starting with the basics: "what's a retrospective and how do you run one?", this talk reveals 7 secrets that lead to more engaging, more effective retrospectives.

You'll learn:

* The best way to ensure your retrospectives lead to real change

* The "pledge" everyone on your team should take before participating

* How to know who to include in each retrospective

* The single most important thing you can do to keep your team engaged during the retro

* And much, much more!

We think we understand that awkward teenager.

Many experienced testers will claim exploratory testing expertise, but too few have ever written an exploratory testing charter, and even fewer have applied a heuristic in that charter. We think we understand exploratory testing just as we think we understand teenagers, because “we have been there”. However the reality is that many of the words currently used in exploratory testing are foreign to us and we feel awkward about our lack of knowledge. The goal of this talk is to give people experience writing and executing exploratory testing charters, creating mind maps, and applying exploratory testing heuristics.

The talk is intended to introduce people to the exploratory testing techniques described by Elisabeth Hendrickson in her book Explore It! with some added material from the work of Cem Kaner and James Bach.

You're a Certified Scrum Master. Perhaps you are an Agile Manger, Agile Coach or Facilitator.

Maybe you are newly minted or maybe you've been doing it a while, but either way you've noticed that not everything seems to work according the way the training or certification class implied it should.

In this session, Camille Bell will explore what you weren't told in training, but need to know. Such as:

• What assumptions Scrum makes that may not apply to your company or organization
• Why some types of teams should not use Scrum and what they should use instead
• How soon Scrum of Scrum stops scaling and what to use when it doesn't scale
• Why some teams don't improve despite holding retrospectives
• How to recognize the hockey stick burn down and what to do about it
• What's a WIP limit and when it can be helpful
• When estimation most helpful, when it's a complete waste and what to do instead
• Why simple prioritization of a Product Backlog won't generate a Minimal Viable Product
• Why the As a.., I want.. So that.. user story isn't enough and what you need to add
• What are the critical missing practices your development team needs

In October, 2015, my company was sold by their parent and taken on by a new investor.  We lost somewhere around half of our staff, but we still had 15 years of legacy tech to maintain while simultaneously finding a new path to profitability.  Morale was extremely low across the engineering organization.  Leaders from engineering gathered in a board room with executive management to figure out next steps.

What started in that board room evolved into our current use of Objectives and Key Results (OKRs) to provide a middle tier of guidance between company vision and sprint planning.  We have also adopted a new tool to clarify the mission of particular teams within the organization.  In this talk, I'll go over what we did and what we've learned.  Most importantly, I'll go over the critical approaches necessary to ensure that you continue to follow Agile values and principles while looking at longer-term horizons like quarters and years.

While much of this was accelerated by our company's sale, it is not just about turning around a company.  The thinking, which continues from what I shared in my Agile DC 2015 talk, "The Myth of Fixed Scope: Why Goals Matter", is for anyone who is looking to deepen their adoption of Agile and Scrum.

Behavior Driven Development / Acceptance Test Driven Development (BDD/ATDD) is a new, exciting approach to developing software that has been shown to reduce rework and increase customer satisfaction. While other testing tools focus primarily on “are we building the thing right?”, BDD tools such as Cucumber and SpecFlow attack the problem of software directly at its source: “are we building the right thing?” By retaining all the benefits of automated unit testing, while extending them upstream to cover requirements, we cut the Gordian knot of risk and complexity to unleash hyper-productivity. 

Why is BDD so effective?

• As a form of Test driven design, BDD helps produce frugal, effective and testable software.
• As a development tool, BDD frameworks like SpecFlow provide many convenience functions and are pre-integrated with powerful libraries like Nunit and selenium to make writing tests a snap.
• As a collaboration tool, BDD helps ensure the “three amigos” (tester, analyst and developer) sync up – ahead of time.
• As a facilitation technique, BDD enables product owners to efficiently provide the team with concrete examples that clarify the true intent of a user story and define the boundaries.
• As a reporting tool, BDD captures functional coverage, mapping features to their acceptance criteria to their test results, in an attractive hierarchical presentation.

Want functional documentation? How about documentation that is guaranteed to be correct, because every feature maps to its test results? Witness the holy grail of traceability – executable specifications.

We will spend a few minutes talking about the context and pre-requisites, so attendees have an idea of where BDD fits in, and what type of investment they are signing their teams up for. We will see that in return for a modest amount of investment in tools and training, very significant benefits can be realized, and the benefits compound over time.

This workshop then dives right in to Gherkin, the structured English language technique used to capture BDD specifications. We will spend the better part of the session learning the tricks and techniques that make for robust and maintainable gherkin specifications. We will review and critique lots of examples, both good and bad.

We will review several examples of reports generated from BDD tools, to provide context and to immediately highlight the bottom line business value that makes an investment in BDD so worthwhile.

Come and learn why Behavior driven design is taking the software world by storm!

In the simplest of terms, software development decisions for commercial organizations can be reduced to a calculation of whether the cost of developing the software will be outweighed by the estimated revenue generated or costs saved by the software.  However, as Mark Schwartz points out in his book, “The Art of Business Value Paperback” this simple explanation is insufficient for commercial organizations, and not applicable for government and other non-commercial organizations for whom the impact of software isn’t primarily measured in terms of revenue.  

In this session participants will experience a simulation that has been created to explore these question of how to make decisions about investments to deliver mission and business value by examining the impact of these decisions on the performance of organizations in changing environments.

Do you want to write great User Stories that provide the vehicle for conversation and confirmation that we build the right thing? Do you struggle with splitting stories so that they still provide business value but can be accomplished within a fraction of your iteration and be potentially shippable to production? We will do a quick refresher on User Story formatting to include Acceptance Criteria. Then we will dive into learning techniques for splitting stories in this interactive workshop. 

Are you a Scrum Master that has a strong affinity to sticky notes, dry erase markers, and other tools of Agile facilitation? Are you tired of seeing the same old blue painters tape on every kanban board? Want to learn some new facilitation techniques that you can use in retrospectives or to build awesome information radiators with your team?

If so, join me for my session on the Super Agile Satchel.

During the session, I’ll briefly talk about how the satchel came to be and its awesome contents.  Then we’ll jump right in to actual examples of information radiators that I created with the tools the satchel contains.  I'll discuss why choosing the right materials, colors, and sizes are critical to facilitation and creating information radiators that draw attention, are maintainable, and focus the team on what's truly important.

Impact mapping is a powerful practice that ensures we are delivering work that directly impacts our business goals and mission objectives.  Our roadmaps and backlogs are usually littered with pet projects, squeaky wheels, and recent ad hoc items that gain priority just because they are the latest shot across our bow.  With a tool such as impact mapping, we can stand firm knowing our real priorities, and fend off these common challengers.

Impact maps visualize quantifiable benefit 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 quality.  Happily, it is also significantly less bureaucratic and much easier to apply than many alternatives.

This workshop will provide an appreciation for the power of Impact Mapping and walk you through building your own Impact Maps.  You will learn techniques for creating Impact Maps as well as facilitating an Impact Mapping session.  You will leave the workshop with a usable Impact Map of your current project, or other of your liking, that can bring immediate value to your road-mapping, backlog grooming, and software delivery.

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.

Does prioritizing your development portfolio seem unclear or mired in politics? Ever feel like the decisions for what gets worked on when are somewhere between arbitrary and emotional? Ever get tired of providing cost estimates for work of uncertain value?

If you answered yes to any of the above questions, this session is for you! Matt Barcomb will open with introductory concepts about shifting from a cost focus to a value focus for development work. Next, providing business value for user stories will be debunked. Then, a collaborative framework for prioritization, Benefit Mapping, will be discussed. Finally, Matt will end with ways to simplify the cost evaluation of work and risk.

Static designs and monolithic structures are brittle and prone to failure. How can we progress beyond them? By understanding the nature of our challenges and applying the right tools at the right time. This talk will describe how to use evolutionary principles to foster changes in your architecture and infrastructure so that you can create antifragile systems.

Nassim Nicholas Taleb spoke to these ideas in “Antifragile: Things That Gain from Disorder.” Join us as we describe how we can:

• Move beyond planning for known failure modes and instead develop antifragile systems that are safe-to-fail in unanticipated ways.
• Leverage the Cynefin framework and its 5 sense-making domains to better frame problems and drive action.
• Employ microservice architectures to make the variability of our environments work for us, not against us.
• Gain knowledge more rapidly through multiple parallel experiments.

How do you create excited, engaged, happy, and effective teams? Start them off right by letting your engineers choose their own teams and projects! Through a proven technique called self-selection, Opower was able to turn a tribe of 40 engineers, many of whom were unexcited about continuing to work on the same old products, into six high-performing teams with engineers who were excited to embark on a new adventure, acquire new skills, and ship awesome code.

In this session we will cover the self-selection process: what it is, generating buy-in & excitement, preparing your teams, running a self-selection event, dealing with concerns throughout the process, and measuring the success of your process. This talk is for anyone who wants to create better teams including Agile Coaches, Release Train Engineers, Program Managers, individual contributors, and other organizational change leaders.

Agile reminds us that the focus of any set of requirements needs to be on an outcome rather than a collection of whats and whos.  Storytelling is a powerful tool to elevate even the most diehard requirements analyst from a discussion of individual requirements to a discussion of outcomes. Outcomes are the big picture that acts as an anchor for whole efforts and which is continuously broken down into more and more detailed backlogs. The onion metaphor that is popularly used in agile planning (Cohn’s Planning Onion) can be used to describe the evolution of backlogs. Building an initial backlog is much like peeling through the layers of an onion to get to the core. There are many mechanisms for developing and maintaining the detailed backlogs, including asking, observing, showing and all sorts of hybrids. Using the onion metaphor, techniques for developing and splitting user stories are the second layer of the onion. However, before getting to the center of the backlog evolution onion, composed of features, epics, and user stories, we need to understand the big picture. 

 Presentation:

Provide an overview of storytelling in a business context and a lean change canvas framework.

Exercise

The room will be broken into teams (aisles will be used if auditorium seating).  Each team will be seeded with a common product change scenario. Based on the scenario the teams will be asked to tell the story of the change and capture the story on a small change canvas.  The exercise and session will culminate in by sharing ideas and lessons learned.

(Note the longer workshop would break the changing canvas into epics and stories)

A well-facilitated large-scale Planning event (such as a SAFe PI Planning) can leave you feeling energized and more confident in your team and your direction. Poorly facilitated events have the adverse effect and can leave you feeling like you’ve just been run over by a Mack Truck.

There is not a lot of guidance from SAFe on how to facilitate this critical event from their website, other than an example agenda and program board. This session will focus on how information radiators and other visual tools can make a tremendous difference in increasing engagement and collaboration amongst teams in order to orchestrate a thoughtful plan with high confidence.

We will show battle-tested ways on how visuals are critical to...

• increase collaboration across teams
• reinforce development practices & standards
• track team progress through the day
• highlight dependencies
• increase the confidence vote
• motivate teams to strive for success

Participants will leave this session with some visual tools and tips they can immediately put to use in their designing their next PI Planning or ANY large-scale planning event.
“There is no magic in SAFe… except for maybe PI Planning” - SAFe authors