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.

As the adoption of Agile DevOps has been steadily growing over the years, many organizations have been taking a proactive approach to prepare for the changes needed for success.  This means building our people and organizations with the skills and resources they need to be successful and working with our customers and users for improved collaboration to enable transparency. We have worked to provide our teams with the tools and infrastructure to enable continuous flow of value.

What do legacy organizations need to transform from Horses into Unicorns? Are there constraints in government programs not regularly seen in commercial industry? Are there commonalities across these organizations that others can learn from to support this journey? 

Suzette Johnson and Robin Yeman are both leading large Agile transformations at different companies with growing implementations of DevOps on large and small scaled programs. While there is not a single pattern to move large legacy organizations to DevOps, it’s amazing the similarities found across two different companies. Through multiple collaboration opportunities they have found similar effective practices and lessons learned.  Join Robin and Suzette as they provide an interactive discussion around the proven practices for large scale transformation, the challenges they have experienced, and the amazing similarities of two Agile DevOps journeys. Their discussion focuses on activities that have been implemented to cultivate teams and build the necessary skills for this transition, to build the infrastructure that enables a DevOps environment, to improve the value stream and extend the mindset of change across the organization, and ways to measure success.

 Specific techniques: Cultivating teams, Building the infrastructure, Change in practices across the value stream/organization, Measures of Success

 Metrics: Reduced Cycle time for Feature delivery; Reduced Mean Time to Repair; Increase in test automation with improved quality; increased delivery of value, Increased transparency for stakeholders

User Stories are a fantastic way of bringing together someone who is requesting a need and someone(s) who will transform that need into a working increment. Inevitably, we encounter needs that are large in nature, too big for a sprint. What do we do about those things? What if we are working in a multi-sprint release? How do we break those large things into smaller sprint size chunks and maintain the concept of potentially shippable increments?  Let’s explore that world with a few techniques. 

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

Reorganizations are notorious for being "a wonderful method for creating the illusion of progress while producing confusion, inefficiency, and demoralization" (credit to Charlton Ogburn). Yet in many cases they are necessary to create the cross-functional, self-organizing teams that succeed the most with the agile mindset. Because reorgs are so painful, many teams and organizations are reluctant to look at team structure at all, and the agile journey is over before it even begins. The result? Organizations and teams are siloed, hierarchical, and process-heavy. If an organization is structured right, it can create fertile ground for a truly agile enterprise. This talk will outline how to approach reorgs for agile teams and minimize the pain using change management techniques.

Agile cost money just like waterfall does. Your software labor costs will be all internal (no vendors), all external (only vendors) or a mix. Paying for software labor by the billable hour means no connection to delivered business value and if vendors are using fixed pricing methods, hidden premiums may unnecessarily inflate your costs.

 This 45 minute interactive discussion includes how two organizations focus on quantitative sizing analytics and estimation best practices and how their Enterprise Managers today manage & reduce costs, improve predictable delivery and quantify business value. These Enterprises are investing tens of millions of dollars in Agile implementations at scale and need non-relative (normalized) data that is meaningful instead of relative aggregation of team level measures. Learn how they are adopting program and portfolio level measures and metrics to have real conversation about business value delivered.

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.

• Is your team performing, but not succeeding?
• As a leader, do you ever ask yourself, "why don't they seem to care?"

If you answered yes or even, "yeah, maybe" -- then you may have a challenge with engagement. It may not be a problem of a team working hard or even working well together, but it may simply be a problem of finding challenge in their work or a lack of clear vision around what they are trying to accomplish -- all of which are driven by a lack of Purpose. Purpose provides the connective tissue between the organizational strategy, product goals, and team motivations. Ultimately, an organization's Purpose sets the tone for their culture. As leaders, and sometimes as change agents, it is our responsibility to help teams learn and establish the Purpose of their work.

It is important that we create an environment where our teams grasp why. In this session, we'll explore why Purpose is important and how it drives vision from the organization to the team to the team members. We will look at the science of Purpose, and the power of it -- how it enables engagement, improves team morale, and can improve performance. During the session we'll leverage some simple facilitation techniques that you as a leader or team member can help clarify your Purpose.

DevOps lore tell legendary tales of “Unicorn” companies. We’re told these mythical companies continuously deliver software to production with nary a blemished aura or mussed mane. Can it be so? Is this but a fairytale?

In this talk, we will dispel the fantasy and show you how to get similar results. Spawning the first unicorn is the most difficult, so I will show you the specific steps, tools, techniques and architectural patterns of Operations First Delivery to create your first “Unicorn” project.

