In a Traditional Development Model, there is an order to how things must be developed in order to efficiently develop code – and it is critical that this order be followed, precisely, or things get really expensive, fast.
Traditional Project Management
In a traditional development flow, the process unfolds as follows.
- Someone comes up with an Idea and describes it to the Dev Team
- They develop a “Specification”, this specification might include:
- Business Requirements
- Technical Requirements
- Wireframes
- User Stories
- Data Model (schema) designs
- etc
- With all parties having been consulted, the spec is given to the development team who begin to “write the code”
- Developers create Back-End systems, API’s, Client Applications, Documentation, Unit Tests and more
- Testers go through and find problems – and product stability is achieved.
- Now the “Project Owner” (customer) is brought in to review. Typically changes are needed/requested
- Change Requests are made, and the project scope slips.
- The change requests then effectively go back to step 2 – and thus we “iterate”.
Often at this point, the project might be 30-50% of the way through the budget on both Time and Money – and frequently, big changes are needed at this point.
As it turns out, this is a very expensive way to write code. It’s expensive for a number of different reasons which we’ll explore below.
Order of Operations is Critical
In a “Traditional Development Model” It is absolutely key and essential that the original specification be as complete as possible before a single line of code is written. The reason for this is that it is not uncommon for literally 100’s of man hours to be invested in making the specification into something real. So if it’s wrong, it can literally cost 100’s of man hours before a shift is possible.
If it’s wrong, and change request is needed, it is critical that the exact nature of the change is fully understood – and that a complete description is provided or changes are costly as well.
Costs Increase with Size
Another cascading problem of the “Traditional” approach is that as the project proceeds, things tend to get more and more out of Sync. This problem is exacerbated as it goes over budget, because there’s less and less time to fully implement changes consistently across the stack. In other words, a change is requested, and the back end get’s updated – but the Client App is still out of date. Or the API get’s updated, but they have to wait for the back end folks to implement their changes before they can proceed.
These problems also get worse are the code-base grows.
Having an SSoT changes Everything
With an SSoT – everything works differently. For one thing, “the specification”, “the code” and “the docs” are all “the same” in a project based on an SSoT. In other words, when the SSoT changes, everything changes – as set.
As a result – on day one, when only an hour has been spent on specifying what is actually needed – with a stack based on an SSoT, it is not uncommon to have a fully functional implementation of that description, end to end – right out of the gate.
It’s not “done” – and it will change again and again and again, but it exists consistently across the full technology stack on Day 1, Day 10, Day 100, etc.
So – after a short discussion, we have a sketchy implementation which can actually be used, and the Project Owners (the customers) can use the tool and immediately provide feedback on what works, what doesn’t work – and the thus the iterations can begin.
So – Agile is to Waterfall as development based on an SSoT is to Agile.
