Managing Contractors in a technology conversion effort of an application

Question

We recently hired a firm to convert an application from .NET to .NET Core.

We have provided access to all repositories, they've been given an overall demo of major features and functions, access to a test box, and general requirements.

As the Scrum Master, I'm trying to understand Refinement in this situation. We as a company hired this firm due to their stated understanding of how to do the conversion. We have created epics that speak to an overall application that needs to be converted. They should understand what tickets need to be created, in what order they must be completed, and also what priority each has. They should have an understanding of points and estimates per task.

Typically I'm accustomed to the Product Owner running Refinement, having prioritized the backlog, going through stories, tasks, and bugs and getting feedback on story points and priority.

Answer 1

This innocent little question reads like a major corporate failure in so many levels...

We recently hired a firm to convert an application from .NET to .NET Core.

Let me take a guess. Two or three years ago, it became obvious that you would need to. Management shuffled that decision on their desks until last year. Last year they compared many contractors and brooded over contract language and payment modalities. And now the project can start. Well, reality did not stop and did not wait for you. That project was good three years ago, but Microsoft has announced, put through a beta phase and released .NET 5 in the meantime, superseding both .NET and .NET Core, so your corporate process has slowed you down so much that by now, your good project has become a doomed project, bringing your old legacy project into the world of slightly newer legacy projects. It's like finding out your iPhone 6 is too slow and asking for an iPhone 7 three years ago and this year finally the order went to the right department to get one for you. Congratulations to your brand new legacy phone. If you want to be up to date, your process of becoming up to date needs to be at least as fast a the cycle you want to be on top of. And compared to the other technologies, Microsoft .NET isn't exactly moving at lightspeed. You are just too slow.

As the Scrum Master, I'm trying to understand Refinement in this situation.

There is no refinement and you are not their Scrum Master. You have hired a company for a project. Not a group of developers that you incorporate into your team structure, a company. They have their own project management. They will give you updates if you ask for it. That's it.

We as a company hired this firm due to their stated understanding of how to do the conversion.

What I do not get... you happen to have a .NET application, but no .NET developers? How did that happen? Who is maintaining this application?

We have created epics that speak to an overall application that needs to be converted.

Well, I think you have zero understanding of what "converting to .NET Core" actually means. Given no .NET developers on your part that is not your fault, but it's is highly inconvenient for your company, going into this blindly with no understanding of what has to be done.

They should understand what tickets need to be created, in what order they must be completed, and also what priority each has. They should have an understanding of points and estimates per task.

Why would they use Scrum at all? You hired them to do a project. They could run it any way they want. Assuming they do want to use Scrum for some reason, there is no user stories here. You cannot go feature by feature of the application, that makes zero sense. Changes from .NET to .NET Core are basically infrastructure changes. All the code might still run the same, but network communication has to be changed. Or the database technology. You cannot go into this project and say "we will do the feature about user-login first". You cannot change database technology for one feature. Making that feature run independent of the others would be more work than just converting it whole.

Typically I'm accustomed to the Product Owner running Refinement, having prioritized the backlog, going through stories, tasks, and bugs and getting feedback on story points and priority.

Maybe they do that. But from the outside I would say it's not your job. If they do Scrum, it's their Scrum Masters job. Showing you their backlog work items would mean nothing to you, because they do not map to the features you know from your application.

So as a summary: if you want to be their Scrum Master, you need to actually hire .NET developers into your team. Since you have not, but instead given a contract to do a project to an outside company, they will do the job as they see fit. Maybe they will use Scrum or maybe not, but their work items will not look like anything you would have come up with, due to the nature of the task. It's purely technical and has nothing to do with what the application actually does.

Answer 2

Typically I'm accustomed to the Product Owner running Refinement, having prioritized the backlog, going through stories, tasks, and bugs and getting feedback on story points and priority.

I recommend keeping a very similar setup.

Prioritize the work based on which features in your application are most valuable. This will help to de-risk the work: If it overruns or hits trouble at the end that will be when the contractors are working on the lowest priority features.

Think about how you will be releasing the work. Will you have a minimum viable product (MVP) release in .NET Core? Will you release the updated features as you go along?

It is also worth thinking about how you will test the work. Do you need to create functional tests on your existing .NET product that you can use to confirm that the .NET Core product has not altered functionality?

Answer 3

Well, the advantage is that you already know what you are building, so this is not some discovery, experimentation, and learning process that evolves while you build the product. So your refinement will probably revolve just around how to do the conversion.

You should probably sit together with the contractor team and together discuss and decide on a "Definition of Ready". What will the team need to know before actually writing the code. This might revolve around information like:

• what are the dependencies; what things depend on others.
• the dependencies might then give you the order in which to do the conversion. Or maybe you order the work by something else, like maybe what might be a natural progression of changes given the nature of the application. Or maybe you go for the most important and riskier things first just to get them out of the way.
• acceptance criteria. Normally this would mean that things work the same after the conversion. If you have unit tests or integration tests, those should still pass, or at least be changed to pass based on what has changed. If something isn't covered by tests, what other criteria will you look for to determine nothing got broken? Those should probably be discussed before work is done in a sprint.
• understanding requirements. The code is sacred. But even so, when the code does not match written requirements (because in Agile you don't have exhaustive requirements, you just have enough followed by a conversation), people will have questions and someone must answer them, preferably before the work is underway on some component.
• estimations. Things (code, documentation, etc) will probably be reviewed enough to get a good confidence of the effort needed and make sure it fits a sprint

Thee might be more, but that's what comes to mind now. I do believe though that trying to agree on the "Definition of Ready" will give you a clue into what you need to do during refinement.

You said you hired them due to their stated understanding of how to do the conversion. So take it to them and ask how they want to attack this conversion and what support you need to offer them. Help them help you.

And finally, be careful. This types of projects (at least in my experience, YMMV) can cause people to generate new requests. New ideas might show up while you revisit the subject (i.e. "while you are there in the code, could you change this, or add that, or remove this other thing?"). So make sure you don't end up evolving the existing project unless it's done in a mindful manner.