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!

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.

Business is tough. If your market is any good, other companies want your revenue and market share. A lot comes your way that's beyond your control, so how do you stay competitive in a dog eat dog world? You strive for Business Agility.

Business Agility is about being able to sense, create and respond to change, quickly and confidently. Every organization has the bravado to think they do, but few actually can. Think about these local companies who are:

• At the top end of the market being threatened by a newer, faster rival.
• Experiencing a market shift threatening half their revenue.
• Subject to whims of powerful regulation. 
• New in an emerging market and need to stay ahead of the major players. 

Major change can come from all angles, whether from competitors, regulators or market shifts. Companies need to be able to execute not just at the execution level, not just as the portfolio level, but at the business level, so they can handle the change or better yet, BE the change.

Business Agility isn't about how big you are, it's about survival of the fittest. Whether you are a small business or a publicly traded company, be the bigger dog.

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.

So why does pair programming (or any form of pairing really) work? Well rather than tell you why, let's experience it! 

This is a simple 3 round exercise that you can do with your teams and managers to demonstrate the benefits of pairing. It will show the linkage between having a shared mental model through collaboration and ease of integrating the resulting work.

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.

When dealing with metrics, most Agile or Lean teams begin with a Burndown Chart.  Unfortunately, that is also where most of them stop.  While a Burndown Chart is a great first step, it only provides a small sliver of the information the team has access to.

In this talk, we’ll be starting at the beginning with what a Cumulative Flow Diagram is, how it relates to a Burndown Chart, its advantages, and where it too ultimately stops.  We’ll then look at additional information radiators that the team can easily use based on existing data to provide transparency to stakeholders and the raw material for continuous improvement.

This talk is inspired by the book ‘The Confidence Code’ by Katty Kay and Claire Shipman.

What is confidence and how do you know you have it?   While confidence is partly influenced by genetics, it is not a fixed psychological state.  However, you won’t discover it thinking positive thoughts or by simply squaring your shoulders and faking it.  It requires work and choices: less focus on people pleasing and perfectionism and more action, risk taking and fast failures.  This is why it can seem harder for women because these behaviors aren’t typically the ‘norm’ for women but generally come naturally for men.

In this talk we will explore the roots of confidence and the gender gap between men and women.  To ground the learnings, we will also hear interview summaries from four great and diverse women in agile: 

 Lyssa Adkins, Esther Derby, Ellen Grove, and Kat Conner

Ideas similar to test-infected development or test-driven development have been around quite a while - at least since Alan Perlis wrote about interleaving small amounts of design with small amounts of testing in the 1968 Proceedings of the NATO Software Engineering Conference. Yet, even today, there are endless debates about whether such an approach is useful. Some consider it a baseline practice for any professional developer. Others consider it extra work that adds no value. 

There's certainly more than one way to achieve a goal. What are the goals, when we write and deliver software professionally? Let's identify the various stakeholders of a software system and enumerate the needs of each. Then, let's walk through several popular ways of building software - TDD and others - and see how we can meet those needs using each approach. 

As timelines on application development and delivery continue to shorten, it’s no longer enough just to ask folks to work faster. Many managers are stuck between missing deadlines or burning out their people.

This was just one of the challenges for Promontory Interfinancial Network when it chose to implement Agile Portfolio Management over three years ago to speed the deployment of new financial technology software in an IT division of over 80 employees. Since its implementation, the number successful projects has more than doubled and late-stage overload has essentially been eliminated. Along with improving productivity, project visibility, resource allocation, and clarity of prioritization, the process has also been a highlight in audits and examinations as it demonstrates management oversight and risk mitigation.

In this session, Simon Storm, Senior Director of Enterprise Applications at Promontory, and the project lead in implementing Agile Portfolio Management, shares learnings from the implementation by the IT Management Team. He discusses how to get management buy-in, tips for customizing the Agile process for your institution, and his insights of how spearheading the Agile process can significantly advance your career by putting yourself in the driver’s seat of improving your organization’s productivity and collaboration.

In the mid-late 20th century, industry giants asked themselves; “How do we continuously improve?”, “How do we build a quality product?” and “How do we design for end users?” These are the same challenges that we face as software developers and designers today. Issues with technical innovation, resource constraints, and organizational support, are experienced not only in zeros and ones but were experienced on the road. In the early 20th century, the U.S. was considered a global leader in economic and scientific achievement. After those major innovations in transportation, space exploration, and computer science, American industries focused on manufacturing advantages, such as mass production and repeatable use. Progress was now measured by process improvements, adapting to market changes and ability to pivot. Why has the tech industry continued to boom, while other industries struggle? Using examples from General Motors, this talk examines their failures in reliability, collaboration, and product design. Take a step back in history to relive the experiences of these pioneers, learn from their past failures, and how they apply to crafting software products today.

“Move fast and break things.” — Mark Zuckerberg

Mobile is no longer a hobby for companies. In that world, speed is the key. My company embraced the principle of “welcoming changing requirements, even late in development.” It’s allowed us to grow, and we have accomplished some amazing things.

It’s also caused some challenges for teams. They felt the pain of this pace, and our clients were frustrated by delayed releases.

This presentation describes a 3-month case study I ran to measure things like team communication, productivity, and quality while implementing Scrum for the first time. The results were convincing, and allowed us to learn what happens when you value speed more than anything else.

I hope you’ll join me in seeing how we learned to work smarter instead of harder.

A team can’t “become agile” in a vacuum. The “contract” that management and the surrounding organization makes with the team needs to become agile as well in order for the team to be effective. There are 10 commitments that a team's management/stakeholders frequently fail to support fully , even now that agile approaches have arguably become predominant in software development. This presentation enumerates those 10 commitments, and contrasts them with the cheats that organizations typically try to substitute in place of true commitment.

This workshop is designed for those who feel they are stuck in a rut of designing "death by powerpoint" or "video overload" learning experiences. This facilitated session will provide a simple mechanics, exercise basics and a significant amount of collaboration and feedback centered around designing interactive exercises. The highlight of this session is where teams will design a 5-minute exercise in an iterative fashion, gathering feedback from nearby teams. These techniques will provide useful for those who are put in the position of having a set amount of time to teach a group of participants what's really important about a topic.

Participants will have the chance to design a five-minute exercise around a Scrum-related topic, first designing a "value proposition" for the exercise, testing it out with another group, making improvements and adjustments, and another test with different groups giving feedback each iteration. The lessons and experiences from this session will have participants walk away with exposure to a number of exercise design topics, plus they will learn a thing or two from fellow attendees by experiencing other team's exercises.