Studies over the last two decades have shown change initiatives have a high rate of failure to meet expected outcomes, yet traditional change management approaches continue to apply a sequential, step-by-step process in constantly changing environments.   An underlying assumption for these approaches seems to be that the desired end-state is assured, as long as the steps are followed.

Successful change initiatives in today’s environment will view the “wicked problem” of complex change through an empirical framework based on proven concepts from Organization Development (OD), augmented with tools and techniques from additional disciplines such as Lean, Agile, and Human Systems Dynamics (HSD) to influence changes in thinking and behaving.

This interactive session includes:

• Overview of the OD approach to organization change
• Introduction of a Change Spectrum for visualizing organization change
• Introduction of an Empirical Framework for designing and implementing change initiatives
• Introduction and Overview of a few specific diagnostic models from OD, Human Systems Dynamics, and Integral Agile
• Overview and discussion of a few specific tools and techniques that help shift thinking and behavior

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.

Do you find your work exciting and fulfilling? Is your team rewarded for finding better ways to work? While many organizations have adopted Agile approaches at a project level, few have effectively aligned their HR processes with Agile values, or made finding better ways of working a truly rewarding and exciting proposition for their teams. With a new generation of employees who are interested equally in purpose as in profit, it is imperative that we revisit schemes like the 360⁰ annual review, and recognize not only their limitations, but also the damage they cause to individual morale and team productivity.

Join Sanjiv to explore the subject of creating a holistic performance management system that not only adheres to Agile principles, but actively promotes individual drive and team innovation. Learn how delink merit pay from feedback, the difference between intrinsic and extrinsic motivation; and how to create a “flow state” on your agile teams to enhance performance and spark innovation.

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. 

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.

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.

In the agile community, we celebrate failure as well as success. On our journey to plan @ scale, the Agile Program Management team at Opower had a lot of early failures, but then we started succeeding. How? By not only listening to our stakeholders, but co-creating solutions with them. In this talk, I focus on how process co-creation is helping Opower scale. I’ll describe a specific case study, then we’ll try co-creation together. By the end of this talk, you’ll have specific tips and techniques on how to successfully co-create solutions with your teams that you can take back and use with them tomorrow.

The government is seeing the merit of using agile practices to develop software.  However, the fallacy that you can’t estimate projects using agile in the government still exist.  The result is that many projects that want to use Agile begin in a very waterfall way developing the initial plan and are forced to stick to that plan throughout the project despite using sprints throughout the ‘development phase’.  Many falsely believe they are stuck in the tradition of estimating everything in the beginning.  During this presentation, through lecture and based upon real experiences, we will demonstrate techniques for developing a project plan and estimating techniques to satisfy the typical government compliance requirements using Agile practices and principles.  In essence, we will together learn how to build the bridge from the traditional government practices to a brave new world where we can plan, estimate and still inject agility.

What do the commercial world and Federal government share in common? Agile success! Yes, it is true that agile grew from the commercial world and has been a shining story of success there, but the Federal government has been adopting agile’s brilliant ways more recently and has success stories of its own to share.

In getting to the point of successful agile delivery, especially at the organizational level, the Federal government has had to clear many hurdles and transform the way it works. This hasn’t been an easy task and is still in its infancy. The commercial world has cleared its share as well and has many war stories along with their success stories.

This session will be delivered as a moderated panel discussion. Two panelists from progressive Federal programs join two shining examples of agility from the commercial space – and entertaining fellows to boot.  Panelists will discuss topics that provide insight into their organizations and the work they did to implement agile successfully on their teams, across their programs, and throughout their organizations.

• Alastair Thomson is the Chief Information Officer for NIH’s National Heart, Lung, and Blood Institute
• Joshua Seckel is the Applied Technology Division Chief at the USCIS Office of Information Technology
• Nate McMahon is a Vice President of People and Technology at The Motley Fool
• Bob Payne is the Vice President of Enterprise Agile Consulting at LitheSpeed

Ever wonder if a major Federal program has been able to achieve Continuous Delivery or implement a Zero Defects strategy? How have the commercial companies been able to increase their output so well while decreasing risk at the same time? What can Federal organizations learn from the commercial world about agile contracting and procurements? How did commercial companies have to change to enable self-forming teams and could our Federal government, with its myriad contractors and its layers of separation, benefit from the same? What can the commercial world learn from Federal agile success? Do successful agile approaches differ between products and services? What do the Feds see as their next agile conquest on the horizon? What is hot for commercial companies to tackle now?

