There’s a twitter conversation about how to manage team compensation. How can we pay people what they are worth and compensate a team for their value? I know there are teams where I was quite valuable—not because I was “the” leader, but because I helped the team achieve our goals. And, there are teams where I […]
We might start to think about agile approaches as a project change. However, if you want to “scale” agile, the entire culture changes. Here is a list of the series and how everything changes the organization’s culture: Defining “Scaling” Agile, Part 1: Creating Cross-Functional Feature Teams. Without feature teams, I don’t see how you can
One of the challenges I see in organizations is how managers can use agile approaches. One of the biggest problems is that the entire organization is organized for resource efficiency (think silos of functional experts). Agile approaches use flow efficiency. Thinking in flow efficiency changes everything. Many people in organizations believe that dividing up the
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