2019 will be the year of Big Agile, where large adopters like General Motors, the Department of Defense, the State of Michigan, Lockheed Martin, and others, who have combined IT budgets exceeding 100 Billion dollars, have all announced their desire to “go agile” at a scale not yet seen in our community. Are technology leaders who cut their teeth in a low-trust, command-and-control, high-documentation environment prepared to make a successful transformation? What will Big Agile look like, and how will it affect the rest of the community?

This will be our industry’s biggest challenge, and I've been studying it for years. As the large adopters in the federal government and corporate sector begin to adopt agile, they’ll bring their habits, culture, and bureaucracies with them, and they need to get in front of the wave.

One of the things I like about AgileDC is that I see a lot of familiar faces. Not just familiar from previous AgileDC events, but from other Agile events in town, other conferences, Meetups and such. I also go to local DevOps events, and I see familiar faces there too, but I don't observe much overlap between the two. In this talk I will discuss whether this division is real, or perhaps just a figment of my imagination, whether we as an Agile community should care, and what we should do about it.

How do you get people to agree on priorities when they may have different objectives? You may be facing an issue now where stakeholders are pushing against each other in order to get their work done first. What would happen if we could create an open dialog among stakeholders and have them understand different perspectives and focus on the goals of the greater good instead of just their own? Let’s face it, proper prioritization is the difference between writing code and developing valuable solutions.

In this simulation style workshop, you’ll learn practical methods for bringing stakeholders together and openly discuss their different priorities to agree on what’s most important overall. You will see first hand how a combining group discussion with proven prioritization methods such as Weighted-Shortest Job First and (WSJF) and Must Have, Should Have, Could Have and Won’t Have (MoSCoW) work.

Presentation Overview: (What is the “message”? What key points will you make?)

Change is hard – Staying motivated during change is even harder! But you can help your teams identify what things about the change are working for them and what they need to do to make small shifts that can keep them motivated.

Is your team or team member facing a big change decision? Moving Motivators can help you identify the best choice by looking at how the factors in the change impact your long term motivation.

Learn to discover and prioritize your motivators so you will understand how change today might impact you in the long run. See which choice is better when there are multiple options. Make conscious trade off decisions in a logical way with long term thinking in mind.

DevOps can help you dig out of the problem you created for yourself: you spent your lunch period reading the interwebs, drank the kool-aid, and decided to embrace the utopia of microservices to solve all your fragile legacy monolithic code issues and allow you to release small independent changes into production. What you didn't realize is that you've translated an early-lifecycle code architecture problem into a late-lifecycle release management and quality assessment nightmare.

This microservice thing has not provided the nirvana you expected. You ended up with:

• a set of federated services that have hidden dependencies
• independent applications maintained by teams that don't talk to each other
• inability figure out which versions work together in your test environments, much less production
• the need to test that your still-monolithic system works in pieces and as a whole

You discover that this looks suspiciously like a DevOps problem and your pipeline is critical to your success.

Someone once said to me "if you are building microservices without DevOps, you've already failed." I've learned that the integration problems created by independent microservices require a high level of automation with a pipeline that works independently of each service and can detect changes that break other services. The pipeline needs to facilitate communication between teams and assess which changes and versions work with each other.

In this talk, I highlight the important things you need to succeed with microservices and avoid some of the common problems. Participants will leave with some new ideas on what they might be doing wrong in their current microservice-based project and/or anticipate what's going to go wrong if they are just getting started.

Government Agile transformations can feel like overwhelming efforts – but do not abandon hope! This interactive, audience-driven presentation reviews how government and large organizations ESCAPE common Agile adoption challenges.
You - the audience - will prioritize your pain points; we’ll focus on the five Agile hells most highly prioritized. We will discuss real examples of “escaping” out of each Agile hell, with pro tips and success patterns you can apply.
The Agile hells we've escaped include:

• No Transformation hell - A federal program or department wants to change but can’t start or can’t finish
• Too Fast hell - Newly Agile federal programs sometimes respond TOO rapidly, too often changing priorities.
• Technical hell - Programs can become bogged down in technical debt and manual processes.
• No Trust hell - Government delivery can be slowed by lack of trust between contractors and feds, between business and IT, or between compliance and delivery groups.
• Product Owners hell - Government Product Owners can be unavailable, think they are managers, aren’t empowered to provide vision, or struggle with prioritization
• Too Big hell- A frequent pattern in federal Agile! Large batches produce slow progress, low visibility and high complexity, seen in big programs, big deployments, and big contracts.
• Collaboration hell - Government teams can struggle with collaboration within the same organization across roles and across the fed-contractor divide.
• Stove-piped hell - Government organizations can struggle to collaborate across contractual or organizational boundaries within the same enterprise
• Leadership hell - An organization can only be as agile as its leadership. In the government, how can you work with leaders who aren't ready to be agile?

For each Agile hell, we focus on successful techniques to escape from these common dynamics. Unlike other presentations, we won't be doing a deep dive, but we will cover the most important challenges our audience face.

The talk walks through lessons learned from a specific government project, jumping head-first into agile, open source, and (oh dear) the cloud. In the jet plane metaphor, it's not about the theory of why a plane should fly (as a physicist), but about the big and little forces that will act on it in practice (as a test pilot).

Do you work on programs requiring collaboration of 30 people or more? Have you heard of Scrum@Scale? While many people have heard of SAFe, far fewer are familiar with Scrum@Scale. Did you know Scrum@Scale was built by Jeff Sutherland, the co-creator of Scrum? And that the very first scaled Scrum project began in 1983?

Come learn about Scrum@Scale, where it is being used, and why it may be a better fit for your organization than other scaling methodologies. I am both a SAFe and Scrum@Scale practitioner and trainer, and will provide a balanced comparison with pros / cons.

Kubernetes married with a cloud provider elastic, highly available infrastructure. Many CI engines today (Jenkins, Bamboo, Gitlab, CircleCI), provide native integration with kubernetes so that your build and deploy workload can be elastically executed. This allows your pipeline to meet the needs of your schedule, be it the 4pm pile on to commit code before going home, the mad rush to get a hot fix to production, or the surge of an unexpected customer ask. Gone are the days of the build queue growing and you CI engine collapsing under the weight of a hundred build requests. In order for a pipeline to leverage this capacity changes must be made to the pipeline architecture. Tools must be dockerized, the ephemeral nature of running docker must be considered, kubernetes specifications or helm charts must be generated for the application, automated testing must be adapted to work in the new architecture, and then there is the database. Each one of these issues, plus many others I’ve missed contained unfortunate, unforeseen pitfalls that translated in schedule delays. Join Glenn as he helps you short circuit the pitfalls of migrating to kubernetes off of your static in-elastic virtual infrastructure.

What happens when 25 product owners, developers, and quality engineers reflect on their previous sprint through the eyes of a child?

Playdoh took my teams, remote and collocated, from showing up to an obligatory meeting on their calendar to intentional interpersonal and intrapersonal dialogue.

Between the carpet and the sticky fingers, adults are usually cleaning up more Playdoh than playing with it themselves. Even to my own surprise, in this “Play Retro,” our team members connected, not only on a professional, but also on a personal level in ways they had not done before.

This session will give an overview of our experience using a “Play Retro” and leave you with tips and things to consider planning a retrospective.

Exhaustion. Numbness. Emptiness. As Agilists, all too often we are seeing teams, organizations, and people that have been transforming for a very long time, and many feel like they have no end in site. Where they were first excited about transformation and trying something new, they are now wanting to be left alone for a hot minute. Transformation isn't something to be completed but rather endured.

In this session, Erin and Yogita will help you to understand what transformation exhaustion is and how to recognize it. We'll also help you to develop--and practice!--ways to show teams their transformation progress as well as how to connect and reconnect with teams. You may have entered the session tired and footsore, but you will leave with new ideas and insight on how to transform your agile transformation.

The federal government, and many local governments, have embraced agile. This has been helpful in terms of incremental progress for the "how" of building software.

However, it's not enough.

The next big shift is when government agencies lift their focus from IT project delivery to digital product management - focusing on the "what" should be built and "why" it should be built. Such a shift will move agencies from incremental progress in delivering mission value to a ground-breaking shift in how missions are supported via technology.