Is our outsourced software vendor "Agile" or do they just not want to plan things?

Question

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?

Answer 1

It sounds like your management have been conned by the vendor, because this will be an extremely expensive process which will produce poor results.

You've got a pretty good summary of the problems right there, have you tried circulating it internally?

but this app handles regulatory rules with large penalties if missed, and I don't understand why we would not want large written documentation to ensure the new company understands all the rules

This is probably the strongest argument. If it's not taken seriously by your managers, can you take your concerns to your legal/compliance department?

Answer 2

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.

You have 2 problems here:

1. Remaking your software is going to be a time consuming project.
2. You are forced into getting their help for long term maintenance, because they own the framework/product that your software is now written on. You will find it hard(er) to find people to maintain your new software, so you either cave and buy a maintenance from them, or remake the software again with someone else.

The term "agile" in non-technical deals really can mean anything. Sales people and higher up managers use this term freely because it sounds cool to non-technical people. The reality is that the methodology the team is using has very little bearing on the final product. From your client perspective, agile only really helps you keep track of their progress easier (so basically the opposite of what is actually happening), but this can be done with other methodologies too. Given the details you provided, they are simply using the term "agile" to woo you into believing everything they say.

Basically:

1. You are being conned in a long game
2. Agile has nothing to do with what's happening here
3. Be wary of people saying "agile" too much, especially in sales pitches, they are likely trying to trick you. You should be able to check on their progress regardless of methodology. The methodology should be an agreement between you and them, not something one sided.

Answer 3

When you said:

they sold my management on just altering their existing software's framework to handle our business needs too

It immediately turns the situation on its head. You haven't contracted someone to make software, you have bought their software and they have promised it is customisable to your needs.

This is super common, big firms write generic platforms and then promise they can do everything. It also explains why they don't want to do prototypes, because they have a live system and are just making tweaks.

Maybe that promise will come true, maybe it will take too long, maybe it will be free, maybe it will cost a fortune. Whether it's a good risk to take is super hard to judge.

Say for example there is no charge until its complete to your specs and you cancel at any time. Well then you just have a free dev team.

Say you are being charged per "sprint" of dev work. Well the contractor can do whatever they want and just get paid every month.

How to deal with this? It's everyone's favorite. Automated testing!

I would prepare large sets of dummy data, run them through your current application to produce the output of various processes and send them half the data.

When they "complete" a feature, ask them if they have run the dummy data through and if they got a 100% match. If they didn't, tell them the feature isn't done, please go back and don't ask for money for this sprint.

If they say yes, give them the other half of the input data and ask them to send the output, which you can then check against your results.

If you have a UI requirement, take screenshots of your app (with dummy data) and send them. When they complete a feature, take screenshots of their app and do a comparison overlaying the images in photoshop or image magic. If there is a one pixel difference, send it back.

If they say no to this, tell them it is a requirement of your application to be able to produce such test data, and that is the first feature of the customisation that you require.

If they argue this is unreasonable, say that you need to be able to produce this data so that auditors can check the app legal compliance with data protection laws. or iso 91000 or GDPR or just say "security"

This will quickly kill the project, as it will be next to impossible to recreate the logic from the end results of processes and the risk of being held responsible for breaking the law will be high for the contractor.

Meanwhile, spin up your own company and rewrite the app with all the changes you have been wanting to do, and sell it to your current company so you can retire. When they want changes, hire contractors and pass on their wages + 20% per sprint.

Answer 4

"Agile" does not mean "no planning", rather that you should expect and plan for changes to the plan.

If you are the customer you should have access to the backlog for the re-implementation, and this should include all formal requirements. You as the customer decide the content and priority of the backlog, while the vendor should provide time estimates. If you think the time estimates are higher than expected, or that the vendor consistently underestimates the time, or the features not implemented as described, you have the freedom to cancel the contract and stop development.

But if the situation anything close as described this whole idea stinks. You should be very careful with doing rewrites, since chances are they will take much longer than expected, and may not even reach feature parity, let alone any get any actual improvements. So they should have some very good reasons to even attempt this, "we want to use framework X" is not a good reason by itself. Likewise, switching development teams is a huge risk and should be done with great care, likely including lots of meetings, documentation, temporary transfer of developers, etc. Doing both at the same time sounds like a recipe for failure, especially without proper planning.

You may also consider what incentives the vendor have. Are they buying the product? If so it seem foolish not to require the source code, regardless if they plan to re-implement or not. Do they bill per hour? If so they are incentivized to continue development as long as possible. How does the profit sharing look? Depending on the details it is possible that the vendor does not really care about the success or failure of the end product.

Answer 5

I hope for you someone has made a contract which allows to make check points in short intervals, where you have a chance to measure the project's progress and where you can cancel the contract if progress isn't achieved in a reasonable amount of time, with acceptable quality.

What I recommend here is that you find a way to make the forthcoming (or the lack of it) of the vendor transparent - especially to your management. You could do this making a rough spec, where you list all the keypoints you want to see in the new application, maybe a list of 50, 100 maybe 250 points. Make sure there are not many "trivial" points here, each point should be a real business feature, or at least a feature slice. This will take some time, but you have an existing application, which means the current requirements are quite clear, and it should not take you more than a few days to make such a list.

Since your vendor claims to be agile, they surely work in sprints and deliver at least every one or two weeks a new release. Now you check how many of the key points they get right in each sprint for the first 3 or 4 iterations (and maybe you find also points which seemed to be correct in the last sprint, but broken now). If the vendor says they are agile, you should be allowed to take influence which features they are developing in the next sprint, so make sure they do not focus on the low hanging fruits exclusively.

Accept those key points when they are really complete, fully tested and documented, so they are a real, working, productive replacement for the corresponding feature in the existing app. You don't have to be unreasonably picky about this, like Ewan suggested about the UI. I made the experience people will take you more serious when you stay reasonable, especially management, and don't offer the vendor a surface for attacks against you. Just don't accept things which are clearly crap or violate business critical requirements.

That should allow your company to estimate how long the whole process will take at minimum (in reality, it will take even longer, since as we all know, unforeseen things usually happen in later project stages). So if those early estimates will already show the vendor will at least need 5 to 10 years of work to replace your existing application, you have all the arguments at your side to stop this nonsense before it is too late.

TLDR; use the vendor's claim they are agile to your advantage. Don't try to debate with them how they work, just measure their progress or non-progress, estimate. That will be the only way you can convince management.

Answer 6

"Agile" is not the problem, the rewrite is not (your) problem, your involvement in the rewrite until it is done is the problem, because it will take much longer than expected.

The question is "what can I say to my bosses", so let's start from your bosses goal. Your bosses wanted to spin off this project because they want your team to do other things. So far so good.

The new dev team needs stuff from you. They have their idea of what they need from you and you have your idea of what you need to give them. In the end they are the ones getting saddled with the result, so it's their call mostly, except for "how long is your team involved?", which does concern both you and your management, who wants your team to do other stuff.

The way you describe it, your team is playng a part, dictating what the product needs to do and checking the end product at each iteration. This is considerable work and will last for the whole time until the rewrite is done.

So, when will the rewrite be done? Usually rewrites of non-trivial software take forever, specifically a time comparable to the total time they have been under development since their beginning. This is seldom an acceptable time to invest and the reason most rewrite projects fail. Note that the exact time does depend on a number of factors and you do have a few advantages over the first time over, but even half of total development time invested is usually way too much. A good question to answer yourself is, how much work in the app was to replace (or throw away) parts of it and how much was spent adding more things to it? The parts that you replaced or cut need not be rewritten, but every bit that was added needs to be done again.

Try to estimate that before going on. You can even halve it because the requirements are now clearer than they were as they emerged the first time. Chances are, it's still a huge time.

So what do you say to management?

• You tell them that your professional opinion is that the way this handover is going it is at a high risk of going on forever and that your team will then not be able to move on as planned in the foreseeable future.
• You can also ask them what was the time window that was allocated for the handover to be complete and discuss whether there is a way to know if the rewrite is on track.

What do you say to the other team?

• you would want to say that you don't want to be on call with them weekly until the end, so they should start to gather all the requirements and free you guys up and maybe call every few months. They would scream "WATERFALL!!! ANATHEMA!!!" and since they'd technically be right the conversation would be over.

Why is waterfall bad? "Agile" is the idea that if you start coding something usable right away (the "Minimum Viable Product") you can start using it early and then progressively improve it until you realize the original vision. This way of working has several advantages, including a faster time to market and the fact that putting the software to test earlier allows the vision to evolve and adapt in the mean time.

