7

I am working as a product owner, in a fintech based software company. My development team follows scrum methodology, and 2 weeks sprint. They tried to follow scrum ceremony, but not to do story estimation.

My stakeholder set 1 production release each month (say 25th of each month), and some time extra hotfix release. Our release cycle is much complex. First QA test the feature in SIT environment. After get the signed off from SIT qa, dev team build the package and send it to devips for UAT deployment. After UAT deployment, UAT tester test the build items (one thing to mention, UAT deployment only happen at time of product release not after each sprint deliverable.). If UAT tester found issue then it gets back to dev team, but they are in middle of sprint and doing some other work. Then dev team fixes the issues raise by UAT tester and send it to them again. Finally signed off from UAT it goes for production.

Now my question how could I streamline the process?, as development team got frustrated that they need to work sometimes in the middle of the sprint for bug fix or priority. I need guideline/expert opinion to manage production release properly that follow sprint.

Improve this question
6
  • 2
    Since, we are talking Fintech: what is actually the risk if the software has a serious bug? Millions? Billions? Then you should consider if a methodology for safety critical software might be preferable over an agile process.
    – lalala
    Commented Mar 29, 2019 at 11:01
  • Yes thats true, but Agile is most popular and my management knows it well. And I believe my problem is common and many experience this.
    – Toufiq Mahmud
    Commented Mar 30, 2019 at 3:08
  • How many people is there on the whole development + QA + infrastructure team?
    – Tiago Cardoso
    Commented Mar 30, 2019 at 8:18
  • 1
    @lalala: We are actually using an agile process to build safety critical software (of the sort that needs to be officially certified), so the two don't exclude each other.
    – Bart van Ingen Schenau
    Commented Mar 30, 2019 at 9:47
  • @BartvanIngenSchenau of course it doesnt exclude each other. What is your release cycle though?
    – lalala
    Commented Apr 2, 2019 at 16:44

2 Answers 2

Reset to default
5

I second ctrl-atl-delor (+1!) - you should invest on automation.

Agile methodology helps on how work is organized, but regardless of the methodology, you should automate as much as possible of your work.

We have a similar scenario in our project - and I'd guess it's fairly common on legacy applications.

You have two main fronts of work:

Based on your scenario, you'll need to assess which areas within SDLC or Testing automation you can obtain benefits faster (the low-hanging fruits).

You'll need support from either C-level and / or stakeholders, as you'll definitely need to invest time and effort on it.

Improve this answer
2
  • Yes, I agree with you. Automation and Test driven development could solve most of my pains. But its way to go. Need alignment with my management
    – Toufiq Mahmud
    Commented Mar 30, 2019 at 3:12
  • If your scenario is similar to mine, one of the key points is to define the items to deliver to UAT, how to identify them and ensure they're tested. That can be achieved with more (lightweight) process.
    – Tiago Cardoso
    Commented Mar 30, 2019 at 8:13
4

Well done you are doing a grate job. Scrum has lead you to diagnose several problems with your process.

I would recommend devops, developers and ops merge. They then fully deploy to testing (that is the same as operational). After testing you press a button to deploy to operational. Docker is a good tool to help with this.

The other thing (and most important thing) is to conduct a retrospective, when ever you detect a problem (feed back from test: Why did this happen? incomplete/secret spec?, incomplete developer testing?)

In a retrospective ask questions, without blame. When asking use 5-why. That is ask why, then ask why (5 times). E.g. Why did it break? It broke because we over loaded the donkey. Why did we over load the donkey? Because we did not know how much load we were putting on it. Why? because the scales where missing. Why? because they were being borrowed by bill. Why? Because bill does not have his own scales. Why? because of budget savings. Why? because …

Improve this answer
3
  • I think you missed the most important question from the feedback - how do we make sure this never happens again? Knowing how it happened doesn't help if you don't take action to stop it happening again.
    – UKMonkey
    Commented Mar 29, 2019 at 13:03
  • @UKMonkey I added a bit on retrospectives.
    – ctrl-alt-delor
    Commented Mar 29, 2019 at 19:38
  • @ctrl-alt-delor Thank you
    – Toufiq Mahmud
    Commented Mar 30, 2019 at 3:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.