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
Own Your Leadership, Part 2 In Own Your Leadership Part 1: Dave and Sherry collaborated on seeing if the team could deliver one feature at a time, to improve the team’s throughput and quality. They had mixed success. The first story took them three full days, instead of their anticipated one day. All the other
One of the things I like about agile is the fact that it encourages me to learn. I wish I were perfect, able to learn things as soon as I try them. However, I am all too human. It takes me time to learn. I just upgraded one of my text-processing programs, and now about
A reader asked me this question: “How do I report on the 1000 (or so) defects in our system? I have 10 minutes on the status call.” If you are working on a legacy application where the team was not able—for any number of reasons—to maintain technical excellence, you might have a problem like this. So
As I’m writing the agile project management book, I’m explaining how agile creates and manages WIP (Work in Progress) Limits. Iteration-based agile manages WIP by estimating what you can do in an iteration. You might count points. Or, you use my preference, which is to count the (small) stories. If you use flow-based approaches, you use kanban.
If you are wondering, “What do I do with the work I said no to?” here’s the answer. Use a parking lot. This is the image from Manage Your Project Portfolio. I recommend just four columns: the project name, the date you put the project on the list, any notes about value, and any other
My most recent post about how to Visualize Your Work So You Can Say No showing a couple of different kanbans was quite popular. Several people ask me how I use my personal kanban. I use paper. Here’s why I don’t use a tool: I am too likely to put too much into a tool.