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!

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. 

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)

Software development culture has been dominated by the hero. Rock stars, ninjas, and 10Xers have been the center of attention, giving the skewed perception that great software is the result of a single amazing developer. But this couldn't be further from the truth.

In this talk, Andrea Goulet, the CEO of Corgibytes, will share her experiences using vulnerability and empathy as drivers for Agile adoption and culture building. 

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.

Building an Agile organization starts with great teams and a positive culture, but what really happens when your organization starts to transition its product delivery to Agile?  How much focus are you putting on building the culture, teams and growing communities inside the organization to drive real, lasting change?  Do you have a strategy to change the organization and build better teams & communities or do you prescriptively follow a framework and hope the culture change follows?

In transforming the way you work, focus on things that will enable the long term, sustainable growth of Agile throughout the organization, and the larger the organization the stronger the underlying community needs to be.  This is a key difference between the organization "being Agile" vs. "doing Agile" and one piece of the cultural transition.

In this talk we'll explore team building and community inside an organization.  We'll look at what helps to enable a high performing team, how to grow your organizational communities around the team to enable them for success, how to prime the organization for the team's value delivery and finally how to spread the knowledge & culture to drive organizational change.  

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.