I am working at a company that builds products (website and apps) for our customers. There are dev team, QA team, and a release manager. The release manager is the one who defines release process and make a suggestion whether the product should be released to our customers or not. He also manages the QA team.

After 3 months working with this team. I noticed that the release manager keep changing the process and condition to give a go for each release.

The first example is when we plan to do a big release where 5 features need to be released at the same time. The first agreement is our QA team will test each feature once it is ready. On the first sprint, he said that he would not start testing until everything is good enough for QA. We change the process by asking developers to do manual tests according to tests from QA before they start testing. I learned that I did not put the agreement in writing and every agreement after this is always in writing.

The second incident is that QA needs API spec which I agreed. Every feature developers build, they also write document explaining the feature and API specs. During the sprint, he asked developers to add postman collection. Sure, that's easy developers do that. Now, he also asked us to add API according to tests. This is the first time I think he asks too much since the API spec is there and if they follow it through, they will know which API to use. Again, this ends up in project delay since they cannot test the products.

The third one is something I am not so sure whether it's a good process or not. He asks people in product team and developers to put impact analysis on every ticket including features and bugs. Otherwise, the QA team cannot test effectively. This is time consuming and I don't think it's a good use of time. This will be another discussion with him

Anyway, learning from my experience working with him. I am sure that he will come up with new changes and demands to product team and developers. What are some good strategy to stop this guy from changing the process during the sprint?

  • 4
    From a QA point of view each request IMHO is not unreasonable. What should be clear is that (most of) those requests should be AGREED in advance. Doing so both of you might need to compromise (and some of that work is probably best done by QA engineers instead of devs then he can't simply pretend but ask - if backed by a good reason, you usually don't want to inflate devs costs) – Adriano Repetti Apr 29 '20 at 18:12
  • I'm not sure what you mean when you say "add API according to tests"?? – DaveG Oct 17 '20 at 23:07

Perhaps this Release Manager has management asking for continuous improvement - or the Release Manager is not quite technical enough and keeps adding these items thinking it's a process improvement. It sounds as though the Release Manager is casting about for input, and should be asking for yours. Either way - it sounds like it would be very frustrating. I would attempt to confirm the current Release process before submitting the next change for approval. Validate his process by acknowledging you carefully thought this through. If he returns with unreasonable changes to the process, perhaps responding with great ideas, let's include those on our next change, as we will be impacted and perhaps slip on our deliverables if we need to change the process mid-workstream.

If that is still not possible, have you considered a non-finger pointing email describing the above with a cc of your management/manager? If used rarely, I find that effective. It depends on your org, of course.

Lastly I would propose that maybe you offer to be involved in the planning of the process, socialize it and offer to work on it. You may not really want to - but if your help is accepted you may get the opportunity to see, change or direct the changes before you are actually thrown into them.

Hope that is helpful in some way! ~catz


One thing that can help is to define a definition of done. Describe what exactly is needed for a user story to be done. Also I would say QA is responsible for the postman collections. Postman should be able however to import OpenAPI specs that can be automatically generated during build time. The actual postman collections and test runner should be way bigger than the (openapi) documented API resources. They would want to test non-documented features or non-happyflow resources as well.


Strange organisation.

In the usual places, the release manager can't just give tasks to developers. They can give requests to the team's manager, and the team's manager will prioritise them. If the team's manager decides these requests are low priority, then they will not be done, and the release manager will have to justify himself to the next higher level.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .