Outline:

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.

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.

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.

As Agile coaches engage in enterprise transformations, there is a common theme among the organizational barriers and impediments seen across most clients. Oftentimes going into new account, organization, or team, it seems like a bit of déjà vu with the type of issues seen, despite how unique each company describes themselves. Usually through some sort of an assessment or an inspect and adapt, the clients all seem to have similar cultural, organizational, environmental, or personnel issues impacting their transformation. While every account does have a unique piece to it and our approach to these common issues can be somewhat standardized, coaches really show value by providing the best solution to their situation.

Some common areas encountered include:

• Annual project and funding approval process
• Lack of visibility into work going on at the enterprise level
• A disconnect between strategy and the actual work being executed
• Culture of fear causing lack of transparency

This lightning talk will review a couple of these impediments, define them, and show how a coach can address and move through them. It’s incumbent upon coaches to help the client understand that these impediments aren’t insurmountable, they just need to be tackled piece by piece. Value can be added in both small and big chunks, but coaches need to ensure they're doing that continuously and pragmatically.

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.

Most government agencies are becoming 'agile'. A few are actually diving in to focus on frequent delivery of software that creates business value. This is not about 'agile' the easy way - implementing a few ceremonies, titles, and buying a software package, then declaring victory. This is about agile the hard way - the stubbed toes and small victories that open the door to lasting change.

The talk walks through lessons learned from a specific government project, jumping head-first into agile, open source, and (oh dear) the cloud.

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.

How much time do you spend working on your masterpiece: Everything that is you, mind, body, and soul?

Over the past year, the need to work on our masterpieces, via self-care, has emerged. This is easier said than done. If you’re like me, it’s difficult to find the right balance between focusing on others and prioritizing yourself.

I’ve come to realize that self-care is a journey, not a destination! A grand gesture, like a long, relaxing vacation is nice, but the benefits are temporary. I’ve found that making small steps, regularly, towards self-care is an effective way for me to work on my masterpiece.

In this workshop, I’ll share with you a continuous improvement approach to self-care. You will not only learn the steps, but you’ll begin your self-care journey with hands-on practice, both individually and in groups.

Remember, all journeys are different, and bound to have peaks and valleys. In this workshop, you will learn and practice techniques to handle the ups and downs along the way.

If you are ready to work on your masterpiece, don’t miss this workshop. You’ll learn everything needed to proudly exclaim “I’m still working on my masterpiece!”

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.