How do you know when you finished a feature? You might have a checklist, to make sure multiple people looked at all the artifacts, and that everything is checked in. (This is easier if you work as a mob/ensemble, pair, or swarm.) In addition, a product leader might approve the feature. Finally, the team, a […]
In product development, we often use the words, “user” and “customer” interchangeably. But they mean different things depending on the type of product you create. I wonder if it’s time to stop talking about “customers” altogether. It’s time to clarify who we want to satisfy, so we can make better product decisions. Here are my
I spoke with a project manager recently. She told me her story. I used to facilitate project teams as a project manager. Why a project manager? Because the project had a beginning and an end. We had (and still have) too many products to keep the same teams on them for a long time. For
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
I have a new column up on projectmanagement.com, 3 Questions to Ask Before Estimating an Agile Program. Often, management wants an estimate for the program. I suggest that before a program manager ask the teams to estimate, she learn the answers to these questions from management: How much would you like to invest in time,
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
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
Create an Environment of Delivery One of the nice things about agile and lean approaches is that they focus on delivering value. I’m a huge fan of delivering value. The larger and longer your project or program, the more delivering value is important. That’s because your organization is investing in your project or program. They