Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASAOriginally published on yuvalyeret.com.It's time to rethink your ways of working, not get rid of themEvery week, I have several conversations with leaders whose teams are implementing an AI harness, adopting spec-driven development, and starting conversations about throwing agile ways of working out the door and getting rid of Jira. Because an agentic software development lifecycle supposedly flattens the work. Individuals do the work of teams. Teams can do the work of entire organizations. So it's very tempting to get rid of all these "heavy" large-scale agile processes.In this article I examine why these scaled processes exist in the first place, what problem they were there to solve, and the conditions in which you can indeed "descale" your ways of working.Why did we need scaling mechanisms in the first place?Instead of descaling everything, what I invite you to do is go back to the first principles. Why did you have all of these scaling mechanisms?The scaling mechanisms were a choice. Coordination overhead that was hopefully worth it at the time, because of a coordination problem you hopefully have.What actually changes with agentic engineeringAI might have changed something about your coordination problem. There's probably work that individual people can now do without coordination. There's work the teams can do on their own, with minimal coordination with other teams. There's work the teams of teams can do that in the past required coordination across portfolios.This change in the cost of coordination makes it interesting to look at our choices regarding coordination mechanisms.There's still value in a lot of the elements of a scaling framework, but done at a different altitude. Instead of PI planning in detailed stories, outcome planning, talking about OKRs. Instead of managing stories in the sprint, managing features.And the honest counterweight, because the hype runs the other way: there are human aspects that this whole AI-first push is kind of ignoring. Maybe it's because people want to get rid of product owners and scrum masters. Maybe there's politics to flattening the organization this way. But I'm not sure you need to change the team structure.What I'm seeing when teams over-read thatA few patterns keep coming up. Teams shipping a ton of features, but activation or retention doesn't move. Multiple teams building overlapping capabilities because each one optimized locally. A critical domain expert not in the loop, and the agents crank out something technically fine but strategically off.The deeper expensive problem is false confidence. Leaders feel good because every local dashboard is green, but the system as a whole is drifting.So the question becomes: what evidence do we have that our increased output is translating into customer value? That's the grounding that resonates with executives far more than the cadence itself.And the other thing happens too. In some organizations, the technology organization is sick of Jira, is sick of Agile, and they're just using AI as an excuse to just do whatever they want.Where should humans be in the loop: in the flow, or on a cadence?What are some ways for humans to be in the loop? One way is to be inside the flow, inside the definition of workflow. A feature gets to spec-ready. That's an opportunity for humans to be in the loop. Another is to come visit the gemba, where the work is happening, on a cadence: look at everything and where it's at, and provide feedback.There's an interesting question, though. If the pace of AI progress is so amazing, if AI is progressing its work on features at 10x speed, is it actually effective to visit such a process every two weeks? Or is it way too late?I see a couple of scenarios. One is that the work will stay pending the human judgment stage until we get to that cadence. If I'm working with a spec-driven lifecycle, AI writes specs for features, but we're saying we want humans in the loop, then the features stay there until we bring the humans together. Assume the humans come together every two weeks. We will probably start to see big staircases in the cumulative flow diagram. We will start to see batching, and flow times where flow efficiency is dramatically lower, because we're waiting.If we decide we're meeting every day, the flow efficiency will be higher. But it might be a very different coordination cost to get all of the people together. So that's a legitimate trade-off.And the question is how you scale this. How can you shift some of the judgment that happens on a cadence to happen in a flow system? Can you minimize the reliance on events and shift it into the flow? I think that's one of the attractions of shifting to Kanban and flow from cadence-driven systems.Before you drop the cadenceBut before we jump too quickly to flow and drop the cadence, this dynamic makes me recall a story that Donald Reinertsen shares about the blind person on a roof.The fact that you can have a structured opportunity to nudge them back towards the right place is a much better way to de-risk them going off the path and off the roof than a scope-based gate would be. They might spend too much time in each one. They might get stuck.Real features, not green onesThere's an insurance company that dropped all of its agile practices and created small teams that can each deliver features. But those features, when you dive deep into it, are not really valuable features. They're not really minimally marketable features. Even if the team says the feature is green and integrated, there isn't marketable value.That points to an important practice, which is real features. I don't care whether you're using stories or whatever. You should manage real features, you should manage the flow of those features, and you should recognize when you have features that are unvalidated, that are not integrated with each other, that just cannot work on their own.Now assume you're past that. You're working with minimally marketable features, and each one, when the team moves it to green, is technically integrated with the others and doesn't break things. That's one of the patterns the System Demo addresses. You could argue that if you have true continuous integration, you don't need the System Demo to prove or protect against technical breakdowns.But what you might be missing is the opportunity to apply human judgment to the feature mix that is in flight. How these features create a better product together. How the whole customer journey is affected and evolved. How the whole narrative is shaping up. How are we enabling people to actually do their job better?Those are the questions we need to think about frequently, because of the cost of delayed feedback. The cost of finding out that features don't work well together, that they don't make sense, is amplified dramatically the farther you get away from the point of introducing them.The half of the review that looks forwardThe other piece people rarely talk about in the context of a System Demo is what we talk about in Scrum's Sprint Review: looking forward rather than just looking back.Let's look at what's in the backlog, let's look at the features that are ready, and apply the same judgment about cohesion. What evidence do we have. Where are we going. What's the hypothesis, and what's the conviction level on desirability and feasibility. Are we approaching it effectively? Do we need to discover before we build, or is discovery a waste of time here? Are we considering the right perspectives?At least in a reality where we still need the diverse perspectives of different humans as part of the process, where AI doesn't have all of the context it needs, where it isn't even an internal AGI, we still need to do that in some way.We could do it for each feature. Or we could do it in a continuous flow. But there's a coordination cost to doing it per feature, and that's exactly why a lot of organizations decide it makes sense to create a placeholder for these conversations on a cadence.Flow or batch, and what each one costs youWhen we're thinking about the choice between running a process in the flow for each feature, or waiting and doing it for several features in one bigger batch, we need to be thinking about the trade-off.When you're doing things in the flow, you don't have to wait as much, and you might not have these cadence meetings that feel forced if there's nothing interesting going on. But it's also more expensive from a coordination perspective to get these continuous meetings happening. People are busy. Getting them together to work on something when it's not on their schedule is hard.Now, it could be that you managed to change everybody's schedule to a schedule where it's much easier for people to just huddle together when they need to. If that's the case, move towards continuous flow.But if you're still in what is called the manager's schedule, everybody's calendar is still full, loaded with a lot of meetings, and it's still hard to get people together for something. And you find that you're paying the price of a lot of time spent on coordinating meetings, or missing key stakeholders whose judgment and perspective you want to have, because you're moving to continuous flow. Then the trade-off might not be worth it.So think about it. Experiment with it. Try it multiple times and see what you're getting from moving to continuous flow. What are you sacrificing? Is the sacrifice worth it?Monday morningPick one event, one board, or one role you still run. Name the coordination problem it was bought to solve, then ask whether you still have that problem. Most people find one or two answers they don't like. If you try that and something surprising falls out, tell me about it.If you would rather have an agent walk you through it against your real mechanisms, I packaged this diagnosis as a skill you can install, free and CC BY.It's not that the physics of coordination and coordination overhead and batch sizes has changed. AI hasn't changed the physics. But it's like going to a planet with different gravity. There's still gravity, it's just different, so you need to adjust how you walk, how you move.These are the guiding principles I use when working with organizations on reimagining their ways of working for the AI age, while still respecting the physics of product development flow.Yuval Yeret helps product and technology leaders move from agile theater to evidence-informed, outcome-oriented delivery. He's shaped the agility path of dozens of organizations and influenced the frameworks used across the industry.More insights on yuvalyeret.com →
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | AI Made Engineering Faster. Why Not The Business? | 0 | 6.62 | 28-09-2026 |
| 2 | From Deployed to Actually Used: The Lane Most Boards Are Missing | 0 | 5.83 | 24-09-2026 |
| 3 | The New SDLC From Google Has a Harness. It Doesn't Have a Team. | 0 | 14.4 | 30-09-2026 |
| 4 | AI Changed the Bottleneck. Your WIP Limits Should Change With It. | 0 | 10.22 | 08-09-2026 |
| 5 | How Next Insurance Broke Its Whole Lifecycle Into Agent Skills | 0 | 7.82 | 24-09-2026 |
| 6 | AI Transformations And Agile Transformations Rhyme | 0 | 7.34 | 06-09-2026 |
| 7 | Is Your Agent Harness Still Learning? Check Its Last Updated Time. | 0 | 6.5 | 10-09-2026 |
| 8 | AI on Top of a Dysfunctional System (1): The Product Backlog | 0 | 5.29 | 20-09-2026 |
| 9 | Scaling Product Orgs with Portfolio Agility | 0 | 7.52 | 17-09-2026 |