In some (if not most) of the transitions to an agile way of building software, the awareness of the manifesto happens after having started on the journey. The trigger to adopt agile probably varies in any given situation.
While some take a structured approach to adopt one of the agile software development frameworks, there are many who are looking to find a solution for a specific situation bothering them for a (maybe relatively) long time already.
Aah, there you go.
Barring few instances, most cases involve researching, adapting to a certain degree and dealing with certain unknowns. Making a comprehensive plan in such situation(s) asks for (some) room to maneuver.
To relate, let me know share two cases to illustrate the point.
Case 1: A software development organization having experienced success with a set of components that worked in tandem wanted to weave them into an integrated system. The idea was to deliver enhanced business value in a seamless manner. This grand ambition off-course lead to meticulous planning and drained all the available capacity to execute and deliver on this multi-year plan. Apart from the delays and impact due to the re-work of the design and re-planning, as more and more resources got absorbed into the plan, work started piling-up, concerning the support of in-production versions of the components and a huge technical debt. Without an end in sight, something needed to change to get things back in control.
Rather than focusing on detailing all the steps into a plan or finalizing the complete software architecture, it was a brush with working software over detailing.
The new approach did not promise a quick turnaround for all the problems. It helped prioritize the issues and deal with them in an iterative manner. To ensure we stay on course, it was decided to work with the potential users of the software.
This lead to earlier feedback and to keep the software fit for business use rather than having to defend the quality of the software using the contractual clauses.
All the internal learning while building the software could not get the required attention due to the rigidity in the plan and not enough scope to re-work and improve.
With the move to Scrum, there was more room to process the internal feedback as much as the external inputs. This helped create an environment of collaboration within the teams. Building the software right took as much precedence as building the right software. There was increased involvement from all the stakeholders as the software started to shape-up.
This was a process of discovery of better ways of developing software. This was a multi-year period of learning the nuances of Scrum and improving upon the way software could be built better.
Accepting the change is more important than just sticking to a plan. The world of tomorrow will be different from the world today and hence the plan most likely less relevant. Plan sets a direction and is not set in stone. It needs to be adopted as the execution proceeds further.
When the complexity levels are high, tackling change becomes difficult as all the consequences may not be seen through. Responding to change in such situations might even blur the sense of direction. As you make further steps in this journey, you will come to realize the benefits of working software over detailing. DO over THINK, SHOW over WRITE.