Have you tidied up your personal life with Marie Kondo and are now wondering how to achieve the same effect in your work life? Do you have the feeling that the most valuable product backlog items (PBIs) are getting lost under a mountain of old stories, bugs, and tasks? Maybe you know a change is needed, but feel completely overwhelmed about where to start? If so, join us to learn how to make your product better through the life changing magic of tidying up your backlog.

We’ll start by exploring the costs of a large, cluttered product backlog and share a short quiz you can use to gauge the current state of your own backlog. Next, we’ll cover how we’ve adapted the KonMari method and introduce five easy steps you can take to get started in your tidying process. We'll share real-life examples along the way, calling out potential pitfalls to avoid (don’t become a storage expert!), and illustrating how story mapping may be the magical backlog equivalent to Kondo’s “vertical folding” technique. By the end of the session, you’ll know the specific next steps to take so that you too can realize the many benefits of a tidied-up product backlog: improved visibility, increased self-organization, and easier decision-making.

Imagine you are asked to sit in on a team’s sprint review and retrospective. The team has been having difficulty forming and the Scrum Master has asked you to observe the team dynamics during these two sessions. Are you simply going to watch what’s going on or is there more you can do? Perhaps you are seeing interactions and team dynamics at play without truly realizing what you are observing. And when you do observe, are you injecting your own biases into those observations? Observation is a powerful tool, but one which we may not take advantage of to its true potential. After all, what exactly should we be observing, anyway?

By learning how to expand our observational skills in a non-biased and non-judgmental manner, we can gain a deeper understanding of team dynamics and interactions allowing us to offer more meaningful and impactful support, coaching, and empathy. Because there are many observational aspects that pass us by, the best way to become more observant is through deliberate practice. So, let’s practice together with a group exercise in a fun and safe setting!

In this highly interactive workshop, we’ll start by sharing tools and tips to make you a better observer. Then we’ll ask for a small group of volunteers (“builders”) to be observed performing a brief task. The remaining attendees will practice applying the observation techniques, and, after the builders finish, will share their observations in small groups. We’ll conclude with a full-group debrief and discussion of the key takeaways and opportunities to improve our effectiveness and observations.

If you’re looking for new ways to connect with your team, to enhance your agilist toolkit, or simply participate in an informative and interactive workshop, this session is for you!

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.

Using metrics for punitive reasons is a problem as old as time. In software, this is further complicated by the fact that people rarely agree on why we are collecting metrics in the first place. In this session we will explore how we can use metrics for good instead of evil.

By focusing on the goal of system improvement, rather than individual performance, we can begin leveraging data to make a positive difference in how we work while also delving into why we work the way we do.

This session will include real-world examples of problems that organizations create for themselves by using metrics for the wrong intent. We will also discuss examples of good metrics and how they can be used to make our lives better.

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.

Rather than engaging in an intense modernization effort followed by years of minimal maintenance, a better alternative often is modernizing a system continuously, balancing operations, maintenance, and renovation. Ideally you can improve, update, and upgrade the software system one piece at a time while it continues to operate, avoiding feature freezes and scary cut-overs.

There are always trade-offs to be made, but some approaches better fit IT systems with long-lived missions. At a certain point, a whole-sale rewrite is the best option for replacing stale, decaying software before it leads to major headaches and eventual catastrophe. Big rewrites have big risks and big failures, however. Because of the stability and enduring mandates of some software systems, long-term investments in IT systems pay off and give room for smart maintenance strategies.

Have you ever worked with a Business Analyst (BA)? Is what a BA does on an agile project much different from what is done on a waterfall project? All analysts bring excellent communication, collaboration, and trust to their work on project teams. During this session we’ll review the roles a BA can play, a BA's responsibility on the development team, and the skills a good BA possesses. For fun, lets also talk about why an Analyst is part of the 3 Amigos and the complexity of communication channels. Generally speaking, let’s discuss how BAs participate in an agile project’s success and I’ll share some stories about my experience going from waterfall to agile, how I’ve interacted with the PO, and important things I think an Analyst should be involved in.

Come learn how our 3 teams, operating in a LeSS-style scaled model, experimented with a NoEstimates approach to development work and then adopted that as our way of working for a year in the Federal government. Included in our story is a switch to Kanban, returning to Scrum, and eventually returning to pointing work. It has been a remarkable journey that I'm excited to share!

