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.
In cases where the start is a specific situation either “taming the backlog of work” or “incremental software development” or any similar situations, the idea about existence of the manifesto and/or the values it promotes is more a matter of discovery than probably a master plan.
Aah, there you go.
In the field of Software development there is always some parameter which limits you from re-using an existing piece of software and being able to make a predictable plan of the re-use scenario.
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.
As a first step, instead of “start-to-finish” approach, step-by-step approach was adopted to incrementally get the half-baked portions to shape up into a working software that delivers value to the customer.
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.
Customer Collaboration over Contract Negotiation kicked off and “Responding to change over following a plan” was happening.
A start-to-finish plan and a completely detailed architecture enforced rigidity into the approach.
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.
Eventually, Individuals & Interaction over Process & Tools became the order.
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.