I keep encountering confusion about what scaling agile is. I’m writing what I think is a 4-part series to define it so we all talk about the same thing.
When I ask people to define what they mean by scaling agile, they talk about these possibilities:
- They have agile developers. They want agile testers. This is creating cross-functional agile teams for projects.
- They have had successful one- or two-team agile projects. Now, they’re ready for an agile program.
- They have agile product development (it might be called IT or Engineering or R&D or something else), and they want to share agile approaches across Marketing, Finance, HR.
- They want to build an entirely agile business.
Each of these is different. Each solves a different problem for the organization. This post is about #1: the developers have been agile in their single function team. They want to bring the testers along and create cross-functional teams. (It could be the other way around where the testers are agile, but I haven’t seen that. I have seen testers using iterative and incremental approaches, but often that’s a reaction to the developers.)
I wrote about the problem of staggered iterations in How Long Are Your Iterations, Part 1. When the developers are on a different cadence than the testers, they don’t act like a cross-functional feature team. The “team” isn’t delivering a finished feature. They’re not solving problems like a team. They often have a ton of WIP (Work in Progress). Using iterations does not make a team agile.
On the other hand, if this is where you can start, do start there. The next part in your “scaling” of agile is to move to cross-functional feature teams. That’s where the team works together, in a collaborative fashion, to create finished features. You might do this in iterations, especially if you’ve only heard of Scrum. You might use a kanban board to see all the flow of work through your team and your bottlenecks.
I keep talking about “your team.” Agile approaches use cross-functional teams who focus on delivering features. I’m not big on component teams. That’s because they postpone delivery of finished features. I also hate the idea (and name) of “shared services.” I’ll blog about that later.
You might think, “The developers are agile. We’ll scale agile to the testers.” If that’s the way people think about agile in your organization, maybe that’s the best you can do. Here’s a possible reframe for you:
Scale agile from one function to a cross-functional team.
When you (and your managers) start to think about cross-functional teams rather than functions, you start to realize the benefits of agile.
If you think scaling agile is sharing agile between functional teams, consider reading my upcoming book, Create Your Successful Agile Project. I’m still in editing and then it goes out for review. We expect it will be available in July.
I do have reviewers, but if you are struggling with your agile approach, let me know if you would like to be a reviewer. We might have room for another couple of reviewers.
| Reference: | Defining “Scaling” Agile, Part 1: Creating Cross-Functional Feature Teams from our JCG partner Johanna Rothman at the Managing Product Development blog. |
