Explore traditional IT development cycle
A few years ago, IT was a facilitating department. IT was there to support the business users, and because time had proven that developed software had bad quality by default, software changes were a risk.
The resolution for this "quality problem" was to keep changes under strict control.
The department that became responsible for controlling the changes became the IT(-Pro) department.
In the past and today, the IT(-Pro) department is responsible for the stability of the systems, while the development department is responsible for creating new value.
This split brings many companies into a problematic situation. Development departments are motivated to deliver value as soon as possible to keep their customers happy.
On the other hand, IT is motivated to change nothing because change is a risk, and they're responsible for eliminating the risks and keeping everything stable. And what do we get out of it? Long release cycles.
Silo-based development
Long release cycles, numerous tests, code freezes, night and weekend work, and many people ensure that everything works.
But the more we change, the more risk it leads to, and we're back at the beginning, on many occasions resulting in yet another document or process that should be followed.
It's what I call silo-based development.
If we look at this picture of a traditional, silo-based value stream, we see Bugs and Unplanned work, necessary updates or support work, and planned (value-adding) work, all added to the teams' backlog.
Everything is planned, and the first "gate" can be opened. Everything drops to the next phase. All the work, and so all the value, moves in piles to the next stage.
It moves from the Plan phase to a Realize phase where all the work is developed, tested, and documented, and from here, it moves to the release phase.
All the value is released at the same time. As a result, the release takes a long time.