Years ago, Roy Osherove interviewed me about project management, agile thinking, hiring, and management. We had a great conversation. (See Roy’s Archived Interviews page for my interviews with him.) I just listened to some of the questions and answers. If you are not sure about effective management, listen to the interviews. After a nudge from […]
Many organizations want to see an estimate for your program (a collection of projects with one business deliverable) before they fund it. So, the teams might spend significant time estimating everything the product owners and managers hope will be in the product from today’s perspective. Or, you might try a “sprint zero” to understand the
Program sponsors and the teams themselves want to know where they are in the program. What’s started? What’s not? How much more remains? It’s tempting to measure “everything.” That creates another problem: You might spend too much time attempting to gather data that doesn’t provide enough information. You might even miss seeing the real progress
The nice folks at Planisware organized a webinar with me, called Scaling Agile. They recorded that, and you can hear the video here: Scaling Agile with Johanna Rothman. We spoke a lot about Agile and Lean Program Management. I referred to my multiple part series about Defining “Scaling” Agile. If you are thinking about “scaling”
I spoke with a potential client the other day. He said, “I want all the teams to use Scrum, and I want it yesterday!” Okay. I asked him, “Are the teams all collocated and cross-functional, with all the capabilities and roles they need to finish work?” “Almost all of them.” I asked, “Do the teams
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