This is part of a series of posts where I take a look at some commonly asked questions and provide my spin on them. The answers are all my own. So while my answers do not necessarily reflect the policy or positions of Agile Alliance, I’ll point to some relevant resources on AgileAlliance.org that either support my perspective or provide a different perspective.
Are we at the point now where we can fairly apply the Agile mindset and related frameworks to all things business, software development or not, and if so to what extent?
The short answer is yes.
Here’s a bit more in depth answer:
There are a lot of people exploring how to get the ideas embodied in Agile software development outside of software development and IT. Most of these explorations fall under the label Business Agility.
These explorations tend to take one of two forms:
- How people in other parts of the organization need to adopt an Agile mindset in order for software development efforts, and in turn the entire organization, to become more effective
- How other parts of the organization can adopt Agile frameworks (ie Scrum) and practices (such as timeboxed iterations, standups, retrospectives)
Agile Alliance started the Business Agility webinar series to share some of these explorations with the community and had sessions at Agile2017 and Agile2018 about Agile Companies.
Spread the Mindset to the Organization
The first form, helping people in other parts of the organization adopt an Agile mindset, is the one I recommend. It’s been necessary since teams have started working in an Agile fashion and it was implied in the Agile Manifesto authors’ thoughts back in 2001. Jim Highsmith hints at this influence in his write-up on the Agile Manifesto site History: The Agile Manifesto:
But while the Manifesto provides some specific ideas, there is a deeper theme that drives many, but not all, to be sure, members of the Alliance. At the close of the two-day meeting, Bob Martin joked that he was about to make a “mushy” statement. But while tinged with humor, few disagreed with Bob’s sentiments — that we all felt privileged to work with a group of people who held a set of compatible values, a set of values based on trust and respect for each other and promoting organizational models based on people, collaboration, and building the types of organizational communities in which we would want to work. At the core, I believe Agile Methodologists are really about “mushy” stuff — about delivering good products to customers by operating in an environment that does more than talk about “people as our most important asset” but actually “acts” as if people were the most important, and lose the word “asset”. So in the final analysis, the meteoric rise of interest in — and sometimes tremendous criticism of — Agile Methodologies is about the mushy stuff of values and culture.
The ideas embodied in the above excerpt are certainly applicable outside of software. I know I’d want any organization that I worked with to exhibit those behaviors. So I think spreading an Agile mindset outside of the organization is a good thing to do.
One of the key places where spreading the Agile mindset into the rest of the organization is helpful is the decision making about what stuff you’re working on and what stuff you’re not working on. In product development, that’s the realm of product management. In IT, it’s the realm of portfolio management.
Spread Frameworks and Practices to the Organization
If you want a truly cross-functional team, it makes complete sense to share practices and frameworks with everyone involved with product development efforts. You want to make sure everyone on the team understands and agrees to the the conventions you agreed to follow when you work together. That’s your team’s methodology. You introduce the frameworks and practices for the purpose of helping everyone to learn how to work with each other.
You’ll want to get everyone up to speed on the practices you use to aid collaboration, such as daily stand ups and retrospectives. You may want to make sure everyone on your team is aware of technical practices such as test-driven development, pair programming, or continuous deployment at least to the point of explaining how your stakeholders and users may be impacted by these practices.
What may not be as helpful is introducing Agile software development frameworks and practices to parts of the organization that aren’t directly involved with software development, unless you can apply those practices in their context.
For example, if you have people working in customer support, the nature of their work does not lend itself to planning every two weeks. Their work arrives much to frequently and haphazardly for that. But there may be value in tracking current work on an information radiator and taking some time on a regular basis to identify opportunities for improvement.
It Ultimately Depends on Context
At the end of the day, you need to understand your context when looking to spread Agile beyond software.
Spreading Agile beyond software makes sense if your organization operates in a situation where you need to deal with uncertainty and need to be able to learn and adapt quickly in order to be more effective.
Spreading Agile beyond software makes sense when you need changes to happen in other parts of the organization in order to make your software development efforts more effective.
Spreading Agile beyond software might not make sense if your only reason for doing it is because you think you’ve solved this software thing and you think it would be neat if your accounting department would start doing daily standups.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