Typical mistake many startups do is engineering idea before validating to learn whether it'd solve the problem. Obvious approach, also another mistake, is to run in a shorter sprints, demo, & get feedback till team realizes that features doesn’t seems delightful or satisfactory. Consequently, the app isn't often used by many as predicted once shipped. Speaking of learning, experimenting with a fake app to validate the idea is a cheaper, faster, a smarter strategy that's worth investing therefore.

What's there to validate about your ideas? What are the cheaper, smarter, and faster ways to engage with users to decide what a good idea is and what a stupid idea is? Let's meet to learn some of the pragmatic ways to validate your ideas before putting everything to leap-of-faith.

I had been introducing some of these tactics to many product teams, forums such as IIBA, Google Business Group events during last few years and now that entrepreneurship and startups has become one of the buzzwords, I am pleased to learn new methods that audience has to share.

Abstract: Fannie Mae, a leading source of residential mortgage credit in the U.S. secondary market, provides reliable, large-­scale access to affordable mortgage credit across the country to help individuals buy, refinance, or rent homes.

Coming out of the housing crisis in 2013, Fannie Mae recognized that the lending environment it was moving into required it to be even more responsive to meet rapidly changing customer needs.  Further, Fannie Mae recognized that agility was critical, not just in technology, but across the enterprise to achieving this objective.  

Over the last 2 years, Fannie Mae has undergone a concerted effort to adopt the agile values and practices and has begun to recognize the benefits promised. Today, there are more than 170 agile teams across Enterprise IT, and both functional and business portfolio's are adopting lightweight agile values and practices as part of their day-to-day activities. 

As a result of transforming from Waterfall to Agile, Fannie Mae experienced a significant boost in productivity as well as a reduction in delivery risks through the relentless focus on innovation and automation to ship "production ready" code with high and higher frequency. The transformation to Agile has revolutionized how the firm plans for the delivery of large scale ($100 million plus investment/year) programs, has significantly mitigated risk inherent in complex in integration between legacy and new architectures/applications, as well as between internal and external systems.

Within the larger context of the transformation to Enterprise Agility, this Executive Panel Discussion will provide unique Executive insight with respect to the organization's journey to date and goals for the future.

Fannie Mae Executive Panelists:

• Bruce Lee, SVP & Head of Operations and Technology, O&T Executive Office
• Stephen Pawlowski, SVP for Business Solutions Initiatives, SF Mortgage Business 
• Frederic Veron, SVP & Head of Business Technology and Delivery Services, Enterprise IT
• Mike Garcia, VP for Development Services, Enterprise IT
• Scott Richardson, VP for Enterprise Data Strategy Execution, Enterprise IT

Moderator:

• David McMunn, Director, Agile Center for Excellence, Fannie Mae

The agile manifesto challenges us to favor customer collaboration more than contract negotiation, but what does that really mean and how do you actually do that?  Join us to experience a “fun” ideation framework that teams can use to engage in dialogue with their customers to determine what needs of the team / customer relationship are most important at the present time and then as a group decide on practices to support the highest priority needs.  As the ideation framework is completed, teams and their customers will be challenged to work together and achieve consensus on a limited number of priorities since we all know what happens when we try to make EVERYTHING a priority.  “Let’s Be Awesome” concludes with teams establishing and agreeing upon working agreements to build an “awesome” relationship between customer and team.  In this hands-on and highly interactive workshop, participants will have a chance to learn how to use the “Let’s Be Awesome” framework and cards to facilitate a team / customer ideation session focused on establishing the foundation for a strong relationship; an opportunity to learn, review and discuss many agile practices supportive of effective team / customer collaboration; and a chance to experience a “MarketPlace of Ideas” where they can exchange recommended patterns and practices for customer collaboration from others also attending the workshop.

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.

In the Federal space, it is often a mix of government staff, multiple contractors and subcontractors making up an Agile projects and teams. While collaboration is a key pillar of an Agile mindset, it can be a challenge to build a collaborative environment in such a multi-entity environment. This talk will cover several case studies and will present:

• How we successfully trained many teams of blended entities through a robust learning roadmap that covered everyone regardless of employer
• How we worked to establish a ‘one team’ mindset through team building workshops and collaboration exercises
• How we worked to establish cross functional collaborative teams, team norms, etc in a multi-contractor environment.
• Successes, failures and lessons learned

