Let's assume that your team does have a definition of Ready. And that they (possibly with a product leader) have shaped the work. But the team still says they don't know how to start—they don't have the right people to think through the problem and finish it.
If you have component teams, the team is exactly right. They are not one cross-functional team that can take work off the backlog and deliver it. (Since this is often a problem with larger efforts, read See and Resolve Team Dependencies, Part 4: All Component Teams, Complex Product for more issues with component teams.)
But maybe you have just one or two teams working on the product. That's not necessarily a program.
Too many teams feel they have to wait for an outsider to come and rescue them and think through the problem. There's even a word for this in the agile community: a “visitor.”
Visitors Make the Thinking Problem Worse
Too often, managers think a visitor will help the team over its “hump” and allow the team to proceed. That depends on why the team needs an outsider.
- When I wrote Rethinking Component Teams for Flow, I only thought about the problem of “shared services.” But that's just one of the reasons a team might need a visitor.
- A more senior person, such as an architect, has the necessary information that the team needs to solve this problem. (Often, other problems, too.) That senior person cannot delegate the work to the team because the senior person has not taken the time to collaborate with the team. Why? The senior person feels too much pressure to do their current work, not revisit their past work. (See One Secret to Free Yourself from the Overwhelm of Leadership Work for this very problem.)
- Someone who did have the knowledge is no longer available to the team. Sometimes, this person moved to another company. Other times, they died before they could collaborate with the team. But there is no visitor who can help this team. The team has to learn together to help themselves.
Visitors, unless they mob with the team, cannot solve this problem. When a visitor works alone and does not collaborate with the team, the visitor reinforces the team's lack of knowledge.
What can the team do? While I prefer the visitor mob with the team for several days or weeks, that's not always possible.
However, teams often have access to a non-human visitor—their favorite AI/LLM tool.
LLMs Can Be Visitors in the Form of a Thinking Partner
I remain skeptical of LLMs to do useful programming work on their own. However, an LLM might be able to explain the code to the team, help create tests to support changes, and help the team learn how to start on a backlog item that remains unclear.
Notice all the “might” and “help” words in that sentence.
Effective software development can only occur when the team understands what they need to do (that's the Ready and Shaping part of the backlog). The team also needs to understand the decisions others previously made.
If there are no or insufficient tests, maybe your team can use the LLM as a thinking partner to make more tests to support changes. Why a partner? Because the team needs to learn how to reason about the product and the code together. That's what a visitor does and what an LLM might be able to do.
Visitors Offer Thinking Support
The best human visitors invite the team to think with them. That's how pools of people in the shared services model can support the teams.
That's how teams can use an LLM.
LLMs are terrific pattern matchers. And they can create small prototypes (hopefully with tests) to test a business idea. That's why an LLM might offer thinking support to a team.
- The LLM might be the rubber duck to discuss the problems with the team.
- Maybe the LLM can create all the tests that the code does not yet have. (I am suspicious of this, but my programming colleagues tell me this is true.)
- And, if the team mobs with the LLM, the LLM might be able to explain its thinking.
I remain skeptical. See the A Little Scree about AI and the Hard Parts of Product Development. However, teams that do not have access to all the necessary skills to start and finish a backlog item need thinking support.
Thinking is Much More Than Coding
Back when I was a programmer, I read much more code than I wrote, especially when I took over a product someone else had implemented. That reading included any of these:
- Sketching how the modules or classes interact.
- Writing tests to test my knowledge.
- Bouncing ideas off other people to see if I understood the problem.
All of this was problem definition and organization. I could use any of these to write prototypes or small changes to test what I had learned.
That's why I say that product development is a form of learning. The faster the team learns this together, as in Measure Cycle Time, Not Velocity, the faster the team can finish. That starts with Ready items that the team can Shape, and then Think together to deliver.
What kind of thinking support does your team need?