We might start to think about agile approaches as a project change. However, if you want to “scale” agile, the entire culture changes. Here is a list of the series and how everything changes the organization’s culture:
- Defining “Scaling” Agile, Part 1: Creating Cross-Functional Feature Teams. Without feature teams, I don’t see how you can have the necessary collaboration for agile approaches to succeed. This is the beginning of moving from functional silos to product delivery.
- Defining “Scaling” Agile, Part 2: Program Management for Product Development. Program teams allow you to move from projects to programs with just enough organization. This is the extension of moving from small silos to involving much more of the organization to deliver value in the form of products.
- Defining “Scaling” Agile, Part 3: Creating Agile Product Development Capabilities. Adaptive and iterative planning at multiple levels provides the organization the ability to commit for now and not forever. This creates the beginning of a resilient organization.
- Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development. Workgroups require a different way to think about agile approaches. Once workgroups realize how they contribute to the rest of the organization, they provide the organization the ability to deliver value more often.
- Defining “Scaling” Agile, Part 4A: Sharing Agile Outside of Product Development. Different workgroups require different approaches.
- Defining “Scaling” Agile, Part 5: Agile Management. Management creates and nurtures a culture of collaboration and optimizing “up” wherever possible. Moving from resource efficiency (and finances) to flow efficiency has the possibility of changing everything. Managers hold the keys to creating a resilient organization.
All of these “scaling” ideas require change.
Agile organizations become very good at small changes all the time. They are adaptive and resilient. They understand how change works and they embrace it. (Big changes are quite difficult for almost everyone. Small changes tend to be much easier.)
Here is a picture of the Satir change model. We start off in Old Status Quo with some level of performance. Some Foreign Element arrives and we have uneven performance while we are in Chaos, searching for that Transforming Idea. We discover that TI and practice and integrate that idea into our work until we reach a New Status Quo, hopefully at a higher level of performance.
The change model works for each human and for the entire organization. In fact, I don’t see how you can have an agile organization until people become comfortable with small and large changes on a regular basis. This is one of the reasons I say we should take an agile approach to agile. (See Agile is Not a Silver Bullet.)
Do you need to be a fully adaptive and resilient organization? Only you can answer that question. Maybe you start from teams and the project portfolio. Maybe you look for incentives that don’t create optimization “up.” (I need a new word for this! Do you have suggestions for me?? Please comment if so.)
You do not have to have a fully agile organization to recognize benefits at the team and project portfolio levels. Agile is Not for Everyone.
Decide how much change your organization needs to be successful. Practice change, as often as you can. That will help you more than an agile label will.
One last comment: I’m not sure “scaling” is the right way to think about this. For me, the scaling idea still has roots in silo thinking, not flow thinking. That could be just me. (Grin!) I wish I had a better way to explain it.
My ideas of scaling agile are about creating a culture based on our ability to change:
- How do we treat each other? Do we/can we see each other as an intrinsic part of a whole?
- What do we discuss? Do we discuss “failures” or learning opportunities?
- What do we reward? How do we move to rewarding non-silo work? That is, work to deliver products (in either projects or programs) or other work that rewards collaboration and flow efficiency.
I hope you enjoyed this series. Please do comment on any of the posts. I am curious about what you think. I will learn from your comments.
| Reference: | Defining “Scaling” Agile, Part 6: Creating the Agile Organization from our JCG partner Johanna Rothman at the Managing Product Development blog. |