Warning, road closed use alternate route.

Has your agile transformation stalled? Are you treading water? Does it feel like your standups are just going through the motion?  Sounds like you need a Transformation bypass.

Any agile transformation is a challenge and can stall if it doesn't get the right amount of attention. Maybe you had a consulting firm come in to lay out a roadmap. Only after they left the anti-bodies rushed back in. Or your tried to kick it off internally, to find yourself never getting off the ground despite executive support?

This session provides a playbook for re-engaging (or engaging from the get go) an enterprise agile transformation. A week by week, play by play guide for enabling the change engine to get enough momentum to keep going despite the resistance.

This playbook is based on what we are doing right now in the AOL Platform's division. From day one hitting the ground to when and how you roll out common training, to what you do next, and next and next.

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. 

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.

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

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

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.

"Companies know that they derive greater creativity and innovation from teamwork - but what, they wonder, makes a great team?"  -Margaret Heffernan

The research is clear: High performing teams are extremely rare, but their ability to impact an organization is limitless. If we know this is what we're aiming for, why is high performance so elusive and how can organizations and leaders create environments where it can flourish?

In this unique session, participants will have the opportunity to observe and interact with a high performing team (live and in the flesh!), discuss what makes them a great team, and learn about the various roles that make them who they are. Through performance and a facilitated conversation, the Ars Nova Chamber Orchestra (ancoselfconducted.org), Washington DC's premier self-conducted orchestra, will offer insights into their organizational dynamics. You will observe and discuss what makes them tick and take away practical examples of how you can supercharge the teams you work with or coach.

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.

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

You have made great progress at the team level with Agile, but your company still does not feel nimble and responsive.  What is wrong, and what can you do about it?

In this talk we show how executives and senior leaders can transform their organization/company to create a truly Agile Enterprise, by transforming corporate functions and enterprise shared services.  

The corporate ecosystem outside of teams must be transformed to achieve enterprise agility, but it is beyond the scope/authority of team members, managers, and consultants to make these necessary changes; these transformations can only be done by senior leaders and executives.  From an executive's viewpoint we will describe the nature of the corporate ecosystem outside of teams and how - if properly transformed - enterprise services can be the missing link between team-level results and real company-wide agility.

“Every line is the perfect length if you don't measure it.”  - Marty Rubin

So your organization has embarked upon a transformation to be more nimble and responsive by employing the latest tools and thinking in the Agile and DevOps arena.  In this transformational context, how do you know that your initiatives are effective?  Empirical measurements should provide insights on business value flow and delivery efficiency, allowing teams and organizations to see how they are progressing toward achieving their goals, but all too often we find ourselves mired in measurement traps that don't quite provide the right guidance in steering our efforts. 

Rooted in contemporary thinking and tested in practice, this talk explores the principles of good measurement, what to measure, what not to measure, and enumerates some key metrics to help guide and inform our Agile and DevOps efforts.  If done right, metrics can present a true picture of performance, and any progression, digression of these metrics can drive learning and improvement.  

It is our hope that this session inspires organizations and teams to start or take a fresh look at implementing a valuable measurement program.

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

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.

I recently was put on a project where we were doing development for a website. There was already a large code base, and we went in to add features in order to complete the site; including performing code refactoring when necessary. In order to accomplish this successfully, we wanted to build a complete DevOps pipeline, ensuring the application was being tested early and often: static analysis, unit, smoke, acceptance, security, feature, load, and performance. None of this testing was previously in place, and to ensure the refactoring doesn’t break anything, this testing became critical for us.
This session will discuss setting up a complete DevOps pipeline, with a quick CI cycle, followed by automated and scheduled CD cycles to QA, Staging, and Production. We will cover the many pitfalls of integrating already built code into this process, and some lessons learned and good strategies for other teams looking to accomplish this. Tools and techniques used for a PHP project will be demoed, but all of these practices can be applied to any project.

You’ve been a program or project manager for years and now all of sudden you’ve been asked to be a scrum master on an Agile project.  With less of an emphasis on controlling scope, what exactly do you do now?  This talk will share and explore various ways for newly minted scrum masters to contribute to the value of their project team by taking you through various scenarios that scrum masters encounter on a daily basis.

"Companies know that they derive greater creativity and innovation from teamwork - but what, they wonder, makes a great team?"  -Margaret Heffernan

The research is clear: High performing teams are extremely rare, but their ability to impact an organization is limitless. If we know this is what we're aiming for, why is high performance so elusive and how can organizations and leaders create environments where it can flourish?

In this unique session, participants will have the opportunity to observe and interact with a high performing team (live and in the flesh!), discuss what makes them a great team, and learn about the various roles that make them who they are. Through performance and a facilitated conversation, the Ars Nova Chamber Orchestra (ancoselfconducted.org), Washington DC's premier self-conducted orchestra, will offer insights into their organizational dynamics. You will observe and discuss what makes them tick and take away practical examples of how you can supercharge the teams you work with or coach.

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)

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.

As the reach of Agile methods grows, organizations are finding that they have to adapt beyond technology groups in order to achieve the pinnacle of their benefits.  This session will provide both historical context and practical tips for introducing these ideas from a business leader that has experienced them directly.  Enjoy:

• A brief history of the trends that have led to this more holistic application of lean and agile ideas
• Specific examples of how aspects of agility are being applied in domains like HR, Marketing, Finance, Sales & Operations
• How to introduce and support such tectonic shifts without destructively disrupting the business

A few years ago everyone wanted to know how to convince their executives to go agile. Today's executives are asking their teams how they'll get them there. While we have made significant progress changing the hearts and minds of senior leadership, executives have a fiduciary responsibility to the performance of their organizations. They demand a greater level of assurance that what you plan to do is actually going to work. Executives are sick and tired of being told to trust the team and that everything will be okay. Better than anyone, executives see the dysfunction in their organizations. They want line of sight to how agile is going to help them make things better. 

This talk is going to explore a safe, pragmatic, and repeatable formula for leading change in large organizations. The Holy Grail for an executive is to tie dollars spent and activities performed, to internal improvement metrics and ultimately improved business performance.

You've probably heard that You can't improve what you can't measure and, over the years, teams have used various techniques to make the invisible visible. From value stream mapping to burndown charts, making things visible is a core component of the continuous improvement process. Brandon says that even with all this visibility, much of the data surrounding how your teams work is either not captured or not visible, and thus represents a great opportunity for improvement. Imagine your management team tells you that your velocity is too low. Why is it too low, and what can you do about it? Brandon shares one team’s surprising answer to that question when they analyzed previously invisible data. How do you know what the highest risk areas of the system are for enabling the most cost effective regression test strategy? You'll get that answer, too. It's all there, tucked away where no one can see.

Does your team treat test code differently than production code? Do you let your test code accumulate duplication and complexity that you'd normally attempt to squash in your production code? Have your tests become brittle? Are you worried that they aren't providing you the same value they used to? Have you strongly considered dumping your test suite and starting over? Are you afraid that if you refactor your test code, you'll introduce false positives?

If you said yes to any of those questions, then this talk is for you.

We'll explore the technique of "refactoring against the red bar" (http://butunclebob.com/ArticleS.MichaelFeathers.RefactoringAgainstTheRedBar), and how you can employ this technique to confidently refactor your test code. No longer do you need to let your test code have a lower standard of quality than your production code.

 Training is often the first step in implementing an Agile transformation within an organization.  Often an agile coach will corral resistant staff members in a room and sell the virtues of Agile with disappointing results.  But at the United States Citizenship and Immigration Services, students are clamoring to voluntarily attend full day sessions and recommending classes to their colleagues.  The organization has successfully grown the Agile Training Program to include 10 courses taken by 2200+ attendees from 25+ federal agencies.  The training is not required on anyone’s mandatory curriculum, but instead is taken because students feel it provides real value enhancing their ability to work well in the organization.  Effective training doesn’t just educate, but instead changes behavior.  

The masterminds behind the USCIS Agile Training Program will unpack the secrets to their success.  Mash Eslami, USCIS Section Chief of Agile Training, and Melinda Solomon, USCIS Agile Training Lead explore 10 factors that make students receptive to learn.  Part Experience Report, part Case-Study, this session will explore:

• How to choose your initial audience
• What to do with resistant students
• How to structure a course that changes behavior
• Ways to grow the program
• And much more…

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. 

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.

Often, we will use the phrase agile acquisition when we really mean acquisition for agile. Both agile acquisition and acquisition for agile are necessary to deliver efficiently across government organizations. The processes within the federal government for doing acquisition means that we may spend a year or more to award a contract for work to begin. This creates a significant delay is beginning projects or programs that impedes the speed of delivery. Instead, we need to move toward a true agile acquisition process where we change how we execute acquisition so that we can begin delivery in much faster fashion.

