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!

Agile methods help to build a repeatable and reliable pipeline of working code to production. Unfortunately, complex enterprises, including the US government, consider agile the solution to finding and solving all their copious and complex problem. In this space, agile alone is not enough. Reliable enterprise problem-finding and solution-creation techniques aren't yet embedded in the agile toolkit, but nonetheless that's the toolkit brought to bear on critical, complex organization-spanning issues. Typical problem/solution methods can create a local optimization (look at this great thing the team delivered!) but create a global failure (the team didn't consider the other systems and teams involved in the process, and broke them). This is the norm, not the exception, and why large project solutions are typically "meh", not "wow". Given agile is now the de facto approach, now is the time to focus on being exceptional.

In this talk, we'll cover three years of the fight to achieve agile success on a critical project at the Department of Veterans Affairs: the struggle to enable an agile environment and the realization of what agile at scale REALLY means; the tactical and strategic efforts to identify the fundamental, success-blocking problems of the enterprise, and how to solve them; and what it takes, from discovery, analysis/design, code/test, and release to production, to deliver actual value, and not just "working code."

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 any of this sound like you?

• You’re a changemaker working on a complex problem either as an entrepreneur or intrapreneur. You have some resources for making change but will need to work with partners, policymakers, or others to scale your impact.
• You’re a product manager, business analyst, designer, architect, or systems engineer in a large organization.
• You’re working on a difficult problem which will need to be solved in phases over months or years.
• You’re managing a portfolio of work that spans multiple time phases or teams.

Are you running into any of these problems?

• The product design cycle is taking too long.
• You’re delivering value but getting a lackluster response from customers and stakeholders.
• You have great ideas and the customer likes them, but there's no roadmap to get them into production.
• You have multiple stakeholders, none of whom are on the same page.
• You don’t have one single, completely informed decision maker who can make the final call.
• You’re having difficulties reconciling modern experiences with legacy systems and business processes.
• You have “wicked problems” to tackle but your organization is ignoring them in favor of low-hanging fruit. And you’re starting to run out of low-hanging fruit.
• You’re having difficulty helping other people focus on anything beyond the latest fire.

If any of that resonated with you, an Enterprise Design Sprint might be exactly what you’re looking for. Combining elements from agile, design thinking, enterprise architecture, and systems engineering, Enterprise Design Sprints will help you make sure that you're delivering value over the long term. This talk will cover the theory and mechanics behind planning and running your own sprint, with examples from the U.S. Department of Veterans Affairs. 

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)

(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.

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

Government missions are complicated undertakings; wouldn't it be great to be able to understand all of your key components at a glance? This session will review the use of a Business Canvas to capture what your organization does, regardless of size or mission, on a single page.  It will also cover  analyses that can be done using such a canvas, both logically and via experiments, and how this can fit into transformation. The demonstration will also show how decisions you make for improvements  on your canvas can fit into your project or program portfolio.

This interactive demonstration will walk you through the concepts using a real Government organization.

We firmly believe that automated testing puts the "A" in "Agile". Without an effective suite of automated tests your ability to be truly agile (that is embrace change) can only be based on the hope that your latest change doesn't have unintended consequences. Additionally, without automated tests, you are missing a vital component in getting feedback into the development team's hands. In our travels, we have encountered many organizations that are struggling with automated testing. These organizations are successfully adopting many Agile techniques but are failing when it comes to automated testing. We frequently hear "Automated testing just doesn't work for us" (eerily reminiscent of the days when we would hear, "Agile just doesn't work for us"). From our experience addressing their challenges, we have identified anti-patterns common across these organizations. These anti-patterns look like they should work, but are in fact doing more harm than good.

This talk is about those anti-patterns. We have given those anti-patterns a name and a face to help organizations understand why they are not getting the benefits from automated testing that others are. We describe several anti-patterns, such as the "Ice Cream Cone", the "Monolith", the "Sunk Cost". We explain why these anti-patterns appear to be good solutions, what makes them attractive, and why they do more harm than good. We talk about the right approach and draw on our experiences helping organizations adopt a robust automated testing strategy that instills confidence and provides fast feedback to the development team. We explain what benefits from automated testing the anti-pattern is preventing. 

What if I told you we are experiencing the thrills of a lean startup and the perks of large enterprise?

We have proven it can be done, and not in any old environment, but the highly regulated and governed one that is the financial industry.

Sad to say, Agile has become a marketed commercial solution. This trend has caused us to get away from the essence, roots, and intent of Agile. By nature, Agile is an adaptive methodology that stresses continuous improvement. However, ironically we have somehow managed to sell Agile as a bill of goods that will magically solve the problems of all organizations. The truth is there is no one-size- fits-all framework because every organization is unique and has its own set of challenges.

There are a number of different approaches to adopting agile. The key is finding which blend of agile and lean practices will enable you to achieve your objectives.

Although the “Lean Startup” methodology originated in small start-up environments, its concepts and techniques can be expanded to the corporate enterprise. In fact, many companies are adopting Agile because they are seeking innovation, agility, and a competitive edge. The lean start-up methodology is geared towards achieving these exact objectives and can be setup to work within a large enterprise.

Organizations in the midst of a bottoms-up agile transformation can find themselves in a quandary. Even though some (or even all) teams may have adopted agile at the developer / program level, PMOs are often still required to plan, resource, and report on progress with almost no consideration given to the methodologies of the underlying work. 

There is much talk about diversity in the software development field and in the tech industry in general, and yet most teams and organizations comprise mostly a single cultural group. The dominant group may be 20- and 30-something white males, as is common in Silicon Valley, or some other culturally homogenous group, such as H1B holders from the same country, as is common in large corporations. 

When nearly everyone in an organization has the same general worldview, problem-solving approach, educational background, life experience, and so forth, the organization tends to suffer from groupthink - they can only conceive of a single approach to achieving a goal or solving a problem. When faced with a unique challenge or an unexpected change in circumstances, such an organization often has great difficulty.

In contrast, a diverse organization can bring to bear a variety of perspectives, experiences, collaboration styles, and problem-solving approaches. The rich blend of differences enables the organization to adapt to change and to overcome unexpected challenges creatively and flexibly. How can we build a more diverse workforce in the software development field?

There are dozens of quality project management applications to chose from today. But most are either complex or costly. This presentation will show how you can effectively use github issues and Waffle.io. The beauty of this strategy is that most shops today use github and waffle.io does a great job of providing a visual, Kanban representation of github issues. Discover how Corgibytes.com uses Waffle.io and github issues to provide project management for multiple clients. 

The presentation will cover how to set up Waffle.io and cover strategies for effective and efficient use of Kanban. It will also cover tricks and techniques used to circumvent some of the limitations of github issues. 

Visual artifacts are a great way to engage with users and get feedback. We used to do lots of mockups in tools like Balsamiq. Our teams are now good enough at creating real code prototypes that we tend to work out ideas in real, interactive applications. The talk discusses the tradeoffs and shows real demos of what it takes to quickly make prototypes. Participants walk away with a stack of tools they can use to start making prototypes today.

"You can't do agile until you have the technical practices down"

"Just start with Scrum, everything else will follow"

"We have to change the mindset here first!"

Do any of these sound familiar? Where does an agile transformation need to begin? In this workshop, participants will play "Wheel of Agile Transformation" where they will spin a wheel and develop their own story on how an agile transformation within their organization is rooted in focusing on either technical practices, process, culture, or other areas!