The presentation is a case study of how Agile (Scrum/Kanban) can be applied to business development (BD).

Business Development is about managing increasing amounts of investment or determining where to invest. Agile business development is about learning, failing and succeeding quickly in this process. This talk presents a case study from the presenter's personal experience in coaching, training and mentoring 6 BD teams how to apply Agile to their work. 

The case study will cover how the following challenges of applying Agile to BD activities were addressed:

• How do you define a Release?
• How to do release planning?
• How to define Sprint goals?
• Do we write User Stories? 
• Do we size the stories?
• Do we calculate velocity?
• How do you do Sprint planning?
• Do we need a Scrum Master? Who should play this role?
• What is the right duration of a Sprint?

Agile scaling models tend to be based on scenarios where 5 - 10 agile teams are working on the same project/program/product/value stream.   The scaling models provide some good ways of organizing the work that needs to be done to plan, synchronize and demonstrate the outputs of the teams.  This case study describes the path of a development group that has 10-12 teams working on about 50 different software "products and services" within a reasonably narrow-focused energy company.  The case study describes how they went about paring down the SAFe model to meet their needs and then prioritizing the scaled-back scaling transformation using group inputs to a weighted shortest job first exercise.

Situation A: Your team is great. You’ve met all your sprint goals and your Product Owner is pleased with the results to date. Yeah!

Situation B: Your team sucked. Zero story points completed last sprint. Team members are complaining and blaming each other for the failures.

These two situations demand two very different retrospectives. The right retrospective can make a good team great and turn a bad situation into a learning opportunity. A bad retrospective can set a team back and create a non-safe working environment.

In this session, attendees will explorer retrospectives techniques and examine the pros and cons of the techniques. The workshop will then explore scenarios and examine how to effectively run retrospectives across a variety of scenarios.

Coming out of this sessions, attendees will have an understanding of applying the right retrospectives based on the state and needs of the team and projects.

You probably started your Agile journey with Scrum, which helped. But regression testing still takes forever. New feature tests aren't what they could be and are hard to complete within the Sprint.

If you have active product owners, the POs helped to improve your product, but there is still a disconnect, between the user story and the tests.  And how do you test "as a, I want, so that"?

Now you hear you need Agile technical practices to keep improving and you find you need to automate. What are you going to do with your testers?  They really, really know your business, but they don't code.

If you are a manager, a tester or a product owner, come hear Camille as she shares her experience successfully teaching manual testers Automated Test Driven Development and showing product owners how to write great Acceptance Criteria that are easy to automate.

In this session you will learn:

• How to get your product owners, testers and developers to understand each other
• How to make your business scenarios unambiguous and testable
• How to avoid brittle tests that need frequent rewriting
• Which tools and languages are better for testers to learn and why
• Strategies and techniques for testers to learn test automation
• Where to find inexpensive and free resources to get started

Ever solve a jigsaw puzzle?  Do you typically design and document all your pieces before assembling the puzzle or know anything about the kind of picture formed by the puzzle?  Hardly.  Usually, the specifics of the puzzle, as they emerge through the process of solving that puzzle, affect our tactics for solving it.  

This analogy is at the heart of Exploratory Testing (ET) - a fun, focused and powerful approach to testing that has been gaining in popularity in recent years.  While not a new idea, it is often misconstrued as being a random, flailing at the keyboard approach to uncovering problems.  Not quite.  ET is a disciplined practice that involves simultaneously learning about the software under test while designing and executing tests, using feedback from the last test to design the next.  It leverages traditional test design analysis techniques and heuristics, but design and execution become a single inseparable activity.  Within the agile context, there is a need for agile teams to augment their scripted automated tests with a manual testing practice that is adaptable, and ET provides the right fit.

In this session oriented towards beginning explorers, we will gain a deeper understanding of what ET is, what it isn't, and discuss the essential elements of the practice with practical tips and techniques for: learning the system under test and capturing our understanding to design tests; designing tests on the fly using heuristics; executing tests and observing results; and finally, integrating ET into the cadence of an agile process.

Are you struggling to implement Agile at your company?  What could be better than to learn from someone who has done it wrong over and over! We want to share our experiences pioneering Agile at a FinTech company.  After multiple attempts and through sheer stubbornness, we were we able to get it right and improve our release pace by 650% annually.  We will walk through where we went wrong, what we did right, and why we now understand that Agile cannot be successful without profound collaboration, Continuous Delivery, a DevOps culture and a desire to continuously improve.

