The first post was about scaling functions to working as collaborative agile teams. See Defining “Scaling” Agile, Part 1: Creating Cross-Functional Teams. Now, let’s talk about moving to multiple teams working together, a program. The good news is that you have a few cross-functional teams. They’ve been delivering as project teams. And, now you have a […]
In more traditional projects, PMI has a notion that you can “control” a project. I have never found that to be true. Of course, I never quite used a waterfall approach—I have used feature-driven approaches more often than I used a serial approach. Instead of “control,” I like to think about guiding or steering a
Culture is a combination of three things: how people treat each other, what people can discuss, and what the organization rewards. Team 1 has a project manager who believes in collaboration. She encourages people to move work across the board, regardless of how many people it takes to finish a story. The team members joke
In our projects, we solve problems all the time. We might solve customer problems—how to make this feature work the right way. We might solve project problems—how to get to continuous integration or how to build enough and the right kind of test automation to make it easier to release. We even solve so-called people
It seems as if the larger the agile program, the bigger the planning. Many organizations try to plan for an entire quarter at a time. They bring everyone on the program together in a large room (often a hotel ballroom) and attempt to plan the next quarter’s work. That kind of planning works for some
One of my colleagues wants to standardize all his agile teams on one process. He happens to like iterations, so he wants everyone to use two-week iterations. He wants them to use Scrum rituals and ceremonies. I understand what he wants to accomplish: gaining the ability to look across the projects and see the same
What does “scaling agile” mean to you? For me, there are two ways to think about scaling: one is moving from one project to a program. The other is sharing agile across the business. Let’s talk about moving from a one-team project to agile programs. A program consists of several projects across the organization. While
Impediments will occur on any project; agile projects are no exception to risks. Agile succeeds because you are more likely to see the problem before it becomes a disaster. Two developers got the flu. Your tester has jury duty. The team can’t figure out what the design should be for a specific feature and it’s
It seems as if everyone is talking about “scaling” agile. What they mean is a strategic collection of projects with one business deliverable: a program. We don’t have “best” practices for agile program management. However, you might find some reasonable practices help you use agile or lean even better. Think Product, Not System Sometimes, we
Imagine you have a large program, where you have several teams contributing to the success of one business deliverable. You are all trying to achieve a specific date for release. One team is having trouble. Maybe this is their first missed deliverable. Maybe it’s their second. Maybe they have had trouble meeting their deliverables all