In Part 1, I wrote about thinking in feature sets and how to quickly create a feature set of—with any luck—smaller features. That’s because features don’t arrive at the same rate and they change in value, during a quarter. Because features change in value and because some feature sets need to deliver value on a more regular […]
Many teams and organizations try to create one-quarter roadmaps. Here are the problems I see: Teams spend a ton of time estimating what they might do and then they select what will fit into a quarter. They feel or are asked to commit to all that work. The product managers and project portfolio managers depend on
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”
Note to my dear readers: As I write, I realize this series is growing. Thank you for your understanding in advance. In Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development, I wrote about an independent workgroup with one stream of work. I used Customer Support as an example. Support has one stream:
Here’s where we are so far in this discussion of what it might mean to “scale” agile approaches: Part 1: Creating Cross-Functional Feature Teams (Teams that can produce features on a regular basis) Part 2: Programs of Cross-Functional Feature Teams (Programs (multiple teams working together) that deliver features on a regular basis) Part 3: Agile Product
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
In the “Scaling” Agile: Part 1, I wrote about cross-functional collaborative teams. The cross-functional collaborative feature team is the basis for “scaling” agile. In “Scaling” Agile, Part 2, I wrote about programs. I realized I need another part before my original part 3 :-). This new part 3 is about creating agile product development capabilities.
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
Understand Your Project Interdependencies Do you have interdependencies in your projects and programs? People on one team need something or someone from another team. Part of the problem is that we use the same word (interdependency) to describe two different problems. Teams can solve sequencing interdependencies. Teams need managers to solve specialist interdependencies. In Sequencing