How many times have you heard someone say that scope is fixed and then throw a tantrum when they hear how long it will take to build?  How many times have you seen the spirited creativity of development teams evaporate when a stakeholder tells them the deliverable cannot be changed at all?  And how many times have you discussed agility with naysayers who say, "That's all fine in an ideal world when you are building some hip little application, but we're in the real world with real projects with fixed scope."

This presentation explores the myth of fixed scope, how damaging the notion is, and the tool we all have at our disposal for escaping the trap.  Come explore how natural it is to use it, and yet how vigilant we need to be to keep ourselves from casting it aside.

Gerry Weinberg once said of consulting “There is always a problem, and it’s always a people problem.” The world of DevOps is emerging rapidly, and just like the early days of Agile, is still working on refining exactly what DevOps means.  So often, the focus is either on the technical aspects of the various tool, or on the people problem of “bringing Ops into the room”.  But what is the problem that DevOps addresses, and is that problem more of a technical problem, or a people problem?  We will explore this, and look at the possible intersection between the two “problems” and how a DevOps approach can help overcome them.

“More and more organizations are realizing the benefits of running projects using Scrum, XP, and/or Kanban at the individual team level. Unfortunately, the typically means that in a 12-24 business idea to production time-frame, the “Agile” part may only be a 1-3 month “construction” phase with rigid controls in place that all but eliminate most of the benefit of Agile.  The root cause of this issue is that the whole organization is purpose-built to support and reinforce traditional methodologies while unintentionally impeding and discouraging the use of Agile methodologies. This is reflected in the organizational structure, physical location of people, the physical workplace, policies, procedures, governance, SDLC, contracts, vendors, belief systems, compensation, software tools, funding model, metrics, and more. A common belief is that all of these are set in stone and that Agile will need to fit in to this existing framework. As a result, many Agile adoptions eventually regress as the effort of working around the existing framework overwhelms the enthusiasm of the Agile evangelists. Unlocking the full power of Agile requires an understanding that changing the status quo is a long-term, organization-wide, major initiative that will take significant resources to accomplish. Such an initiative will only be undertaken if the rewards are significantly greater than the cost. In this session, you will learn about the true barriers to Agile adoption; the surprising and significant financial benefits of organization-wide Agile transformation; and the Kotter Change Model, an approach for implementing major change management efforts.”

The Tadpole Technique is an approach that teams can use to break a larger idea into smaller pieces in an interactive and visual way.  This facilitated session is a way to get team members to participate in some chatter as well as as generate a few takeaways from the session.  This technique is useful in meetings where a group of approximately ten individuals and a facilitator go through a series of discussions following a brief writing activity.  The result is a visual representation of the teams thoughts and discussion, and can be used to further expand later talks or to create some takeaways.

This talk will explain the mechanics of this technique, what teams will need, and explain how to facilitate the session.  Participants will then engage in an exercise where they get to experience the technique as a group, enhancing their ability to facilitate future sessions of their own. 

Often when organizations go through an Agile transformation, there are some concepts that are challenging to address or adopt. We have a tendency to avoid the ‘crucial conversation’ so as not to hinder progress. Eventually these fundamentals can get overlooked or "put on the back burner". At this point transformations stall, and we find that our process is operating more like a 2 week waterfall than an Product-Increment-Producing-Machine-of-Wonder. I believe this behavior is one of the drivers for the ‘scrum-but’ concept.

This session will delve into anti-patterns, bad smells, and other pitfalls which are keeping organizations from reaching the next level of Agile adoption. We’ll examine common warning signs and identify strong signals that indicate that a sprint time box is not being optimized. Once we’ve identified the challenges, we’ll explore best-practices, tweaks, and courageous actions to get teams collaborating in a first-class manner. 

In short:  Step 1: Understand what is hindering our Scrum practice. Step 2: Surface actionable remedies that we can apply tomorrow.

As we see Agile evolving through the years, particularly into the government space, a lot of terminology is used that seems foreign to many who first used agile with their individual teams.  "Hybrid Scrum"..."Delegate Product Owner"...even "Scaled Agile".  Are these simply extensions of the agile values and principles in the manifesto to fit a different and more complex environment, or do they represent a diluting of those same values and principles?  Explore in a facilitated workshop with your peers whether such terms are appropriate (maybe even necessary) to adopt agile in the complicated enterprise, or whether they represent (oxy)moronic agile and a step backward.

Do you want to be able to “trust the wisdom of the group” but find it difficult? Do you ever feel like you’re having the same conversation over and over again with no real progress? Do you ever feel like you are stuck in a disagreement and not sure how to move forward?

