Historically, Project Managers (PMs) and other middle managers have hustled in a bureaucratic system to drive teams to deliver value. As organizations transition from a project to product model, where can these leaders best add value in a fast-moving, Agile and entrepreneurial world? In this new and exciting world, middle managers are enabling rapid delivery of value and successful business outcomes via the creation of the Agile Value Management Office™. Learn how an Agile VMO™ drives business agility through small batches, frequent releases, and continuous adaptation. We'll explore how to:

• Create a collaborative management team-of-teams
• Bring Lean discipline to product portfolio prioritization
• Establish an End-to-End team model of resource management
• Track in-flight product work using a Visual Management System

We'll explore the transition for PMs and other leaders into this exciting role: facilitating the delivery of flow, value, and innovation end-to-end on the Agile VMO™, even as they support their Agile teams in the quest for business agility.

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.

One of the key advantages of Agile over plan-driven approaches is that an Agile mindset acknowledges our ever-diminishing ability to usefully predict the future and focuses our efforts on managing change instead of trying to suppress it. This “new reality” has become pervasive enough to drive its own buzz word – VUCA, which stands for Volatility, Uncertainty, Complexity, Ambiguity. But beyond the hype lies a truth that Agile leaders need to understand and embrace – that certain problems really do respond differently to our attempts to manage and solve them. Why does this matter? Because problem contexts that defy straightforward cause-and-effect expectations significantly impact productivity while simultaneously presenting much higher risks to success. Even worse, applying leadership approaches that aren’t matched to the problem context dramatically increases the danger of catastrophic failure.

In this session, we’ll examine how the Cynefin framework helps us make sense of what kinds of problems we’re dealing with and how we should approach them. We will then look at ten ways in which Agile frameworks, approaches and technical practices help us manage or even reduce complexity and one where they fall short. You will walk away with a deeper understanding of how - and why - the things we do as agilists increase stability and reduce risks for our teams.

People don't like being told what to do, especially knowledge workers. Yet in many work settings we give feedback that is directive in nature. What would it be like to receive feedback that, instead of making us ashamed of our failures, helped us to learn and grow? What would it be like to give feedback that enabled deep and sustained learning and growth in another person, while still being perfectly honest?

During this talk you will learn about Developmental Feedback, which enables the giver of the feedback to be clear and speak truth, and enables the receiver of the feedback to absorb it without defensiveness, and with a sense of invitation to learn and grow. You will learn about a variety of feedback types, how to have a "shared sensemaking conversation," what Impact Feedback and "The Story I Tell Myself" feedback actually are, and review sample dialogues. We will explore the conditions necessary for effective developmental feedback conversations, such as psychological safety and timeliness. You will emerge with a practical tool you can use with anyone (not just at work) to speak your truth while respecting the other person’s humanity, leading to lasting change and deeper relationships.

CMMI and agile haven't shared many beers at the bar over the years. But there is no reason they shouldn’t be best of friends. They both long for continuous improvement, creating learning organizations that strive to reduce risk and increase quality. I believe that a major cause of dissonance is the lack of perceived value in the way the CMMI models have been applied and appraisals performed in the past.

So, what would it look like to implement CMMI and prepare for an appraisal focusing all of our effort into creating value and removing waste, instead of adding it? That was the question we tackled this past year and are seeing a completely different practice and outcome given our approach, including enthusiasm and appreciation from the project teams for this approach as opposed to the more typical dread.

Participants in this presentation will hear from both a CMMI Lead Appraiser and an agilest who lead this value-driven approach to CMMI. They will learn how agile mindset, practices, and tools can be used to apply the CMMI model to our delivery, with intentional focus on creating an ever-maturing practice that reduces risk and increases quality. Participants will also hear how agile was used in the appraisal preparation, enabling continuous improvement across the organization and even reducing the amount of time and effort needed for the SCAMPI A appraisal.

Good news: Test-driven practices have jumped the chasm to general acceptance! The bad news, though, is that while TDD, BDD, and ATDD are prominent buzzwords in the industry today, they are rife with misconceptions, with many people incorrectly assuming that being test-driven is all about testing.

