Continuing the series on dependencies… Maybe you don’t have the problem where the team creates internal dependencies with their process. And you don’t have to wait for someone outside the team to approve your work—an organizational process. But you do have a combination of platform/component teams and feature teams. I see this most often in […]
Did you ever work on a project that dragged on and on, slipping a week every week? Back in the day, we called those projects “death marches.” I never saw anyone literally die, but I saw too many divorces, abuse of drugs and alcohol, and very dissatisfied and unhappy employees and customers. Waterfall projects can
Many people talk about “going back to normal.” We aren’t going to return to normal. That old normal is gone, at least for a year, if not longer. (I suspect we will cycle between remote work and office work for the foreseeable future.) What we can do is discover a new normal. Discovery requires different
Many of my clients feel stuck with their component teams. They feel they must implement across the architecture, not through it. That’s because the people are organized in component teams. As the organization grows, so does the number of component teams. The more component teams they have, the more complexity they create in the teams, in
At the Influential Agile Leader workshop earlier this year, I led a session about scaling and how you might think about it. I introduced the topic and explained that “scaling” might not be the answer. My experience is that when people use frameworks for larger efforts, they experience these unexpected side effects: The framework actions
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