The Agile Manifesto doesn't explicitly talk about what changes in management should happen and neither do the approaches. In fact, sometimes we hear the exact opposite from teams - "What do we need managers for..?" or perhaps "Can't they just get rid of all the impediments we have?"

As a former manager and now as a coach, I find the words Servant Leadership sometimes doesn't resonate. It actually only paints part of the picture anyway. What we want are ways to enrich management so that they can do more for the organization and its teams. Let's discover what some of this enrichment might be.

If you’ve been exploring agile methods, you probably want to deliver the most value in the least amount of time possible. But what if the best prioritization and planning just isn’t enough to keep your organization at the top of your market?

Enter Impact Mapping, an approach that reveals the hidden assumptions that keep you from reaching your goal. This technique helps when you're looking for innovative solutions to tough business problems because you'll bring in strategic thinking skills as you identify the ones most likely to reach your goal. Even better, you'll know upfront how to measure the impact of those solutions, so you won't invest more than you need.

This workshop is hands-on, so get ready to learn while you’re working!

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

Do you feel like Agile Scaling has become a goal rather than the means to an end for your organization? To determine where you stand on the Scaling spectrum, ask yourself a few soul-searching questions: Why do we need to scale? Is this the right time for us to scale? If you’ve checked these boxes, you may wonder “where do I go from here?”

This talk will focus on 3 areas that emerged as common themes throughout my experience working on government Agile Scaling projects and ultimately influenced the trajectory of each agency's scaling journey:

• Communicate vision consistently
• Focus on your people genuinely
• Create your own path intentionally

I've seen successes and some struggles with Agile Scaling efforts in government agencies. Regardless of the agency acronym or the frameworks used, these key elements shaped their scaling outcomes.

Summary

In this session, you’ll learn about one team’s struggle to improve collaboration and how they sought to shorten cycle time by carefully crafting an experiment with an Andon Cord. The Andon Cord is a Toyota innovation designed to empower front-line employees to recognize issues, initiate a stoppage of work, and work together as a team to quickly identify a path forward. The emergency cable strung above assembly lines became a symbol of the Toyota Way, and has widely been copied throughout the auto industry and beyond.

You’ll be introduced to metrics that show a surprising correlation between collaboration through Andon Cord pulls and Cycle Time!

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

On average Agile transformations get into trouble at about 14 months from the time they start. Have you ever wondered why?

Is it because you started from 'the bottom up?" Or is it because you spend time, money, resources and people creating great teams and didn't pay attention to having a professional, empowered Product Owner organization?

Agile transformations that target department level and not the organization have a very low success rate and you end up with an agile department enveloped by a traditional organization. That leads to dark work, decision delay and dysfunction.

So, what can you do?

Come and learn some of what I learned the "hard way" over 7 transformations.

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.

Have you ever seen the term “process authority” used to describe the role of a Scrum Master? You don’t have to look too hard to find this description. In my experience, it has caused a lot of confusion and misunderstanding on project teams. So why is it even used? And should it?

I worked on a new Scrum project where management informed the project teams that the Scrum Master role was given process authority over the team. There was a lot of confusion and unease about this. Questions started popping up such as “I already have a manager – is the Scrum Master now my boss,” “What does process authority mean,” and “Do we really have to do what she says?” As a result, the teams were becoming hostile to the Scrum Master role, untrusting of the Scrum Master’s responsibility, and concerned Scrum Masters had authority to tell the teams what to do. I was the project’s agile coach and needed to diffuse the confusion and better the working environment as quickly as possible. This did not happen overnight, but our journey started with this interactive discussion which we used as a foundation for the project moving forward.

In this interactive presentation, we explore the concept of “process authority” and consider the various directions it takes us. To do that, this discussion goes far beyond a typical “the role of a Scrum Master” presentation; It explores…

• What it should (and should not) mean when/if “process authority” is used to describe the Scrum Master role
• How the responsibility and expectations of a Scrum Master are different than that of team members
• How different leadership styles play into understanding the role of the Scrum Master
• The importance of trust in a Scrum Master/team relationship

The presentation uses real-time audience feedback to further explore these topics. Audience members will provide answers to questions given throughout the presentation, so we can explore members’ thoughts, opinions, and experiences they have had with the Scrum Master role.