In this talk, learners will leave with a clearer understanding of Test-Driven Development (TDD), Behavior Driven-Development (BDD), and Acceptance Test-Driven Development (ATDD), and gain practical insights into how these practices can help teams develop better software. We will gain an appreciation for TDD as being primarily a specification and design technique, and how to get the whole team involved earlier in the delivery cycle using a BDD approach.

When companies are struggling to increase the quality of their deliverables they tend to turn towards quick technology fixes, for example pushing for more test automation. The real solution isn't a technology fix but a cultural one. We need to change our culture to one that embraces, nurtures and encourages software craftsmanship.

It's only when your employees care about the quality of their work and when your organization rewards quality over speed that you'll make a lasting impact. Let's explore what this means and how we can start this culture shift.

Some of the things we'll look into:

• How to implement code reviews that become primers for mentoring each other.
• How performance reviews can impact the quality of your software
• How a CICD improves software quality
• Changing your management style towards Management 3.0

Many times, meetings are called to figure out what to do.

Many times, these meetings fail to do just that

On my current project, we use "scarecrows" to make sure that we focus on getting a solution and getting everyone's input

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.

We all do it. In fact, I've done it already in this talk description. I've amended to title of the "Manifesto for Agile Software Development" to just "Agile Manifesto," and I suspect most of the you attending AgileDC 2019 have done this as well. In this talk I will argue that this truncation of the title of the Manifesto is more than an abbreviation of convenience, it is a sign that how we use the Manifesto in practice has moved beyond what was stated in the foundational document. For many folks Agile has significant importance and impact beyond software development. Just as our nation's Constitution has been amended over the years, I will propose amendments to the Manifesto in this talk.

Many agile talks are about the benefits of cross-functional teams and integrating them with your business and changing their structure to better align to the value delivery. And amazing things happen with you get all of this stuff working together. There are industries and organizations that can't do this. Not because they don't want to or that they are not interested in the modern ways of working, but because they don't have the skills in-house and the cost of bringing all of those skills into the organization are inhibited by constraints of one sort or another.

The use of contractors and outsourcing of IT development was a major push for many years as businesses focused on their core capabilities. Industries like government couldn't compete with the marketplace for IT skills and so turned to contractors to fill the needs in many organizations. Now, these same organizations feel they need to bring the modern agile ways of working to their organizations. So how do they actually get the benefits of modern agile ways of working and delivering products while continuing to use contractors for most of the work?

This talk will focus on 3 areas of achieving most of the benefits of modern agile work while continuing to use contracted work. First, how to decide what to outsource. The decision of which pieces or work to use contractors for is the most important. Second, how to actually hire contractors. The procurement process can be evolved to be more agile and to encourage finding contractors that will drive toward the desired collaboration. Finally, how to manage and work with contractors. The day to day grind of working where real delivery will be accomplished.

Getting benefits from an agile framework and delivery is important and can still be achieved when some of the work is outsourced and the importance of defining and finding the right contractor are vital to achieving the desired success.

Sometimes, a good debate is what’s needed. Conventional wisdom is boring. Agile is old enough now to inject some alternative thoughts. This session seeks to use the idea of the French Salon. A salon is a gathering of people under the roof of an inspiring host, held partly to amuse one another and partly to refine the taste and increase the knowledge of the participants through conversation. The intent is to combine learning, good manners, and conversational skill. Salonnières provided a place to gather, a topic, a structure or starting point for the gathering, and ensured that there would be a good mix of opinions among the guest list. “Salonnières therefore had to perform a difficult balancing act, cultivating individual merit without letting one guest overshadow the others.” Therefore, the goal is to facilitate the topic of Long Term Planning in Agile and whether there are any responsible ways to perform and execute it. Participants will bring their ideas along with an open mind to developing new possibilities.

DevOps has become all the rage from a technical change perspective; it really has changed the game. And while it provides numerous benefits, only after you also embrace the human side of change within the organization, can you really get to full Agility.

What if we could take advantage of a continuous delivery of change just like we do in our development pipelines? As executives, managers, Scrum masters, coaches, or anyone else in a leadership role, we should desire to make each change focused, easy, and small to contain risk. Once this is done, changes can mimic a development pipeline that delivers towards a business outcome. This workshop will help you learn how to keep the number and size of changes in check and consider how to manage the risks of deploying change.

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.