If any of these issues are standing in the way of your work with groups and teams ‐ ‘how’ you are having (or not having) the conversation is likely contributing to your challenges. Research consistently demonstrates that team effectiveness is highly dependent upon the quality of the communication between team members. Yet it’s easy to get into the flow of daily work and be really focused on the ‘what’ in our conversations without much attention to the quality of ‘how’ we’re communicating.

As an agile coach one of the most important ways you can serve your team is to help them unlock the wisdom that exists within the team itself and have the conversations they need to have. We’ll explore a framework for learning to ‘read the room’ using four elements for all face-to-face communication. We’ll do some live practice to apply the framework to a conversation and then identify some typical patterns of “stuck” communications that can lead to “breakdowns” in teams.

This will be an interactive session with people actively engaged in both large group and small group discussions.

Gain insights and learn real-world strategies and techniques for leading an enterprise or divisional Agile transformation.  Based on current experiences driving Fannie Mae's enterprise Agile transformation, and drawing upon years of experience leading Agile transformations in multiple divisions at Capital One, Mr. Richardson will share proven methods and approaches for leading a successful Agile transformation.  This session is aimed at senior leaders, executives, and management. 

Via a dynamic presentation and lively participant dialog, we will cover in depth topics such as:

• Assessing your organization's strengths and opportunities re: Agile adoption at all levels in the organization
• Key elements of a successful Agile transformation plan & execution of that plan
• Engagement strategies for teams, middle management, and executive leadership
• Techniques for lighting a fire with Agile enterprise-wide
• The appropriate roles of delivery leaders, Circles of Excellence, User Groups, PMOs, etc.
• Maintaining Agile discipline in the face of organizational friction
• Dealing effectively with many varieties of change resistance specific to Agile transformations

Additionally, we will cover advanced enterprise topics such as:

• Enterprise investment management and new techniques for an increasingly Agile portfolio
• Refinements to Procurement approaches to enable Agile
• Structural elements in large organizations that must be addressed for an Agile transformation to have staying power

When design is based on random choices, the end product is an assembly of random elements that have little or nothing in common. But when design forces all elements to work together then it makes a single, powerful, and meaningful impression to the user. While agile can get the job done faster, it doesn’t help guide design choices for a software product.    

This session presents a design driven approach called Strong Center Design that incorporates design into an agile workflow.

If you have an interest in improving design of your software products, then this is the session for you.

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.

The Zombie Retrospective - presented by Tommie Adams 

So they say the retrospective is one of the strongest and most powerful tools in the agile scrum methodology tool kit, and is often overlooked or skipped. So how does a scrum master find ways to creatively explain and express the importance of this agile scrum ceremony, or even the basics of agile scrum in general. How does the scrum master explain the importance of banding together as a team in this brave new agile scrum world.  In many organizations, nowadays, the teams are even made up of outside vendors as well as in house associates. So how do you even start to pique the interest and the importance of team collaboration to a bunch of folks who are strangers to one another on a agile scrum team?  Even more specifically, how do you explain how the retrospective ceremony will help improve the way they work with one another over time?

My answer: ZOMBIES!!!  Everyone loves zombies, right?  So come, take a bite!

Tommie works for Marriott International in Bethesda MD. His background is in theater and communication which he studied at Grinnell College in Iowa. He has worked for Marriott International for 26 years with jobs ranging from reservation sales associate, to group sales manager, to functional IT tester to his current position as scrum master for the Marriott Rewards Agile Scrum Team. A native of Omaha, Nebraska, his hobbies include photography, cello and learning the ukulele, (you know, in case you were curious.) 

“Running a football team is no different than running any other kind of organization…” -- Vince Lombardi

Large enterprise scale software development is a team sport. In order to win in this game your software needs to be of the highest quality, which is almost impossible to achieve with testers on the sidelines. To build a winning a team you need the right players, but great teams don't always need the best players. Great teams win because they find ways to let the individuals on their team be great. 

The wave of DevOps in the industry is in a broader sense an effort to let developers and system engineers do what they do best by eliminating or simplifying tasks that forced individuals into activities beyond their expertise. Pre-DevOps roles were like trying to ask Payton Manning to play both quarterback and running back at the same time. DevOps is the manifestation of empathy between two distinct sets of skills allowing the other to focus on what their best at. What about testers? How can the team expand their empathy to their role? What can the developers, program managers, and others do to let testers be great? Please join me if your curious to hear about the practices, tools, and culture that can make your software a winner with quality.