sprints

Introduction

Note: this is not meant to be rage-bait and I am not seeking correction on "that's not Agile".

I propose a change to the "normal" methodology engineering in organisations, where my observations are around "use of agile". I talk about what I believe is the inheritor of kanban and scrum, and I will just call it agile. I won't write an ode to the manifesto nor talk about the origins of car manufacturing processes to assert my bona fides as I just want to get to the point.

Agility is - the ability to react to change - the continual refinement and iteration of how you deliver things with others

Achieved through - effective communication - agreed, clear goals and effective planning

Proposal

• No more sprints.
• Just features on a backlog
• Owned by the person who pays the bills (the Product Owner)

The advent of agentic engineering I believe means sprints are now outdated and have served their time. Thank you, and good-bye!. And guess what, being agile permits me to experiment with other humans on what works and what does not. No big deal.

The new sequence

Note: all stages are a mix of a human and agent(s)

1. Refinement

• The PO describes with Engineers the features, in a backlog.
• Features are Refined until they meet some DoR, cost estimate.
• PO agrees with Engineers a named human who will be figurehead for the delivery of the feature.

Note: where the feature is an engineering feature, it follows the same process

2. Prioritisation

• The PO and Engineer agree the prioritisation of the features. In most cases the PO holds the veto where the Engineer will inform the common-sense cost of prioritisation.
• The backlog is physically ordered
• The features to be worked on are then collected into what looks like a sprint, but is not time-bound - it's just a container of features.

3. Implementation

• The Engineer implements the features.

4. Review

• The squad demo all features to the PO
• The PO accepts the feature

5. Release/Repeat

• They loop until the feature is consistent. Meaning adheres to a DoR, SDLC, has a valid reason for existing.

• Engineers implement the feature.

• PO accepts the outcome

• There is no more story pointing, or planning poker.

• There is no daily standup other than the one the team need.

Team Size

Engineering squads should drop to a smidge above the bus factor, so - three humans.

We end up with 2x or 3x squads from what we had before, enabling "do more with same", or "do same with less". We will shift or grow cost towards tokens.

Powered by

A software factory. A common engineering process that yields the software outcome of the feature. The reailty is the SF is like an F-117a or F1 car - neither work without a team of engineers that make them into a PLane or Car seconds before they take off. When they are static, they are useless lumps of material. Same with engineering.

Some conundrums

Jnr Engineers (and other non-junior humans) need the company of others. Therefore the burden of leadership requires that the Engineering Manager needs to effectively manage the team.

There is a conundrum which is we do need to estimate, so there is some form of story pointing - however the implementation should not be considered a multi-week concept anymore, rather it should be agents chirning for hours/days.

In the aggregate this does add up to weeks, but the sprint concept ahs had its time. It is no longer necessary.

This means the tempo goes

• backlog review (outcome is prioritisation and blessing of features, setting expectations on when they will deliver)
• specific feature meetings (for clarification and blessing)
• engineering of the feature
• demos of the features
• repeat
• periodic retrospectives - either after any feature or after n features or every n weeks if none have occurred.

that's it.