You will leave this session understanding some of what the commercial world has done to achieve great success with agile. You will also hear about agile success in the Federal government, bureaucracy busting moves, and what the government had to do in order to achieve those feats. Both sides will share their stories, describing the impediments they faced, the benefits they have seen, and even the areas they have not been able to conquer just yet, attempting to drive agile throughout their organizations and into every aspect of their delivery. Panelists will also discuss topics and answer questions the session participants have for them to ensure everyone has an opportunity to take back valuable and pertinent knowledge afforded by these experienced agilists.

When you transitioned to Agile you solicited the best advice, updated your development tools, hired coaches, installed furniture, and embraced painful cultural changes. Now, a few years later, you wonder whether Agile is working. Are you realizing the productivity you are paying for, or did Agile flop? With so many people developing software every day you expect more to get done. Your advisors tell you not to worry about productivity, this is how it’s supposed to be. Questioning themselves, many executives are awakening to these gut feelings of disillusionment in their post-transition organizations. How much productivity should they expect from Agile teams? How do you know if Agile is working? Can Agile organizations be slow and unwieldy despite their Agileness? This session offers a strategic business management perspective about the honest reality of Agile in a post-transition organization. Attendees will learn to recognize the signals of poor Agile productivity and how to fix development so it stays fixed.

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.

Delivery teams know from experience the importance of maintenance such as applying patches, upgrading, and conforming to the latest security and accessibility regulations. Product Owners, other value team members, and system stakeholders are focused on functionality and end user satisfaction. Maintenance isn’t sexy and can sink in priority until it fails to be included in releases.

The Security community has been using Dark/Abuser/Evil Stories using the persona of a Black Hat Hacker to uncover vulnerabilities. In this workshop participants will assume the role of Delivery Team members and use the power of personas to write “Dark Stories” that bring to life the full impact of failing to perform necessary maintenance.  The intent is to give Product Owners a complete understanding of the importance of maintenance so they can appropriately prioritize maintenance and keep their systems strong.

FeatureBan is a simple and quick simulation that introduces several of the key concepts of Kanban, including visualization, feedback loops and limiting work in process and that lets participants learn by doing.  The simulation is also useful because it lets organizations who are curious about Kanban quickly learn about it before investing further.  Mike Burrows invented the simulation, but in this session we will present a modified version that we have used with both technical and non-technical audiences.

Like in Horseshoes and Hand Grenades, being close in Agile has great value.  We need not abandon our brethren in the trenches just because some of the most recognizable practices are out of play.  The great principles of Agile help in even the most difficult environments.  Shipping great software while under some traditional constraints is a true test of the movement – and we have a track record of doing just that.  We have employed Stealth Agile, Green Box Agile, Cafeteria Agile, Agile Pathfinding, and even Agile Treason in order to deliver in less than ideal circumstances.

A series of actual scenarios will reveal the adaptations to Agile practices that kept us close to principles.  A small set of practices are present in so many of our projects that we consider them to be part of our Agile core.  Sometimes we rename them, sometimes we feather them, sometimes we disguise them, but they are always present and are pivotal to success.  Chief among these are the various practices that enable and encourage rapid feedback at multiple levels including Customer, Product, System, and Development.

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

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.

The many trivial testing and refactoring examples available on the web are difficult for developers to apply to real-world code bases. As a result, many "new to agile" developers don't attempt to apply tests or refactorings to legacy code, reserving these techniques for the ever elusive greenfield project.
To help developers with this dilemma, this session will walk through a real legacy Java code base, and go through the steps required to bring the code under test & begin to perform useful refactorings. All of this will be done under the guidance of the principles of Simple Design.

Are you overwhelmed and/or confused as to which metrics can reveal insights to make fact-based decisions to properly manage your agile software development portfolio.  Join us for a the story of a journey, where we will use the metaphor of “going on a road trip” to explain and demonstrate simple yet effective metrics for agile portfolio management.  As we go on our road trip, we’ll highlight the importance of defining and then using quantitative “roll-up” metrics to enable leadership to make informed strategic decisions without slowing delivery team activities while at the same time providing a foundation for team self-management and autonomy.  We’ll use the road-trip metaphor to depict the challenges that teams and organizations encounter attempting to manage their portfolio without effective portfolio metrics defined.  Think about what driving on a road trip would be like if your car didn’t have a check-engine light or a gas gauge, sound risky???  The good news is: it doesn’t have to be that way, and believe it or not, if you have measurements at the team level creating actionable portfolio-metrics is easier than you think.  As we recommend simple portfolio-level metrics to guide our road trip, we’ll define them, share how to interpret them, discuss the insights they provide, and offer guidance on how to gather or aggregate them from team execution data.  We will also touch on why and how the use of an easy to understand metaphor has aided significantly in creating and sustaining engagement amongst stakeholders for portfolio inception and governance activities.  Participants will leave having learned how to successfully navigate their next enterprise-wide initiative using quantitative data to promote alignment, maximize return on investment, foster engagement and reduce risk - everyone attending will receive a printed guide (worksheet) summarizing recommended metrics for agile portfolio management discussed.

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

All Not for Profits aspire to be effective, nimble, and fun all while changing the world. Agile mindsets and practices can help all nonprofit organizations use technology agile concepts skillfully and confidently to meet community needs and fulfill their missions.

Successfully implementing and fully adopting agile can be seen as unnecessary overhead.  Creating an Agile community and toolbox for Not for Profits would greatly reduce the organization change costs and allow not for profits to benefit faster.  This community would facilitate the exchange of knowledge and information within the agile community and within the Not for Profit sector. It would connect members to each other, provide professional development opportunities, educate our constituency on issues of technology use in nonprofits, and spearhead groundbreaking research, advocacy, and education on technology issues affecting our entire community.

Most scrum teams create effort estimates, often using story points. As a product owner, you also want to have an estimate of the business value of each user story. Business value estimates help you create a more rational backlog and maximize the value the team delivers.

This workshop explores the art and science of estimating the business value of user stories. Participants will gain an understanding of the essence of business value,
and why it is more complex than just revenue or profit. Then we will then learn a surprisingly simple technique to estimate and quantify business value.

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.

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.

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?

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.

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

"Language does not just describe reality. Language creates the reality it describes." - Desmond Tutu

The agile community has evolved into a group of highly enthusiastic proponents who bring a high level of excitement to everything they say and do. Agilists speak a strange sort of insider jargon in which plain English words have very unusual, and often counterintuitive meanings.

They may describe your multi-billion-dollar enterprise as "dysfunctional" and on the verge of "failure." They may suggest your teams "sprint" to get work done, and yet do so at a "sustainable pace." They may tell your management that agile helps teams "go faster" while assuring your teams that agile isn't about "going faster." They may insist that agile is more about culture and mindset than about practices, and then measure your progress in terms of how faithfully you follow a prescribed set of practices.

There are many more examples of this odd insider jargon, starting with the seminal buzzword itself, "agile." Over the years, the way agilists speak has confused and turned off many who might otherwise have benefited from applying agile values and principles. The presenter will share several stories of the unintended effects of agile-speak, and will invite you to share your own tales of woe and amusement.

One goal of release planning is to ensure dependencies among teams are identified, common issues are addressed and people are committed within teams and among teams.

 One team using Scrum release planning consists of keeping a prioritized backlog, tracking the team velocity.  When up to 3 or 4 teams are working on related backlogs, comparing and coordinating backlogs are effective.  

 Somewhere around 4 to 5 teams working on related backlogs, a more structured approach such as Scaled Agile Framework (SAFe) Program Increment (PI) planning provided a structured framework to coordinate among teams.  SAFe PI planning facilitates conversations and coordination across teams.  However, product owners are not necessarily interested in architecture updates.  Also, conversations between two teams may apply to more than two teams if only the other teams.

 Open Space Technology (OST) provides a facilitation framework where participants generate the agenda on the fly.  Generating the agenda with all participants ensures that topics that the meeting organizers were not aware of are discussed among relevant team members.  A public agenda ensures that all interested enough to attend the breakout sessions have a say in the program direction.  Proceedings ensure that all have access to what was discussed, and provide guidance of who to talk to after planning about the subjects with questions.  However, OST by itself does not ensure a release plan will come out of the meeting.

 The best release planning sessions I have held so far combine SAFe PI planning structure with OST.  Combining the techniques was an immediate improvement over using only SAFe PI planning.  The planning session came out with sprint goals, identified dependencies and proceedings from breakout sessions.  This session will point out what has and has not worked so far, identify areas for improvement, and is a call for experiences beyond my own using this technique.

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.

Your Agile Stand-up Meeting Sucks!

Most Agile and Scrum stand-up meetings I see are boring, lifeless, status meetings that don't provide any real value.

In this session you'll learn:

The REAL purpose of the daily stand-up

The most common bad habits and how to correct them

The habits good stand-up meetings have

How you can use Improv to invigorate your daily stand-up

A whole bunch of Improv exercises you can start using with your team right now!

More and more organizations and teams are adopting Agile, however most stay focused on just the development part. They maintain a Big Upfront Requirements/Design (BRUF) phase and still have a long test and deployment phase. This approach results in more of a mini-waterfall approach rather than an Agile approach where we actually place valuable products in our customers’ hands. The old risks and pain points are still there: are we building the right thing? Is it valuable and usable? Does it work? So the true benefits of an Agile approach in terms of quality valuable products and higher ROI is never achieved due to our long cycles and slow feedback loops. Come to this session to see how Lean Discovery and Agile Delivery combined with a DevOps mindset, can make actual delivery of customer value sustainable. We will look at how Lean Discovery replaces BRUF and ensures the team is constantly building the right thing. We will also see how applying Agile Engineering practices ensure that the team is building the thing right and how a DevOps mindset ensures that the product the team builds actually gets delivered to the customer early and often.

Teal is a natural extension of the Agile mindset, but who would have thought flattening the hierarchy could be this difficult! If Agile removes impediments and empowers teams to deliver more frequently and more valuable offerings, teal removes organizational impediments (hierarchy built on lack of trust ) and fosters empowerment by localizing decision making, re-centering activities around an evolutionary purpose, and aligning the personal with the organizational (wholeness). But what actually happens when you put rubber to road and empower teams to recruit, hire, fire, and determine each other’s bonuses? Well, things get a little messy. If you’re patient, set aside short-term outcomes, and look to long-term gain, it can prove deeply rewarding. I’ll take you on our own evolutionary journey from green to teal and share with you lessons learned along the way.

If you’re curious about alternative management styles or interested in the next extension of Agile, then come sit, chat, and reflect.

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.

Most agile teams focus on following a delivery process and overlook finding ways to improve the process. The essence of agile is focused around the idea of continuous improvement via inspect and adapt. In this session, we will be providing insights around evolving your measurements using data in order to embrace a different mindset. A mindset that encourages more facts and less judgment. A mindset that encourages organizations to move from “performance” to decisions, behaviors, outcomes, external evaluation to “Let’s figure this out together”, proof to evidence, answers to questions, precision to speed and from objective to subjective (but with lots of facts!)

“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.”

We all know that a Minimum Viable Product is a lean startup technique designed to test and validate if a solution actually solves a customer problem. It is an endeavor to go forth and learn  to then, iterate or pivot as you better understand the problem and solution.  To be successful, it is not only  about learning what the people want but also being able understand the most painful aspects of that problem to then define what is the minimum amount of work you can do to generate early value to them.  But how do we figure that out?  In this 45-minute workshop, you will learn what is an MVP;  why it matters; what makes a good MVP experiment; and how to get started on designing your own. By the end of this 45-minute workshop, you will have:

1. Created a problem statement, or hypothesis for an MVP
2. Turned your hypothesis into a list of possible experiments
3. Collaborated with agilists who will help you formulate your MVP concept and experimentation ideas

Our project was suffering from a series of unfortunate events; it was behind schedule, over budget, re-baselined twice and nearly cancelled. The PM and one third of the staff was gone. Needless to say **we did not have a trusting relationship with our client or their other contractors.** We knew for sure we could no longer conduct business as usual.

We had to convince our government partners that they did not make a mistake in trusting us. Agile had to rebuild relationships, knock down barriers, and produce quick results.

In our case we are government contractors to the United States DoD, working with other contractors (competitors), in an environment that was heavyweight and plan driven. We used agile to drive trust and transparency, which led to collaboration and real results.

If we made agile work you can too!

This exciting workshop includes case study interspersed with frequent exercises and discussion so that you can take what we learned and apply it in your context.

As a business analyst on an agile team, do you spend your time gathering decisions from product owners and passing them on to development teams? Are you tired of simply being a “proxy without power?” As a product manager, do you feel like you are just collecting stakeholder opinions and filtering them for the team? What can you do to boost your impact to your team?

Be more than a proxy.

By definition, a proxy means doing a thing “by the authority to represent someone else.” That job can be important, especially when stakeholders and customers have limited available. But teams need more.

In this workshop, Diane Zajac-Woodie demonstrates how you can be more than a proxy. Through some experiential exercises, you will learn what impact collaboration has on results and why requirements are just as important as ever. Diane also teaches you how to document requirements so people will actually read them. Using acceptance tests, you will practice writing requirements that describe the exact behaviors that you expect in a format that everyone understands.

Be inspired to embrace your role in an agile environment and leave with new techniques that ensure that you will be more than a proxy when you head back to work.

Clarabridge is a commercial software company headquartered in Reston, VA.  We have 8 scrum teams, almost all of which have members on two or more continents and some of which span up to 10 time zones.  This has created challenges that we have addressed in a variety of ways over time.  In this talk, we'll discuss the evolution of our methods for running distributed scrum teams and share what has worked well and what hasn't.

Why does the Agile community encourage cross-functional teams?  So many large organizations have naturally organized into system-specific teams.  This is a very common and logical approach.  At scale, though, it creates serious impediments to organizational agility and getting things done.  We'll discuss the roots of that phenomenon, one of our key interests in cross-functional teams, patterns for enabling such a team structure, some failure modes, and how to prevent them.  Please join us!

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.

There are many levels of estimation, including budgeting, high-level estimation and task planning (detailed estimation).  We can link a more classic view of estimation to  the Agile planning onion popularized by Mike Cohn.   In the Agile planning onion, strategic planning is on the outside of the onion and the planning that occurs in the daily sprint meetings is at the core of the onion. Each layer closer to the core relates more to the day-to-day activity of a team. The #NoEstimates movement eschew developing story- or task-level estimates and sometimes higher levels of estimation. As you get closer to the core of the planning onion the case for the#NoEstimates becomes more compelling and dare I say useful. 

This presentation focuses on challenging the attendee to consider estimation as a form of planning. Planning is a considered an important competency in most business environments. Planning activities abound whether planning the corporate picnic to planning the acquisition and implementation of a new customer relationship management system. Most planning activities center on answering a few very basic questions. When will “it” be done? How much will “it” cost? What is “it” that I will actually get? As an organization or team progresses through the planning onion, the need for effort and cost estimation lessens in most cases. #NoEstimation does not remove the need for all types of estimates. Most organizations will always need to estimate in order to budget. Organizations that have stable teams, adopt the Agile mindset and have a well-groomed backlog will be able to use predictable flow to forecast rather than effort and cost estimation. At a sprint or day-to-day level Agile teams that predictably deliver value can embrace the idea of #NoEstimate while answering the basic questions based what, when and how much based on performance.

This unique journey will transport you deep inside the world of the General Services Administration (GSA) Integrated Award Environment (IAE).  You will see how user-centered Agile is transforming the way software applications are engineered, how users' voices have been integrated with large-scale Agile development, and what issues we encountered along the way.

When Eric Schmidt, former CEO of Google, predicted, "Everything in the future online is going to look like a multiplayer game," perhaps he was envisioning a user community such as ours.  The IAE family of software applications have more than a million users representing federal, state, local, and tribal government organizations; congressional staff; large and small businesses; universities, schools, and hospitals; non-profit organizations; foreign entities; private citizens and others.  Our greatest challenge is the diversity of our user base, resembling a massive multiplayer game in many ways. 

This case study looks inside a major reengineering effort to migrate 10 legacy applications into an integrated environment while at the same time transitioning from Waterfall to Agile development.  It tells the story of how IAE users have shaped our transformation thus far.  

We often talk about what the Product Owner Must "Do" - they must own the Product Backlog, they must manage the product backlog and the priorities, they must refine the backlog, they must answer the team's questions.

We very rarely talk about what the Product Owner must "Be".

During this session I will highlight what I have learned from my experience as a Product Owner and a Product Owner coach, what I believe are the main Must "Be's" for a Product Owner.

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

If you are looking for a recipe (pun intended) for success, then this session will disappoint you.  For, a tool by itself will not change anything, but how a tool is used can help foster changes in behavior, which is key to organizational transformation.  

 So, what is DevOps? Is it just hype? How does it help organizations deliver value to their customers? If these questions are on your mind then this session is for you. While simply a constriction of two terms, "devops" is in essence a stub for broader organizational collaboration and feedback beyond just that of development and operations working together.  It emerged as a grass-roots movement at the confluence of two rising trends - agile development and large-scale cloud infrastructure.  And, like any horizontal revolution, devops is a path of discovery - people and processes do not change overnight.  Agility in coding and agility in systems takes time and effort, but the results can be astonishing.  The feedback and feed-forward loops that devops advocates makes the whole difference in quality and results, while the sharing and close collaboration pierces the veil among organizational silos, blurring their delineating lines. 

 In this session targeted towards beginners, we will explore these ideas and principles, framing our conversation within the context of the nascent and evolving CALMS framework and look at what it means to extend  "traditional agile" principles beyond the boundaries of the code to the entire delivered service.  After-all, isn't the principal Agile credo about satisfying the customer through early and continuous delivery of valuable software?