In this panel discussion, four executives sit down to explore some of the key concepts and common threads covered in the Elevate Agile talks. Together, they discuss some of the history that’s led us to this point in the Agile industry and share real-world examples and stories to illustrate how they’ve elevated Agile in some of the largest companies in the world.
Calling Your Shots: Creating Safety, Accountability and Orchestrating Change at ScaleChange doesn’t happen by accident. Change must get planned, orchestrated, and held accountable. Many organizations have a Project Management Office responsible for setting standards, providing resources, managing work, and making sure the organization’s work is visible. We need to discover a similar mechanism for orchestrating an Agile Transformation, an Agile Transformation Office, if you will. If such an office were to exist, what might it look like? What might it be responsible for? How would that office ensure the Transformation was on track? And what would it do once the Transformation was over?
This talk will explore some of the more common elements of an Agile Transformation Office. How you create one. What services it offers. And its overarching responsibility to responsibly lead change. We will look at how it selects and supports pilots and develops Transformation roadmaps. We will explore the role of Agile playbooks, Agile tooling, metrics, and assessments. We will explore how training and coaching fits in and what you do with the rest of the organization when it’s excited to go but isn’t on the near-term roadmap. Finally, we will explore the relationship between the Agile Transformation Office and the Office of the CIO and what it looks like once the Transformation is complete.
Topic Areas:
In this talk, Amy tells you about her experiences at Ford Automotive and how they used Agile principles to evolve so they could focus on services, experiences, and technology to build a better world where every person is free to move and pursue their dreams.
Engaging the Enterprise at Scale: How to Get Everyone Else to ChangeOne of the challenges of introducing Agile into an organizational ecosystem is that the principles, practices, mindsets, organizational structure, governance, and metrics are orthogonal to how most corporations do business. Agile gets installed in the small and is instantly at odds with the current operating model. It is incongruent with how work is funded and approved and how it handles compliance and corporate governance. To even have a chance, agile is granted exceptions to these control frameworks. Still, in the end, these frameworks will limit our ability to make progress and achieve true business agility.
The goal of an early-stage Transformation is to organize our systems and structures around markets and customers. It is to use Agile to create a reliable system of delivery, a system of delivery that executives can reliably delegate into to achieve their goals. Once we have teams, workgroups, and departments that can reliably, predictably, and economically solve problems for their clients, a world of options opens up for refactoring the organizational operating system to align it with the delivery organization and to make it an enabler of Agility rather than an impediment to Agility. Once the system is trustworthy, how do we begin to trust?
This talk will explore how to deal with annual cycle planning and move it to a more frequent exercise. We will deal with issues of batch size at enterprise scale and how to pivot the organization from project or business capability-based funding to funding value streams. Finally, we’ll discuss how to move closer to continuous planning and continuous delivery and closer to an organization that is inspecting and adapting in real-time so that it can sense and disrupt, and ultimately dominate its marketplace.
Topic Areas:
Most organizations view Agile as a way the delivery teams produce working software. Even when we get agile working well at the team or workgroup level, we often fail to consider how the rest of the organization will need to change to exploit this new delivery capability. Once we have a trustworthy system, one we can delegate into that does what it says it will do, when it says it will do it, what has to change companywide for true business agility?
We will never get true business agility unless we can impact how product marketing and strategy work, strategy articulation and delegation, budgeting and funding, technology and architecture, compliance and controls, talent and culture, and of course, leadership and management style. It’s unfair to ask the organization to change how it governs until the new system is installed and predictable. But what must change once it is?
Topic Areas:
For years, the Agile community has taken the approach that an Agile Transformation was about teaching people the principles, practices, and mindset of an Agile organization. While principles, practices, and mindset are incredibly important, they are insufficient for successfully orchestrating a transformation at scale. Everything about agile assumes that you have complete cross-functional teams, clearly articulated and strategically aligned backlogs, and the ability to produce a working, tested increment of software at the end of every sprint. This begs the question; what do you do if you don’t?
Over the past 10 years of helping orchestrate some of the largest Agile Transformations in the world, we’ve come to learn that the real work of an Agile Transformation is about creating the conditions for Agile principles, practices, and mindset to take hold. In the small, it’s about how you form teams, how you build backlogs, and how you produce working tested software. In large, it’s about creating a team-based organizational structure, an Agile governance framework, and metrics that support, enable, and reward delivering with Agility. It’s about having a plan for what to do with dependencies, and more importantly, how we are going to break them.
Creating the conditions for Agile to thrive is as much about refactoring the organizational architecture as it is about refactoring the technical architecture. What compensating controls do we put in place while dealing with dependencies, and how to dismantle those controls once we’ve broken the dependencies. It’s about having a clearly articulated end-state and a tightly orchestrated and funded plan for how you are going to get there. It’s about It’s about enlisting key stakeholders, aligning the enterprise, defining an end-state vision, a roadmap, and a credible plan that will move the organization forward with a high degree of certainty.
This talk will explore several models for how to think about defining your organizational end-state. How to break big organizations into smaller groupings of teams and put together a credible and accountable plan for stewarding the organization as it moves ever closer to greater Business Agility.
Topic Areas:
Discover how Lockheed Martin is using Agile principles to generate disruptive innovation. In this talk, John and John will cover how Lockheed Martin is improving their processes, technology, and tools to drive Agile responsiveness and provide data-driven insights to their customers. Over the course of the talk they’ll tell you about some of the practices they put in place and the results they began to see.
Agile Transformation and Delivery Systems at ScaleSmall teams dominated the early days of Agile, often collocated and working side-by-side with onsite customers. With autonomy over their technology stack and the ability to do push button changes into production at a moment’s notice. The core organizing principle was that we had dedicated teams, working off a clearly articulated backlog of requirements, producing an increment of working-tested software at regular intervals.
As Agile got more popular, it got codified into methodologies like Scrum and SAFe. While these approaches are aware of the necessary pre-conditions to make themselves work, they didn’t meet teams where they were and provide guidance to help practitioners untangle their organizational designs and technology architectures. The net effect was often poorly formed teams, insufficiently clear backlogs, and the utter inability to produce a working tested increment of product at the end of the sprint.
Solving these problems requires that we look at the System of Delivery holistically and articulate a strategy for forming teams, feeding those teams strategically aligned backlogs, and integrating and measuring the output of multiple teams working in tandem to deliver more complex and larger scale deliverables. Cross-team coordination and dependency management become essential factors in making Agile work, especially in an early-stage transformation.
Topic Areas:
This year the Agile Manifesto celebrates its 20th anniversary. As a document, it’s challenging to find an approach or philosophy, or way of thinking that has more deeply captured the imagination of the world of software development. The Manifesto articulated four values and twelve principles that empowered small teams of engineers working side-by-side with their customers to deliver products early and often to get maximum feedback, maximum value, and strong attention to software craftsmanship and technical excellence.
As Agile grew in popularity, it similarly captured the imaginations of Project Managers, Directors of Development, and even Senior Executives. The promise of cost-efficient, lightweight teams, working with minimal bureaucracy and overhead, delivering working tested products on regular intervals, maximizing speed and return on investment seemed almost too good to be true. Looking back over the past twenty years, now might be a good time to ask if it was too good to be true? Did Agile deliver the value it promised?
In his opening keynote, Mike Cottmeyer will explore what we’ve learned over the past 20 years about adopting Agile practices and Transforming Agile organizations. We will look at what the signers of the Manifesto got right, but why it’s incomplete as a model for scaling to larger enterprises. Mike will make a case for how we must elevate the conversation around Agile or risk Agile being relegated to that thing teams do, which has nothing to do with running a business.
Now is the time to close the gap and elevate the conversation around Agile.
Topic Areas: