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.

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.

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)

Regardless if an agile team is just starting out or a seasoned crew, many groups not only need but also have a desire to improve their way of working.  This is challenging for these new as well as established teams if they have not revisited the fundamental elements and reasoning behind their team's activities.  These conversations and activities could potentially feel mechanical and impersonal at times as teams "go through the motions" and just try to make it through them.  This is a feeling we would all like to avoid, so let's explore some alternatives by going back to the basics. 

This workshop will expose participants to some key principles, values and definitions that are present in teams that have the Agile Mindset.  Attendees will connect with other practitioners to explore and discuss their way of working in a dynamic setting.  Through these interactions, they will then work to identify a specific activity or conversation to focus on and collaborate with others to generate potential solutions.  We will wrap up the workshop by sharing these potential solutions, which participants could then bring back to their teams in the spirit of always trying to improve how they work.

Participants in this session will identify and discuss specific activities and conversations regularly present on projects executing with an agile mindset.  They will then  revisit the fundamental elements, values and principles of popular frameworks.  Participants will then identify one activity that they could improve in and craft an "Improvement Pitch" to take back to their organization, leveraging the Inspection and Adaptation elements of Empirical Process Control. 

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.

In his book Reinventing Organizations, Frederic Laloux describes the “Teal Organization” model. Teal organizations have an evolutionary purpose, self-managing teams with little or no organizational hierarchy, and individuals who bring their whole person to work rather than putting on a work face when leaving the house. Zappos is the most talked about organization attempting a transition to Teal.

Bob describes how his organization is becoming a Teal Organization. Since the concept of Teal is not a specific recipe, they are basing their transition on practices gleaned from other organizations and their history of helping truly agile organizations. LitheSpeed is starting the path of delegating most authority to team members including profit sharing and hiring decisions, using a Spotify Tribe model and extreme transparency, implementing a simple set of peer-based operating procedures, and deemphasizing titles.

Bob shares lessons on building the organization, culture, and systems to support the transition. Although it’s early in the journey and the road is sometimes rough, Bob is excited about the prospect of a Teal future.

Come hear the good, the bad and the ugly side of this long days journey into teal.

(This talk was well-received in 2015, so we can do an updated version for 2016)

DevOps as a buzzword is gaining traction, but what does it really mean? Managers, non-techies, and developers-new-to-devops will get a guided demo of development automation. See all the cool tools in action - continuous integration, automated testing, cloud deployment, etc. More importantly, we'll walk through what they do, and why that adds value to a project. 

This talk will...

• Break down the buzzwords and define some key technical practices in plain english.
• Uncover the pain that leads teams to seek greater automation.
• Demonstrate a continuous integration pipeline working in practice via live demo.
• Diminish the knowledge gap between technical practitioners and managers/analysts/coaches.
• Level-up the vocabulary of non-technical attendees.
• Introduce practices to developers who don't yet work in an automated environment.
• Spark "ah-ha" moments to convert skeptics into DevOps believers!

By the way, all of the tools in the demo are some combination of free and/or open source. DevOps doesn't have to cost a lot.

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.