Notice a few assumptions:

• get a MVP in production soon
• time to market is important
• the vision has not met reality yet, so it is going to evolve a lot

So, what is the MVP in a full rewrite? Unfortunately to replace the existing product it has to have all the features the existing product has. The enormity of this statement is why product rewrites fail so often. Moreover the product "vision" is already mature and will change significantly less drastically than it would for a new product and the time to market is "we're already there", as far as users or sales are concerned.

To sum it up, the advantages are less relevant than usual and there is the added cost of tying up the existing dev team, which is not present in a new product. This would make me opt for a traditional "waterfall" development there.

N.B. 1 - I would NOT do a full rewrite of the software but rather gradually refactor it into something portable in the new platform. But if I HAD to rewrite it, waterfall would be the way to go.

N.B. 2 - here "waterfall" mostly means prioritising gathering the requirements and freeing up the old team. A promising idea could be to write automated functional tests for all requirements gathered, so that the original team can be activated less often and they can be also used as a measure of how far away we are from the end of the rewrite

Answer 7

Just to answer "are they actually being agile" more concretely. The Manifesto for Agile Software Development says:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

In terms of how they're failing to do this, the most obvious failing is that whilst they're not following a written plan, they're also not responding to change (you are asking them to handle this differently, and they're refusing).

They're also declining to collaborate with the customer (other than in fairly specific ways).

You can also argue that you started with working software and what you now have is not working software.

They also seem fairly attached to their process (we write software then you tell us what to change about it). This is a subtle one, but a number of the original authors of the agile manifesto have expressed frustration that many "agile" practitioners believe in sticking rigidly to their particular "agile" process, and that this represents a failure to understand the goals of agile.

Answer 8

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 work they are using to our executives who have a hard time understanding our complaints?

It seems your main complaint is that they aren't remotely performing a real investigation into how your current application works.

It seems ridiculous that they haven't asked for source code, if it was available, if only in case they might want to refer to it. Meanwhile, they haven't interacted much with the developers like yourself either. It's not clear what their detailed source of information is for what the application should do.

I would clarify with your management that they are being expected to reimplement the existing application, not devise a completely new design from the ground up.

If management agree that this new application is supposed to be derivative of the existing one, then perhaps invite management to wonder what their source of information is for how the application works, if not either the source code or the developers of that code.

Management may however ask, how are you expecting the contractors to approach the development? For example, are you expecting them to approach you for a conversation before developing each screen or piece of functionality?

Answer 9

Agile isn't right for everything. It's right for developing in situations with rapidly changing requirements.

You have a fixed target, and regulatory requirements (which tend to be fairly static).

this app handles regulatory rules with large penalties if missed

If it were my devolopment team, I would be going for bog-standard waterfall in this environment.

Add to that and the fact that your vendor clearly doesn't have any idea how to do agile anyway and is just using that as a buzzword to cover them not bothering doing the work properly, and I'd recommend you just cut your losses and sack them.

Answer 10

What I would do is go to your boss and absolutely sing the praises of Agile as a professional technique. Explain how useful it is to keep the flexibility in a context where you don't yet know the details of what needs building. Find a fitting non-computer analogy for it. One that feels plausible is "Agile development is like crafting something in clay rather than casting it in metal."

The goal here is to cut through the marketing buzz and make it clear when they'd want an Agile shop, and by implication when it isn't. You're trying to get a mass-manufacturing outsourcing partner, and they're insisting on doing everything as artisanal pottery. You don't have to say anything about any suspicions you may have that they may also be bad potters if the goal is cast iron.

Answer 11

I think that the description you made describes a problem obscured by political problems. It does not seem you have been on site enough to gather the technical details. It is possible that the vendor has a not invented here syndrome or it is possible that the vendor already had a framework to do something similar and they want to start from there the developement intead of starting from your code. That says nothing about the process they are using. Agile or not agile has nothing to do with it.

I suspect that all the pushing back happened because they don't want to let you know what they are doing. What framework and libraries they are using. You should actually wonder if they are hiding something and eventually explain the situation to the management. You might also ask the management if there were some special agreements, they promised to do the things in a certain manner or use developers with some specific skills (which might be missing).

For what matters the attitude about requirements it is possible that they are copying the behaviour of the app taken from the marketplace. You better check if there are new requrements that were not deployed. That should be the first things to check during the tests.