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.

 
 

Outline/Structure of the Workshop/Game

This is a structured workshop focusing on having people first recognize the problems with big changes and then moving them to understand how changes in the small can improve what they can achieve.

We envision the workshop proceeding after a quick intro as follows:

Opening Exercise: The Default

We provide two scenarios

1) a large entertainment company that is attempting to proactively change to better react to the market.

2) a fictional government organization that needs to modernize its software systems to better handle its mission.

We will let people quickly gravitate to those that interest them, keeping in mind that there will be a minimum number for each - we want enough people to discuss two different types of big change that occurs in each organization. For the entertainment company scenario, one group of 4-6 will have the big changes of Agile Transformation and another group will have Digital Transformation. For the government scenario, one group will have Agile Transformation and the other will have Modernization. The opening explanation and movement to where they want to explore will take about 2 min.

If we have more than 4 groups, we'll repeat the types of change.

We'll ask each group to develop the steps they think are needed to enact the type of change provided and any order/dependencies and what success looks like. The groups will put these on flip charts. We expect to give the groups around 7-8 minutes to do this.

5-7 min Debrief: These are the driving questions to answer...

What were some of the selected steps? (We'll focus on one the two scenarios in turn.)

How would you know you are being successful?

What linkages do you see between the two types of change efforts?

2-3 min Present the concepts:

BIG Change > Has to be named > Have to sell it > Focuses on compliance

> Need clear roadmap > End State

BIG Changes tend to be silo-ed efforts

What if we went small? What if we didn't have an end state?

Provide a takeaway sheet of possible small change patterns for use in the next exercise and for use back at their work. This will be a blend of organizational change patterns and a few technical change patterns.

Follow-up Exercise:

2-3 min Keep the scenarios, extract 1 business outcome desired; something that helps them serve their mission or customers; write in the center of the flip chart

2-3 min Identify 2-4 players that need to change their ways to get this business outcome; connect this up (in mindmap form)

3-4 min Identify the behaviors that need to change in order to be successful

4-5 min Identify 2-3 change options (technical or organizational) that could be made to help bring about these behaviors - use your sheets to help you if stuck, but feel free to think of ideas yourself

3-5 min Identify how you know that the change you selected is working for that actor; how will you know if the behavior is changing

5-7 min Debrief: These are the driving questions to answer...

What was different about this round?

For your behavioral change, how fast are you likely to see it occurring? What can you do if it isn't the result you wanted? If it will take a long time to get feedback, what might we do?

If we had to 'name' this change, what would we call it?

What mix of organizational and technical choices did we have?

Reveal that in their groups they built an impact map for their organizational change.

Remaining Time: Answer any questions

Learning Outcome

  • How to recast the focus of change from change's sake to business outcomes
  • How to select small changes
  • Some patterns for making these small changes happen
  • How using an impact map for change management can help you inspect and adapt

Target Audience

Executives, Directors, Managers, Scrum Masters, Coaches

Prerequisites for Attendees

Participants should at least have some awareness of the concept of organizational change.

schedule Submitted 1 year ago

Public Feedback


    • Richard Cheng
      keyboard_arrow_down

      Richard Cheng - How to REALLY use the Agile values and principles!!

      Richard Cheng
      Richard Cheng
      Principal
      Excella Consulting
      schedule 1 year ago
      Sold Out!
      45 Mins
      Workshop/Game
      Beginner
      Your organization is doing Agile, which great, but what does that really mean? Perhaps they are implementing Scrum, or Kanban, or one of the other Agile methods, but are they really being Agile? Does it feel like you are you are doing Scrum, but you’re team isn’t really Agile? There's difference between doing Agile and being Agile and this session explores that concept.

      In this session, we’ll understand what Agile really means and how that relates to the way we implement our Agile methods within our organizations. We'll identify how we effectively use the Manifesto value points so that we can maximize the value of our products while still ensuring that we have quality and governance built into our process. This session will also explore the use of Agile principles to guide our strategic and day to day decisions.

      This sessions is great not only for beginners, but for anyone who wants to get past simply implementing Scrum or Kanban by the book, but really understand how to use Agile values and principles to build better products and organizations.
    • David W Kane
      keyboard_arrow_down

      David W Kane - Hang Out with the DevOps Folks!

      10 Mins
      Lightning Talk
      Intermediate

      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.

    • 45 Mins
      Talk
      Beginner

      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.

    • Mark Grove
      keyboard_arrow_down

      Mark Grove / Julie Wyman - What’s REALLY Going On? An Observational Skills Workshop

      45 Mins
      Workshop/Game
      Beginner

      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!

    • Mathias Eifert
      keyboard_arrow_down

      Mathias Eifert - Complexity is the Enemy! How Agile Practices Allow Us to Operate in a VUCA World

      45 Mins
      Talk
      Intermediate

      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.

    • John Tanner
      keyboard_arrow_down

      John Tanner - Using Metrics for Good not Evil or: How I learned to Stop Worrying and Love the KPIs

      45 Mins
      Workshop/Game
      Beginner

      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.

    • Mark Koenig
      keyboard_arrow_down

      Mark Koenig - Continuous Modernization

      Mark Koenig
      Mark Koenig
      Scrum Master
      Excella
      schedule 1 year ago
      Sold Out!
      45 Mins
      Talk
      Intermediate

      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.

    • Mindy Bohannon
      keyboard_arrow_down

      Mindy Bohannon - I’m a BA Girl in an Agile World

      Mindy Bohannon
      Mindy Bohannon
      Agile Business Analyst
      Excella
      schedule 1 year ago
      Sold Out!
      45 Mins
      Experience Report
      Beginner

      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.

    • Adam Parker
      keyboard_arrow_down

      Adam Parker - NoEstimates at Scale in the Federal Government

      Adam Parker
      Adam Parker
      Agile Coach
      Excella
      schedule 1 year ago
      Sold Out!
      45 Mins
      Experience Report
      Advanced

      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!

    • Paul Boos
      Paul Boos
      IT Executive Coach
      Excella
      schedule 1 year ago
      Sold Out!
      45 Mins
      Tutorial
      Executive

      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.

    • Colleen Esposito
      keyboard_arrow_down

      Colleen Esposito - Beyond Prioritization: How to Make an Impact for your Customers

      Colleen Esposito
      Colleen Esposito
      Agile Coach
      Assurant
      schedule 1 year ago
      Sold Out!
      45 Mins
      Workshop/Game
      Beginner

      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!

    • Nicole Spence-Goon
      keyboard_arrow_down

      Nicole Spence-Goon - Peaks or Valleys? The power of Scaling Agility in the alphabet soup of Government agencies

      Nicole Spence-Goon
      Nicole Spence-Goon
      Agile Coach
      Excella
      schedule 1 year ago
      Sold Out!
      45 Mins
      Experience Report
      Beginner

      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.

    • 45 Mins
      Talk
      Beginner

      Have you tried TDD? Do you hate it? Do you have a hard time applying it in practice? Do you find it promoting bad design decisions because you must write micro tests instead of looking at the big picture? Are your tests tightly coupled to the implementation due to a lot of mocking making refactoring a pain? Do tons of tests break when a simple change is made? Do you have a hard time justifying all the time spent on writing tests vs. just focusing on development?

      You are not alone. Every organization or team that I run into is supposedly Agile. Some are also applying agile engineering practices such as automated unit, integration and acceptance testing, etc… However, many struggle with TDD. TDD is hard, seems counter-intuitive and requires a lot of investment. Come to this session for a TDD reboot. We will look at the benefits of TDD, discuss the resistance to TDD and uncover some common difficulties along with misconceptions. We will then address these misunderstandings and explore different approaches to making TDD easier. Leave with a fresh perspective and new insights on how to become better at TDD and apply it with ease.

    • Zack Ayers
      keyboard_arrow_down

      Zack Ayers / Joshua Cohen - Andon Cords in Development Teams: Our Experience of Driving Continuous Learning through a Culture of Experimentation

      45 Mins
      Talk
      Beginner

      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!

    • David Fogel
      keyboard_arrow_down

      David Fogel / David Bujard - Nine levels of Agile Hell... and how to get out!

      45 Mins
      Talk
      Beginner

      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.

    • 45 Mins
      Talk
      Beginner

      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.

    • Dane Weber
      Dane Weber
      Lead Consultant
      Excella
      schedule 1 year ago
      Sold Out!
      45 Mins
      Experience Report
      Intermediate

      After three years as a Scrum Master and Agile coach, I hit a wall coaching a team that did not want to try popular Agile engineering techniques such as TDD and pair programming. I had become a Scrum Master after four years working on the business analysis and account ownership side of things and could not speak from personal experience about engineering practices. In order to get some first-hand experience and to gain a new perspective, I chose to spend a year or two as a software developer on a Scrum team.

      The experience has been eye-opening. I experienced a tremendous cognitive load working with a wide array of technologies; this pulled my attention away from many of the collaborative and process-oriented activities I cared about as a Scrum Master. I was surprised to feel strong pressure to complete work quickly, cutting corners, even when the Product Owner and Scrum Master were not asking me to. When this pressure was explicit, it usually came from my fellow developers. On the other hand, there is real joy in writing code and seeing a system do something worthwhile that it wasn't doing before. My outlook has changed tremendously and is something I want to share with anyone who works with development teams, especially Scrum Masters and other coaches. I am still enjoying my time as a developer, but I'm looking forward to returning to coaching and incorporating this experience into my approach.

    • David W Kane
      keyboard_arrow_down

      David W Kane - Amend the Agile Manifesto!

      10 Mins
      Lightning Talk
      Intermediate

      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.

    • Mark Grove
      keyboard_arrow_down

      Mark Grove - Authority and Trust: Finding the Scrum Master Balance

      Mark Grove
      Mark Grove
      Excella Consulting
      schedule 1 year ago
      Sold Out!
      45 Mins
      Talk
      Beginner

      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.

    • Dr. Patrick McConnell
      keyboard_arrow_down

      Dr. Patrick McConnell - The Velocity Trap: Learning to Value Enterprise Outcomes over Team Output

      45 Mins
      Tutorial
      Beginner

      Behind the creation of every Agile Framework was the intention to improve the Return on Investment for creative work, primarily through faster and richer feedback. But as team-level frameworks like Scrum are internalized by large organizations, that message gets mistranslated. Instead of, “Get better outcomes, sooner,” the drive instead becomes, “Just do more, faster.”

      A common expression of this problem is the confusion of Velocity for Value, where teams are directly managed based on their Output, but the connection between Output and Outcome is lost or ignored. This plays out in all kinds of ways that distract from achieving tangible results, and often incentivizes internal competition over collaboration. This problem can be especially tenacious in organizations with significant institutional ‘status-ing’ behaviors, where leadership struggles to translate common Agile methods like Relative Estimating into existing artifacts like Executive Dashboards or Earned-Value Management.

      In this tutorial, participants will explore the 'Velocity Trap', and will be shown how to setup a results-driven framework that prioritizes 'Maximizing Outcomes while Minimizing Output.'