This is the August 2024 Pragmatic Manager Newsletter, from Johanna Rothman. The Unsubscribe link is at the bottom of this email. Problems. They’re always there, just waiting to pop up and say, “Surprise! Gotcha!” I don’t mind new problems, but the sneaky problems, the ones that reappear after I thought I fixed them? I really […]
A potential client called me. “What’s a good tool to see the state of my projects? I need a tool.” I asked, “What problems do you see?” “Everything is late. No one’s synchronized. I can’t tell where the projects are.” “How many projects do you have in progress?” “At least 100.” (I was pretty sure
If you are like most people I know, it doesn’t matter what approach you take to your projects—your manager has too much work for you to do. Instead of a potential career-limiting conversation, frame the conversation so you can show your manager you’re considering his or her perspective. Here are some options for how to
Sprints, by definition, are a timebox. You’re supposed to say, “Pencils down!” at the end of the sprint, show your work and reflect. One of the big problems with new-to-agile teams is their inability to finish work inside a sprint. Each team is unique. However, I’ve seen these causes most often: Team members multitask, so
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