This workshop will examine how to change our acquisition processes to become more agile and able to support the delivery of IT services in a much faster manner. We will look at both successes and failures in acquisition and determine what changes need to be made in order to meet the quickly changing needs of government. Both contractor and employee viewpoints will be considered and discussed. We will look specifically at ways that government is trying to make these changes in the DHS Procurement Innovation Lab, the Office of Federal Procurement Agile training, as well as others and how those activities may play into your organization and procurement activities.

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!

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.

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. 

Fannie Mae, a leading source of residential mortgage credit in the U.S. secondary market, provides reliable, large­scale access to affordable mortgage credit across the country so people can buy, refinance, or rent homes. In November 2014, Fannie Mae’s Enterprise Data Warehouse completed a multi­year project to implement several thousand data attributes across numerous interfaces which were then integrated with various development organizations working in parallel; the results were sub­optimal. In January 2015, Fannie Mae undertook a brownfield initiative to transform Fannie Mae’s Enterprise Data Warehouse, responsible for sourcing, vending and provisioning data attributes, which informed numerous interfaces, as part of a larger Federal compliance mandate, to SCRUM. Initially, starting with two teams using SCRUM, the initiative progressed to six-teams implementing SCRUM­OF­SCRUMS, within 6 months. Thereafter, the SAFe framework was adopted encompassing twelve­teams (130+ team members) on a single Agile Release Train. As a result of transforming from Waterfall to Agile, Fannie Mae experienced a significant boost in productivity and reduction in delivery risks through the relentless focus on innovation and automation to ship "production ready" code with high and higher frequency. The transformation to Agile has revolutionized how the firm plans for the delivery of large scale ($100 million plus investment/year) programs, has significantly mitigated risk inherent in complex in integration between legacy and new architectures/applications, as well as between internal and external systems. Within the larger context of the transformation to Enterprise Agility, this Experience Report will focus on the changes to the organization, architecture, and technical practices required to implement data attributes every two­-weeks and the corresponding benefits realized.

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!

Have you ever been stuck between a rock and a code place? Learning to code can feel as daunting as climbing Mount Everest! In this talk, I’ll share seven software development best practices I learned through rock climbing.

This talk will…

• answer how do I start?
• address the mindset for coding
• discuss the value of practice versus profession
• introduce the benefits of doing what you love
• ideate on how to find help and support

What do climbing rocks and writing code blocks have to do with one another? Come learn some techniques and strategies for becoming a better software developer (and incidentally maybe a better rock climber too)! No harness and rope required!

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. 

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.

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.

Today, knowledge workers are seeking to find meaning in our lives and purpose in our work. With this new generation of employees who are as interested in purpose as in profit, it is imperative that we revisit management schemes like top down work assignment, the annual review, strict “clock punching” work hours and inflexible vacation policies; and recognize their negative effects on individual morale and team productivity.

As leaders, it is time to recognize and own our responsibility in these counter productive techniques and boldly move into the future with radical alternatives. Now, with organizations as diverse as Virgin, LinkedIn, The Motley Fool, and Zappos applying Frederic Laloux’s “Teal” system to revolutionize management, it is time for us to undergo personal transformations and to lead as well as we manage.

Join Sanjiv to learn how to create the space for a “results only” workplace with a flatter organization structure, work anywhere flexibility, participatory profit sharing, and delegated hiring and firing. Explore the leadership journey needed, with its fears, challenges and tribulations; as well as its joys, triumphs and unassailable business results.

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. 

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. 

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

Max Weber and Michel Crozier both got it right when they described the ideal bureaucracy which is the number one impediment to Agile efficiency in the Federal government.   Perhaps a grand re-organization, accompanied by lots of "systems analysis," “customer participation," "cooperative federalism," and "interdepartmental coordination " might lead to something getting done.   Merely to state this prospect is to deny it.   There is not one bureaucracy problem, there are several and the solution to each is in some degree incompatible with the solution to every other.  There are inherent limits to what can be accomplished by large hierarchical organizations.  this though proving session faces the issue and suggests meaningful methods to approach bureaucracy as an impediment and address procedural stagnation, attitudinal fixtures, rule-bounded-ness with interventional strategies.   By understanding ecology of agile governance, strategies can be designed to evolve a system with procedural innovativeness, attitudinal mobility, rule flexibility and wider interest.   A very complicated subject, but one that shouldn't be ignored because it is hard to solve and can't be fully addressed in 45 minutes.

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.

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.

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.