UPDATE: Myself and the business unit leader were able to make enough noise with the bosses such that the vendor has agreed to prepare User Stories for the work they have done and also for all new work going forward. The bosses did NOT seem to ever care about the whole "Agile" angle so it wasn't a selling point for them to start with I guess. It was a good lesson in that our IT jargon does not always translate to non-IT folks. I'm hoping that this change on the project approach will yield success. It will be nice for this app to "graduate" from my control and its success/failure after the vendor agrees to my specs is now out of my hands.
My company created a small app about a decade ago that has slowly grown into a large business unit and now is being spun off into its own business. It generates a ton of revenue and needs more support than my dev crew can put into any one project of ours. Basically it's a wild success in terms of the work we do. The corporate decision was made to spin it off so that a dedicated outside company takes it over, because it's now demanding some higher audit capabilities and support requirements than we want to handle. My team was not involved in the selection process for the vendor.
Additionally, the vendor selected did not propose that they just take over our source code. Instead, they sold my management on just altering their existing software's framework to handle our business needs too. So they are RECREATING our software from scratch instead of just taking over the source code.
They were given some internal training materials that I had prepared for cross training our own devs on the app, as well as a copy of the production database. They had around 2-3 phone calls with the lead business person (not an IT person) regarding what the software can and should do. The business unit lead is fantastic to work with, but did not understand that these conversations would be the "requirements gathering" phase (this is the fault of the vendor as they did not explain this to her).
At this point I was expecting some formal docs to be prepared but instead the company informed my bosses that they are "Agile" and just started writing code. As expected, myself and the business unit lead were caught off guard and tried our best, at first, to review their new app. We immediately noticed that they were changing UI and not implementing various business rules, because how could they when they never asked for our source code? They were relying on the 2-3 phone calls plus their attitude is "you guys test the software and tell us what to change".
I asked them to pause real development and just prepare UI prototype screens. This is how the business unit leader and I worked for years. They said no, it would be too complex and wasteful to do dummy screens. I responded that their version of our app seemed to be a normal JQUERY-based web app and that they could just give us unstyled dummy HTML for the screens, to which they still said no.
The business lead has asked them for what we in the industry might call "User Stories". Basically text descriptions of what the software should do. Again they have pushed back on that. They still just want to write code and ask us to tell them when the code does not implement the business rules.
I am at my wits' end. I'm kind of a home-grown back-water developer and have never done formal Agile or Scrum, but surely this cannot be correct.
I understand that Agile can be a great approach. But we have an existing application that is battle-tested and handles all the current business rules perfectly. Agile would be great if we were coming up with a NEW app I guess, but this app handles regulatory rules with large penalties if missed, and I don't understand why we would not want extensive written documentation to ensure the new company understands all the rules. We store the personal data of children under the age of 18 in this app, for example.
What can I do or say to this vendor and my bosses to explain that this approach is (1) terrible and (2) not actually "Agile" which is the buzz word they are using with our executives who have a hard time understanding our complaints?