I’ve been thinking and experimenting a lot about how to use the various LLMs, both in my work and with my clients. I keep seeing a familiar trap: that managers think the gating factor in product development is the speed of coding. But that’s not true. The gating factor is the speed of understanding the […]
I said earlier in this series that no one cares about how “agile” your team is. Or the kind of “agile” your team professess to be. Managers do care about agility: the ability to respond quickly to a changing or changed environment. And that depends on where your team has delays. That’s why value stream
In Part 1, I wrote about what the value stream map looked like for expert-focused “cross-functional” teams. In Part 2, I discussed cooperative teams that have working agreements on when to do code review or make other decisions as a team. While those teams exhibit somewhat more agility, cooperative teams are still not collaborative. So
In Part 1, I wrote about what the value stream map looked like for expert-focused “cross-functional” teams. While those teams are cross-functional, they are not collaborative. However, these expertise-focused “teams” are not the only type of non-collaborative agile teams. There are also cooperative teams. Cooperative teams still tend to work sequentially, focused on each person’s
We talk about cross-functional agile “teams” as if they are the norm. That’s what I show in this image: some responsible person creates a ranked backlog that the cross-functional, collaborative team works on. That team delivers increments of value on a regular basis. At some point, the team will demo their work and retrospect on
Maybe your team does have Ready criteria for their backlog. But they look at the backlog item, and they say, “Oh, this is way too big. We have no idea how to start.” That “no idea” often means the work is too large, unclear, or not based on a specific customer with a specific need.
Summary: It is unfortunate that the department attending to employees is called “Human Resources.” That language colors what managers call people in the organization. But the more you call people “resources,” the more they become interchangeable—and more like desks, or infrastructure, or something that is easily negotiable. Resources are not people. People are not resources.
I write a twice-yearly column for Better Software magazine. The title of the column is called “Technically Speaking.” For this column, I decide to tackle the question of “What’s a Professional?” If you don’t already subscribe to the magazine, you do have to join the site. It’s a free registration to join.