Spec-driven development
Specifications (or specs) are the description of the software. In the traditional scrum flow, they are written (or not written) by developers based on the requirements provided by the Product owner. In scrum, specs do not have the highest priority: As long as there is an (intrinsic) understanding between Product owner and developer about what the software needs to provide, the spec is neglectable.
AI is now another member of the development team. AI does not understand intrinsic knowledge the way that humans do. A lot of requirement misalignments in software building a caught by asking questions or a random comments by a colleague. AI does not have that. If AI writes the code, the description of the expected outcome needs to be sufficiently complete and unambiguous to avoid tedious and time-consuming rework
Because we want AI to be included in writing code, we, Product owners and developers, need to adjust how we approach software development. Because AI codes quicker than any developer and is more likely to make up requirements, we have moved to spec-driven development for any new projects that we start.
Old versus new
Traditionally, at the beginning of each sprint, we started out with a feature idea that had 90% clear requirements. The team had refined it previously, and any last questions that came up when running into edge cases, we discussed during the sprint. First, the testers wrote the testcases for the feature, in parallel the developers started coding. Coding usually started on the first or second day of the sprint.
This approach is not very effective with AI as a junior coder. With spec-driven development, the team’s first action in any sprint is working on the specs. The first few days of the new iteration, we focus on writing a detailed report of the What, the Why and the How. Only when 100% of the requirements are clear, and the spec file has been clarified and ratified, does the coding start. The process of coding therefore moves to later in the work increment, and takes up a smaller part of the overall timeframe.
We moved past Scrum
At Infodation, we have been working in the scrum framework for a long time. Meaning that we check priorities every sprint, we release on a regular schedule, we have standing meetings that fulfill certain functions like sprint reviews, refinements and retrospectives. With how much AI changed our software development, scrum doesn’t work for us anymore. Metrics like velocity are not applicable anymore, traditional planning tools like Story points lost their meaning, and with rigorous automated testing, we have the option to deploy code more often than in the previous two-week intervals
The New Way of Working (NWOW)
We developed our own approach to software development. Internally, we call it the New Way of Working. NWOW focuses heavily on software development supported by AI, from prototyping to writing tickets, from creating documentation to running tests. Spec-driven Development and an outstanding test-case suite are the backbone of this new approach. We are currently in a transition phase and expect that by Q4, 80% of all Infodation projects will use NWOW.
A methodology, not a monument
As makers of software, we are used to an ever-changing landscape. AI is the largest upheaval since I started working in tech, and its constant iterations and improvements make it challenging to find the spot in the market that allows for good quality software, economic viability and happy employees. NWOW is our attempt to find that spot in a new world.
NWOW is not our final answer. It is our current best answer.
AI is improving fast. Models that today require exhaustive specs to produce reliable output will, within years if not months, handle ambiguity better, ask better clarifying questions, and catch requirement gaps the way an experienced colleague currently does. When that happens, the case for front-loading days of specification work weakens. Some of what we are building into NWOW today will become unnecessary overhead tomorrow.
We are aware of this. NWOW is designed to be revised. The same discipline that led us to question Scrum when it stopped serving us will lead us to question NWOW when the tools outgrow it. We expect the spec-heavy phase to shorten as AI matures. We expect new bottlenecks to emerge that we cannot yet name. What will remain constant is the underlying principle: understand what the software needs to do before asking anything (human or machine) to build it.
For now, NWOW reflects the AI that exists today, not the AI that is coming. That distinction matters. A methodology built for a tool as it is, rather than as we hope it will be, is one that can actually be used.
Is your team figuring out how to work with AI? We're happy to share what we've learned!
