You've done the scrum training, you've completed the team forming agreements, and you've enhanced your branching and merging strategy. For all intents and purposes, your scrum teams are moving faster than ever. So why does it still take six months to get anything to our customers?
Hi, I'm Lance Dacy, otherwise known as Big Agile. And let me guess what your teams are dealing with.
The All-Too-Familiar Bottlenecks
Your team finishes a sprint ready to deploy, but maybe your data center operation says we only have deployment windows once a quarter. Submit a change request and we'll review it in three weeks. And by the way, the people reviewing it have no idea what that change is.
How about this one? Your team identifies a critical technical investment that would accelerate delivery, but finance says, show me the detailed ROI analysis for the full fiscal year. Where's your capital authorization request? We'll review it within the next budget cycle.
Or one of my favorite ones: your team desperately needs to add a designer or hire a specialized engineer. But HR says, well, we need to open a req. We need to get multiple approvals, we got to post it for 30 days. We got to interview and then we got to wait for the start date. That'll be like four to six months.
So your developers end up iterating every two weeks, but they're trapped in a system that's designed for annual budgets, quarterly releases, and hiring cycles.
The Real Problem: Teams Aren't the Issue, The System Is
Let me paint a picture that's a little bit more full of what I see in organizations everywhere. You've done the work, you've trained your teams, you've got product owners who understand value delivery. You have go-to-market teams that are ready to go. You've got five scrum teams in a product group that are running smoothly with two-week sprints, and they're delivering working product consistently and collaborating beautifully. The retrospectives are really generating good improvements.
But here's what happens: your two-week sprint cycle gets batched into, let's say, a three-month release cycle. Value sits waiting and is invisible. Inventory and feedback get delayed, and risks actually increase because you're deploying larger batches less frequently.
I tend to think of it like this: the teams really aren't the problem. It's the system around them. And here's why this is so insidious—HR and finance controls kind of control what we call the purse strings. Operations control the go-live. Or you have these policies in place where your developers can't release directly to production, so it has to go through a change control board.
We've seen this movie before, and those people aren't being malicious, by the way. They're doing exactly what they were designed to do. They're protecting the organization from risks, financial or otherwise, and ensuring compliance to the SOC 2 policies or whatever it might be. They're maintaining governance and stability. That's exactly what they were there to do.
But their control systems were actually designed, I believe, for a world of predictable annual projects with distinct phases, large batches, and minimizing variation as we go. And so those control systems are now becoming the constraints of your organization.
What Enterprise Agility Really Means
What we're really talking about here when we say enterprise agility is we're not just trying to scale scrum practices. That's what I get hired a lot for. We're trying to create agile organizations. That's really what we want to talk about here.
Teams should be able to deploy when they have value to deliver, not when some group or the calendar says that it's allowed. Finance should enable fast decisions with small batch authorizations, instead of forcing everything—whether it's a $50,000 investment or a $5 million investment—to go through this annual planning cycle. We want HR who can staff critical needs in weeks, not months. We want to develop people for collaborative excellence instead of individual heroics.
Most teams will create some bad habits because of some lack of skill that's now baked into your organization. So the quicker we can get the right skills or cross-pollinate those skills, typically the better we'll be.
Now we're creating what Mike Cohn calls in his book Succeeding with Agile "far from equilibrium conditions." And what that is, is an organization that's always adapting, always evolving, instead of one that resists change and tries to return to the comfort zone. I like to call that organizational gravity.
Legitimate Concerns About Governance
I know what you're thinking: but finance and HR and operations have legitimate concerns. We can't just ignore governance, financial controls, and risk management. And you know what? You're absolutely right. I'm not trying to eliminate controls. We're just trying to design—or redesign—them so that they support agility instead of stifling it.
And I get it, this is hard. Change is hard, especially when you're asking people to redesign a system that they've worked in for decades, systems that have shaped their very careers, and systems that frankly prevented real disasters in the past. We celebrate that.
But here's the truth: your agile teams will only be as agile as the slowest, most controlling function in your organization. And right now for most organizations, once we get the product teams up and running, those tend to be like finance, HR, data center operations, or technology operations. Sometimes if they are not part of our product development team, they can cause a great deal of constraint.
A lot of times we say this because they control the purse strings—either the money coming in (we need new servers, we need this, we need that) or they control approvals, or they control when value can actually reach the customer.
And so the question isn't necessarily how do we scale scrum and agile? The question is: how do we create an organization where these control functions—very important functions—enable agility instead of constrain it?
Three Organizational Control Systems That Either Enable or Strangle Transformation
I want to show you three organizational control systems that usually either enable your transformation or strangle it. And I want to be really clear: I am not blaming HR, finance, or operations. These systems were designed for a different world. They were built for stability, predictability, and control, but they're now actively working against the agility that we strive for.
This is where leadership, in my opinion, becomes absolutely critical. Because without leaders who understand that these barriers exist and have the courage to redesign them, the agile teams don't stand a chance. We can do our best in the trenches delivering value, but it'll get stifled at some point.
HR: The System Designed to Reward Bad Behaviors
Most of us are familiar with performance reviews that are all about individual achievements. The evaluation criteria typically reward individual contribution or individual performance. One of the first things when I sit down and talk about Scrum or any kind of agile process is the word—the management dogma starts creeping in. They're like, "Well, if everybody's responsible, none of us are." And it's like, yeah, it's dogmatic. It doesn't really work for professionals. Professionals want to do the best we can.
The Story of Chuck
I want to tell you a story about a developer we'll call Chuck. And this story just breaks my heart every time I tell it because I see it play out in dozens of organizations.
Chuck was a fantastic backend developer. If you're talking about a software team, these are the people that really do the heavy lifting of getting the data up into the presentation layer. That's where a lot of the business logic is hidden. That's where a lot of the controls are hidden. He was great at it, and he was consistently a high performer on his annual reviews.
But when we were transitioning the team to be truly cross-functional, we actually needed a lot of our backend developers to learn more of the front end. Nowadays, we might call them full stack developers—there's different words for them now—but the point is there's not always just backend work that we need that helps us move features forward to the customer's hands.
We needed everyone to develop some kind of skills—a lot of times front end skills or DevOps skills to understand deployments, to become more T-shaped, as we call it.
And Chuck essentially refused. He came to me and said, "I'm more productive staying focused on the backend. That's where my knowledge is. And that's where I'm getting reviewed on, and that's what gives me my raises. If I start spending time learning more of these other things, my output goes way down." He was afraid that his performance review would suffer and maybe he would lose money.
Y'all hear what I'm saying there?
Chuck Wasn't Wrong
Here's the painful part: Chuck was not wrong about those concerns. His performance metrics were based on his own contributions, his performance, his individual utilization, whatever you want to call it. We really can't penalize him for trying to stay in his lane.
But I was trying to convince him that we have to change the word productivity. What does that really mean? We want to optimize for delivery to the customer, not optimize for his utilization, and that might require him to know other skills. And the other thing—you're going to be a lot more marketable in this day and age. If you only know one skill, you're going to have a hard time finding a job.
So I was trying to pivot and make it a little bit more palatable for him. But the team needed more cross-functional capability. They needed more generalists, not all these specialists that were there. And I'm not against specialists—they have their place—but we needed people who could pick up work wherever the constraint was, even if they did go a little bit slower.
But the HR system said, "Stay specialized. That's how you get promoted."
The Solution: Balanced Scorecards
When we talk about HR and what we can do to mitigate that, enter the balanced scorecard. People typically intrinsically prefer individual work over group work accountability. And that's a hard thing for us to swallow sometimes. We're uncomfortable trusting our careers to outcomes that depend on others. And our systems typically reward individual output with narrow specialization, not necessarily team outcomes.
So we need more of this balanced scorecard approach. What I like about this is having different areas that you're going to be graded and scored on—like customer, financial, education and growth, and maybe internal processes. If we can start scoring individuals that way, they may be more enticed to help us with the productivity of the team at large.
But here's the truth: you cannot have a truly agile, cross-functional, self-organizing team when the HR systems are designed to identify and reward individual specialists who maximize their personal output. It's just not possible. The system is literally telling people: stay in your lane, maximize your numbers, or you won't get promoted—no matter what we're saying in the trenches.
This is a leadership challenge. HR cannot fix this alone. It requires executives to say, "We're redesigning how we develop, evaluate, and reward people because team outcomes and versatility in the organization matter more than individual utilization."
Yahoo's Transformation Example
A company you might be familiar with that did this is Yahoo. During their transformation, they understood this and they asked employees—since adopting scrum was what they did—how was your sense of accountability and ownership, how has that changed? How has collaboration changed and how has morale changed?
So they were measuring the shift from individual to more of a team mindset. But more importantly, they started building new systems: team-based objectives, peer feedback loops, growth frameworks that recognized individual skill but also the collaborative impact of how they were doing with that.
So that's creating an agile organization. That's kind of what it looks like. Yahoo redesigned HR support systems to account for team-level accountability.
Finance: The Gatekeeper That Can't Let Go
In product operations, typically how we fund projects is a big impact to how we're going to manage our roadmap planning process.
If you have a traditional project approval process with phase gates—like analysis, design, build, test—in traditional project management, finance controls the purse strings through phase gates because they don't deliver funding unless they buy into what it is that we're trying to do.
So they maybe won't release the next round of funding until you get completed with one of these phase gates like analysis. They'll release more when that design is done. They need these distinct phases to determine when something is technically feasible before they'll actually capitalize it. Because there's all these other rules about capitalization, CapEx and OpEx and things like that.
I love how Mike Cohn also says in his Succeeding with Agile book that even through a sprint, when we deliver some feature, that is already proving it's technically feasible. So you could account for that delivery, but they're just not set up that way.
The Problem With Sprint-Based Delivery and Traditional Finance
If we go back to sprints and say here are these iterative and incremental cycles of sprints, we're not doing phases—we're delivering actual product increments. But in Scrum we don't have those distinct phases. So finance just basically freezes and they don't know how to declare feasibility. They don't know when to capitalize versus expense. They can't reconcile the iterative delivery nature with the annual budgeting cycles.
And while they're out there figuring that out, our agile teams are just stuck waiting for approval to do work that they already know needs to be done.
Fund Teams, Not Projects
But here's what's deeper, I think, and this is the real problem: finance is still trying to fund projects when they really should be funding teams.
Think about what happens in the traditional model. A project gets proposed. Finance says, "Show me the business case, show me the ROI, when will it break even? What's the payback period?" They do all this analysis to approve the project and then allocate the budget.
Then six months in, the market shifts. The team discovers that the original assumptions that we were operating under are now wrong. Customers actually need something different. But now finance says, "No, this is what we approved for this project. We did the ROI analysis of that particular project." And they're not willing to change. You can't pivot without going back through the approval process. And you can understand why that is.
But software and product development projects really aren't like that.
A Different Model
Imagine a different model where instead of finance funding the projects, they fund stable teams. A product team that has a clear mission gets a budget not for the project, but for their capacity to deliver in an area of their product discovery.
So the team discovers something isn't working, then they can pivot. They can learn what customers need and pivot to that. They adapt. The ROI analysis really isn't about "will this feature pay back?" It's about "is this team with this mission creating more value than they cost?"
When you can annually budget "I'm going to have this many people on this product team," it's a lot easier than project by project. So we let the product management, the go-to-market team, and the stakeholders manage the capacity of the team and, of course, trust them to do that.
The ROI Analysis Illusion
The truth is that nobody really wants to say out loud: the detailed ROI analysis on individual projects is terrible. It is mostly an illusion anyway. Finance is spending weeks on spreadsheets, making assumptions about adoption rates, revenue impact, and cost savings. And that stuff won't be validated for years. And so meanwhile, the team's just sitting around waiting. I feel like it's all an illusion anyway.
Finance will give—they'll throw back terms at us like, "Well, we got to track CapEx and OpEx and all that." So let me talk about that problem, right? The capitalization challenges are still there. Scrum and Agile doesn't make them go away, but I feel like they're easier to navigate when you fund teams instead of projects because you can then amortize costs across the team's portfolio of work rather than trying to trace every hour to some specific project for capitalization. And by the way, those developers that are putting those hours in there, it's one of those things anyway. So it's really just an illusion.
Making this change requires leadership. Finance directors and CFOs don't wake up one day and say, "You know what? Let's throw out this project-based funding and ROI analysis." They're never going to do that. So executives have to sponsor this change. They have to say, "Hey, we're shifting from funding projects to funding teams"—which also requires some level of new organizational design to product groups and things like that that we teach.
But the thing is unraveling this: detailed ROI spreadsheets for every single initiative and tying that back to measuring value and throughput and making fast decisions about where to invest. Maybe monthly at the latest, we have these innovation councils that we entrust to do that.
So that's definitely a hard shift.
Operations: The Utilization Trap
But I'm going to tell you, here's a shift that might actually be the hardest one that I encounter a lot of times: operations—whether it be deployment operations or just the operational mentality of people doing work. A lot of times their success is measured by utilization rates and things like that.
I've done a lot of blogging and even some cool tools to help us refigure some metrics that actually help us capture what we're doing. I call it flow efficiency, DORA metrics, and things like that. Those are some really good metrics to start with. So check us out on some of our blogs—we have some of those.
The Cost of 100% Utilization
Traditional thinking says: keep everyone busy. If people aren't working, we're wasting money. So maximize utilization. It makes intuitive sense. People need to be busy and doing work.
But remember that a six-month project that could have been done in two months if people could focus—that's the cost of the utilization trap. When everyone is 100% utilized, our work sits in queues waiting. Delays compound. Context switching destroys productivity. And ironically, you're going slower even though everybody seems like they're really busy.
Now my question is: would you pay 20% more to get a critical enhancement out in two months instead of six? Every executive I think would say yes. But here's the truth: you don't get there by adding people or working harder. You get there by removing delays, by having fewer and smaller queues, by adding what I like to call strategic slack to the system. We built systems that don't do that a lot of times.
The Shift Required
We have to shift from managing people's utilization to managing workflow delays, from local optimization (sub-optimizing locally) to value stream throughput. Let's have a portfolio board where we look at all these different value streams and what are the holdups for that value to flow to our customers.
The Pattern: Deeply Embedded Control Systems
I hope what happens is you see the pattern. These aren't minor friction points. These are deeply embedded control systems that were designed to prevent variation, ensure predictability, and maintain the status quo. They're doing exactly what they were designed to do, but that design is incompatible with organizational agility. And that's what we have to have the courage to stand up for.
Creating an agile organization means redesigning those control systems, and that requires leadership—leadership with the courage to challenge decades of management orthodoxy or dogma.
Real Data: Proof That Creating Agile Organizations Works
I want to show you data from real companies that created these agile organizations—not necessarily the global giants that everybody kind of quotes, but three examples where leadership actually drove system-wide change.
Case Study 1: Salesforce
This one may be a global giant, so I'm probably violating the one thing that I was saying here, but I'm going to talk about Salesforce. It was almost Halloween—or it is Halloween today that I'm recording this. October 30th, 2006, it was largely believed that Salesforce was operating in waterfall, and then Halloween day they were transitioning to Agile in one day. That's a hard change to make, but Salesforce did it and they committed to that enterprise change.
They were founded in 1999 and had grown to $450 million in revenue with over 2,000 employees by 2006. But they'd slowed down dramatically. Releases had dropped from four per year to just one. Customers were getting less value and waiting a lot longer for it.
So leadership didn't just say, "Let's do Scrum in engineering." Steve Green and Chris Fry, backed by executive sponsorship, redesigned how the entire organization worked.
First Year Results
The first year of transition data shows:
- 94% more features were released in the first year
- 38% more features were developed
- 500% more cumulative value delivered to the customer
A consequence of that was actually that their revenue doubled to over a billion dollars in the next two years.
What Made It Work
What made it work is they had to work with finance on new capitalization models. They had to work with operations on deployment cadence and security controls—all those things were still important. And of course they had to work with the go-to-market team, like support with release management, and HR on how teams were evaluated and hired for.
So this wasn't really just a scrum rollout. This was creating an agile organization, and leadership was driving that change across every function. 500% more value—I mean, that is a big, substantial increase. Leadership drove that change, and that's a great case for it.
Case Study 2: Systematic
Another one that I want to talk about is called Systematic. They're from Denmark. They were basically a culture that was striving for CMMI level five certification. It was a 400-person independent software developer. They work in defense and healthcare and manufacturing, and they were already CMMI level five, which means they had serious—I mean serious—process, discipline, and control systems.
So leadership made a really bold decision. Instead of saying "Scrum or CMMI," they said "Scrum and CMMI"—or Agile and CMMI. So they redesigned their processes to support both discipline and agility.
The Results
The results were great:
- 50% reduction in defects
- 50% reduction in rework and total work required
- You could even say that's a 50% reduction in process overhead
They did all that while maintaining the same level of discipline.
When you look at that—all of these reductions and still having the same discipline—change is hard. I'm sure it caused some strife in the organization, but that's an amazing thing to accomplish for them.
Jeff Sutherland, the creator of Scrum, called this combination a "magic potion" because leadership understood that you don't throw away control systems. You basically redesign them to support agility instead of stifling it. So CMMI ensured all relevant processes were considered, and Scrum ensured that those processes were implemented efficiently while embracing the change that had to happen.
But neither of those will work without leadership saying, "We're creating something new here."
Case Study 3: Primavera Systems
The last one I want to talk about is Primavera Systems. They were challenging themselves with compliance without losing agility. They were more of a project management software company. They were already doing these agile practices, but they needed an ISO 9000 certification for their customers.
When you start mentioning that, what's the fear? It's like, "Oh my gosh, well that compliance will kill their agility with all the overhead."
So leadership sponsored a 10-month effort where they conducted 30 cross-functional workshops to document their process. Their mantra was: "Provide just enough documentation to be useful and helpful with the process enforcement." I'd always add another one to that that says, "Are we willing to maintain that documentation as well?" A lot of times that answers all the questions that need to be answered on documentation.
The Pattern in All Three Cases
If you notice the pattern in all three cases:
- Leadership sponsored the change
- They didn't delegate it to a transformation office and then walk away
- They designed organizational systems like HR, finance, and operations along with product development—all of them
- They created this "far from equilibrium" condition
- They kept the organization adaptable, ready to evolve instead of letting it settle back into its old pattern
And that's really what separates successful transformations from failed ones. Not the scrum training, not the Kanban boards. Those are catalysts for sure—I love doing those things. But leadership with the courage to say, "We are creating an agile organization and that means everything changes." That's really what we need because then the people can see that and see the urgency of that.
Your Leadership Journey: A Framework for Creating Agile Organizations
What do you do with all this? I want to give you a leadership framework for creating your agile organization.
Step 1: Recognize That You're Not Just Transforming, You're Creating
You have to shift your mental model. You're not just rolling out Scrum, you're not just scaling agile. You are creating an agile organization.
What does that mean practically?
- You're creating organizations that operate in a "far from equilibrium" condition
- You're going to constantly be adapting and evolving
- You're creating self-organizing teams that are supported by organizational systems that enable, not control them
- You're creating a learning organization where continuous improvement is embedded in the very culture—it's not like some mandated thing from management
When you talk about the three elements of this kind of transition that's required, I think about it as:
- Self-organizing teams (or we'll call that autonomy)
- Enabling systems
- Continuous evolution
Mike Cohn writes about this. He says we need leaders who agitate the organization. We want to keep it from settling into equilibrium. And that's your job as a leader. You're not the hero who has all the answers. You're basically the gardener who is creating the conditions where good things can grow.
Step 2: Name the Organizational Gravity and Get Commitment to Break It
Organizational gravity is whatever formed your organization into its current shape, what's pulling you back every time you try to do changes like this.
What I'd like you to do is start listing what are the organizational gravity elements:
- Is it annual performance reviews that reward individuals?
- Is it budget cycles that don't align with iterative delivery?
- Is it facilities that prevent co-location or coordination?
- Is it finance that needs these phase gates?
- Is it operations that measure utilization over flow?
- Is it promotion systems that favor technical heroes over collaborative leaders?
You name it, you write it down, take it to the executive team. Because here's the truth: you really can't fix organizational gravity from the middle. You need executive sponsorship and teams on the ground that are willing to push back on it.
As Primavera writes in their case study: adopting agile requires an executive's sincere support. It can be a bumpy ride until things settle down. So we need sincere support, and having executive support lets the learning take hold despite the many problems and features that can arise.
You don't want just a checkbook-only commitment from a sponsor. That's one of the most likely reasons your transformation will fail. Leaders must personally be engaged rather than just engaging others.
Step 3: Create Your Enterprise Transition Community
Mike Cohn writes in Succeeding with Agile that we need an enterprise transition community. You can't do this alone. You can call it whatever you want. Jeff Sutherland calls it an executive action team (or EAT), but it's basically a group of working agents from across the organization that meet in sprints—yes, they practice scrum too—that drive the transformation.
It's not a steering committee that meets quarterly. It's a working group that commits to specific work each sprint, demonstrating progress at sprint reviews and retrospectives that adapt their approach, ignite interest, and provide air cover—as I like to call it—for teams.
These improvement communities will be spun up based on what our top problems are. You can't solve all problems at one time, so you got to prioritize them. The ETC (or whatever you call it) needs a sponsor who participates—not someone who just initiated the change and walked away. Someone who shows up, removes barriers, and demonstrates commitment.
Step 4: Redesign Your Control Systems—Don't Just Work Around Them
Most transformations fail when they try to work around the existing control systems instead of redesigning them.
I find that:
- You can't have individual performance reviews and team-level accountability—you have to redesign those things
- You can't have phased gate funding for initiatives and iterative delivery—you have to redesign how finance approves the work
- You can't measure operations on utilization and optimize for flow—you have to redesign what you measure
This is where leadership I think is absolutely essential. Because the people who run those systems—they're not bad people. They're good people trying to do the right thing. But they're running systems that were designed for a different world, and they basically need leaders who say, "We're designing these systems to support the organization we're creating. We have to redesign them."
Step 5: Focus on Value Streams, Not Hierarchies
We want to stop managing people and start managing the work. Value stream mapping is one of the best tools we can use. Where are the delays? Where does work sit in queues waiting? Those queues are where the value is going to die.
This isn't about going faster, it's about eliminating waste and delay—being more effective. It's about shifting from "everyone is busy" to "value is flowing."
Notice that optimizing a value stream requires you to work across all of these functions:
- HR has to help people develop skills that support flow
- Finance has to enable fast decisions
- Operations has to deploy quickly or, better yet, let the people building the product deploy
You're creating an organization aligned around value delivery and functional excellence.
Keep the Organization Far From Equilibrium
We want to keep the organization on its toes, far from equilibrium. Organizations that operate like that are better suited for continuous change. An organization that is in equilibrium will resist change.
Leaders keep organizations on their toes by introducing variation, defining clear performance standards, and creating the conditions for evaluation. You can alter the containers (how teams are structured), you can amplify differences and make work great, and you can transform exchanges as well. That's what we call the containers, differences, and exchanges from Glenda Eoyang.
A lot of times leaders are worried about how do we manage and get to the point where we can have self-organizing teams without managers interfering? It's the containers, differences, and exchanges that we can subtly influence for the teams as we go forward. You're not specifying behavior in advance. You're kind of guiding the evolution of those behaviors that emerge from those self-organizing teams.
And that's what creating an agile organization looks like.
In Closing: This Is Fundamentally a Leadership Challenge
As we wrap up—we talked about a lot of stuff, but we're going to kind of dive into it for the week—I want you to remember that creating an agile organization is not about what happens in IT. It's about what happens everywhere, even around it.
You can have the most well-functioning Scrum teams in the world, but if HR is still rewarding individual heroics, if finance is still operating on annual budgets and phase gates, if operations still measure success by utilization rates and handle deployments—that organizational gravity will pull you right back where you started. And I see it all of the time.
This is fundamentally a leadership challenge, not a process problem, not a training problem. You're asking people to abandon the control systems that have shaped their entire careers, systems that have made sense in a world of predictability, stability, and low variance. And you're asking them to embrace a far-from-equilibrium condition, self-organization, and continuous evolution. They won't do that without leaders who focus on that.
Organizations that figure this out are not just faster or more productive—they're creating organizations where people want to work. And that's important as well. We want learning to be continuous. We want focus to be on creating value, not looking busy. We want to create organizations that can respond, that can evolve, and can thrive in uncertainty.
My Challenge to You
If you're a leader, recognize that this is your work. You can't delegate creating an agile organization. You have to redesign the systems. You have to keep the organization on its toes, and you have to personally demonstrate what that agility looks like.
If you're not in a leadership role yet, find a leader who gets this. Help them see the cost of organizational gravity. Help them see the cost of hidden inventory and understand what could be possible. Be part of the enterprise transition community that ignites change.
This week: Identify one control system—just one—that's creating friction. Schedule a conversation with a person who owns that system, not to tell them what they're doing wrong (you'll get defensiveness real quick), but to understand their constraints and to explore how you might redesign it together.
Because creating an agile organization isn't about IT transforming and dragging everyone else along. It's about the entire organization learning together and how to sense and respond to change.
Ready to Transform Your Organization?
That's what we do at Big Agile. We help leaders create agile organizations. If you need help with that, we have classes that teach you to think of agility as the operating system—it's not just what your developers do.
Explore Big Agile's classes and training offerings to learn how you can lead your organization through this transformation.
If you found this helpful, hit that subscribe button and drop a comment about which control system creates the most friction in your organization. I hope to see you next time or on one of our many outlets at Big Agile.
Remember: you're not transforming, you're creating. And that requires leadership.