Larger organisations in particular, whether government or financial institutions, whose operations rely to a large extent on IT and software development, still lean on safe ways of working such as Scrum or SAFe in the age of AI. Product owners and scrum masters have been hired and processes have been set up to make sure work is done according to the established rules, in order to comply with internal or external regulations. As a result, employees are technically enabled by AI, but in practice they can still be stuck in processes, meetings and expectations that keep the focus away from fully using their own knowledge and the possibilities they now have. Things like daily stand-ups, refinements and alignment meetings used to work well because the development process was long. Now they work less and less well.
There are core principles of software development (the so-called laws of software engineering) that dictate that software should be built right the first time. Processes like Scrum are built on that: a refinement is needed to find out what the exact specifications are. That refinement often needs exploratory work or pre-refinements of its own. Then there are alignment meetings meant to remove blockers and adjust course along the way. This structure no longer makes sense when, as a developer, you can set up a proof of concept or implement functionality within minutes by giving an AI an instruction. In fact, giving those instructions often reveals more quickly what the requirements should be and where the blockers are. By letting the software developer stay in control of this whole process (instead of spreading it across a team), you get better knowledge retention among developers. They know exactly why an idea does or does not work because of these exercises, and when something does work, the barrier to implementing it is usually very low.
Development teams usually receive their work from a backlog fed by the organisation and/or from a maintenance and operations perspective. Items on that backlog go stale quickly and take work to write up or keep current. When you develop from an AI mindset and look at possibilities instead of historical requirements, it makes more sense to keep functional descriptions, reasoning and the rest of the administration that comes with changes next to the code, instead of in a separate backlog that requires a lot of manual work in management tooling. The exact form does not matter much. You could keep a changelog in your repository with the things you would normally write in a work item (user stories or Gherkin, for example), so that you can comply with processes that require this kind of documentation where needed. This log also shows what has actually been delivered. Research that was done but never implemented could go in a separate log. By pulling this information out of systems and recording it as plain text, it becomes queryable by AI, and it quickly becomes clear what the status of something is or what should currently take priority. The concept of story points and planning can be dropped, because the human value of that estimate has disappeared. Estimating work therefore does not make much sense anymore.
A Kanban-like way of working with a list of topics can feed the process above. A team is still needed, because knowledge has to be transferred between team members so they can replace each other and validate each other's work. Someone still needs to translate between the organisation and the technical team, a kind of product owner, but a developer can fill that role too. People from the organisation could add their requests directly to the list in the repository with a priority, or have AI determine that priority based on business considerations.
This allows teams to become smaller (less overhead), puts more responsibility on developers, and lets developers position themselves more as architects and less as pure implementers. As a result, the output and speed (agility) of a team go up considerably.
When developers work more as architects, work flows directly into teams and the responsibility of developers grows, a company grows in quality as a software-producing company. This means choosing standard solutions makes less sense. Standard solutions often require specialised staff (think Mendix, OutSystems, SAP, content management systems, etc.), often come with high licence costs, and upgrades to new versions are often painful. When we have truly agile development teams of architects, we are able to phase out these products quickly and replace them with open source alternatives that emerge from the fast-developing AI market. It is only a matter of time before open source alternatives to standard solutions start popping up everywhere. The company that can adopt and integrate them will gain both financial and agility benefits. You can already see entire projects being rebuilt in Rust, and even whole suites like Adobe Creative Cloud.