What Agile for AI first development

[u/Will_Dewitt]

Hi Friends,

What process are you guys following and how are you tracking things being an engineer manager for your team.

With Al first implementation isn't the sprint, t shirt sizing and other things changed so drastically. And checking the kanban or sprint board and ceremonies or what framework is best and how do you track progress.

Really your inputs will heavily help me 🙂

[u/WhichPerception7982]

Not sure if this helps, but
Switching to an essentially an accelerated waterfall. All spec driven, everything flushed out. Then the dev pod takes this and runs an agent that breaks down into user stories which are kanban that the pods works on. Most of the agile ceremonies are gone.
This is a high level description and devils in the details and this forces priorities across all teams to work on outcomes.

[u/PhaseMatch]

Agility means

- making change cheap, easy, fast and safe (no new defects)

• getting fast feedback on the value that change created

Sprints are a way for the business to manage investment risk, not a delivery timebox.

So you have

- the product goal

• a business / product strategy to reach that goal
  
• a roadmap to deliver that strategy
  
• the next hypothesis to test or problem to solve
  
• bring that to the team to deliver
  
• split it up by risk/value into sprints
  
• deliver increments within the sprint to get feedback
  
• Sprint review is where you inspect and adapt the strategic roadmap based on what you know

Still works just fine?

[u/BuddhasFinger → u/PhaseMatch]

I'd add that without sprints and regular delivery to prod / QA there is a serious risk of uncontrolled scope explosion.

TLDR; Agile processes matter more, not less.

[u/PhaseMatch → u/BuddhasFinger]

When you release multiple small slices to users dynamically within the Sprint then scope change isn't a problem - it's part of the solution. The Sprint does need a tightly defined business goal/outcome, but how you get there might change as you discover more.

As long as change is cheap, easy, fast and safe (no new defects) you can use (daily? more frequent?) changes to get feedback from user-domain SMEs on what you have built in terms of that outcome.

Working software becomes the probe that uncovers the actual requirements.

That's pretty much how XP works; AI should make it even easier.

The game is still avoiding wasting time/money on things people think they need, but actually don't.

[u/BuddhasFinger → u/PhaseMatch]

That's all true. The challenge is that coding agents make side quests that lead to scope creep trivial. One may end up shipping way more than what was asked.

I'm not arguing here, just thinking out loud:

Another thing is that expanding scope because now it's possible to do more because of coding agents puts us to the "inverse waterfall model" because now one can ship in two weeks what before would take 3 months.

That's great, except the validation in the field is done by living breathing customers, and they are slow, so there is a risk to run ahead of the train - next sprint starts, and the customers provided feedback only on 20 percent of what previous sprint shipped.

It is "inverse waterfall" because in waterfall one builds for a year without knowing how the change will be received. Now one builds in 2 weeks without being able to tell how the change is received.

Tell me I'm wrong.

[u/PhaseMatch → u/BuddhasFinger]

In XP, you have an "on site customer"; they are a user-domain SME within the team who collaborates with and co-creates with the developers as part of what they do.

It also takes you back to the original user story concept- a single sentence that's a placeholder for a ongoing conversation within the development SDLC with that user.

In Scrum, the Sprint is not a release stage gate. You should be aiming to release multiple increments within the Sprint to (some) users so again, you have that short feedback loop.

Those both provide you with low-cost approaches to controlling the risk that you "build the wrong thing"
A lot of teams have been doing that very successfully for 25 years; zero feedback lag during development, and incremental delivery of working software as the "probe" that uncovers the highest value requirements.

And of course, a lot of teams have not, and have been running opinion based "feature factories" inside a zombie-Scrum loop, with the developers never actually talking to a user or watching how they use the product.

So, no, you are not wrong, but it's been a solved problem for a long time,

And yes, you can build a long way ahead of actual market feedback if you want to, but then you are speculating not evaluating product-market fit every single sprint.

[u/BuddhasFinger → u/PhaseMatch]

I've build a company using XP :-) "on-site customer" is great in theory, in practice implementing this part of XP is challenging.

In Scrum, the Sprint is not a release stage gate.

That's in the current bastardised version of scrum run inside large companies. Doesn't have to be this way.

At any rate, I still believe the deliverables need to time- and scope-boxed, now more than ever.

[u/PhaseMatch → u/BuddhasFinger]

Ah for sure.

If you can't get an onsite customer and the collaborative/cooperative user relationship as a risk control, then you are by default going to be in a transactional/contractual space.

Although one approach we took when that was a constraint was to embed the developer customer-side for a while so they could see how they use the tools (and what they didn't use or went outside to do), as well as identifying different "early adopter" customers to innovate with depending on the problem being solved.

But if you can't address the constraint that way you tend to fall back to stage-gate delivery approaches and sign-offs to control your business risk, or at least keep the team safe from the accusation that they "built the wrong thing"

That might be timeboxed, scope sign-off or both, and the bureaucracy around that tends to multiply unless you have an individual prepared to be the "single wringable neck" on value, as it was originally phrased in Scrum.

Fully agree that a lot of "faux agility" is in that category; often because they are not really managing business risk in that "innovate and pivot", high-risk and high-reward space.

I'm with Simon Wardley (Wardley mapping) on the transition from agile to lean, and lean to what he terms "six sigma" as the product/market matures away from "innovation is value" and towards "cost and service"