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.

Tiago Cardoso
  • 8,645
  • 6
  • 29
  • 72
Toufiq Mahmud
  • 71
  • 4
  • 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 Mar 29 '19 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 Mar 30 '19 at 03:08
  • How many people is there on the whole development + QA + infrastructure team? – Tiago Cardoso Mar 30 '19 at 08: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 Mar 30 '19 at 09:47
  • @BartvanIngenSchenau of course it doesnt exclude each other. What is your release cycle though? – lalala Apr 02 '19 at 16:44
  • @lalala, we are still working towards having potentially releasable software every iteration, but actual releases are delivered to our (non-agile; company internal) customers roughly every 2 months. Not all of those releases contain updates to the safety-critical parts.and only a few of them need certification for going into the field. – Bart van Ingen Schenau Apr 02 '19 at 17:32

2 Answers2

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.

Tiago Cardoso
  • 8,645
  • 6
  • 29
  • 72
  • 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 Mar 30 '19 at 03: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 Mar 30 '19 at 08: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 …

ctrl-alt-delor
  • 431
  • 2
  • 12