2

In our development process, for networking reasons, some stories can't be QA'ed or tested until they have been pushed to production. We do not, however, currently have branching capabilties so when pushing something to test into production mid-sprint, we also push some unfinished code for other stories.

I am still defining many of our scrum practices, but this seems to be a confusing issue that I am trying to wrap my head around.

Does anyone have any suggestions?

2

I see 3 routes you might be able to take:

  • create branching capabilities :)
  • create proper test environment(s)
  • follow Scrum by the word and create one feature at a time. That would result in change sets that are only relevant to the feature you're about to test.

I don't believe there's any workaround you could get away in this situation apart from simply solving the problem that you don't have a proper staging/qa solution.

You could however ask the questions:

  • what are the networking issues?
  • how can you get rid of those issues?
  • who's in your way of solving them?
  • why didn't that person solve it already?
  • repeat the above for the problems you discover by these questions until you reach the root cause, and solve it.
6
  • Thanks! Firstly, usually, do teams deploy all of their work to production and test on production towards the end of the sprint when it has all been finished and tested on QA, or do they incrementally push and test on production after each feature has been tested on QA?
    – ppadru1
    Oct 24 '13 at 15:58
  • There's usually a QA environment where they test after every commit and the boxes contain the master branch. If a release is good to go, they deploy it to a production-like clone environment and test the whole thing there. If that's good, they ship it to production and eye-ball it. Littering production database with test data is usually not a good idea, and if you have a proper clone of the prod environment in the previous stage, you can be confident that it'll work in prod too.
    – meza
    Oct 24 '13 at 16:01
  • so, QA (deployed on a feature-basis) > Production Test (deployed on a feature-basis) > Production (all sprint code, containing all features deployed at once)
    – ppadru1
    Oct 24 '13 at 16:09
  • It depends on the team and the way you define the process. In advanced situations the whole process is automatic. A developer commits to the codebase, it gets deployed to the QA environment. If all the tests pass, it gets deployed to the pre-production environment. If all tests pass, it's shipped automatically. In less professional setup, it might go to pre-prod with every commit (after being tested on QA), and when you have your sprint demo and the PO is happy with what she sees on pre-prod, she can press the "Ship it!" button :)
    – meza
    Oct 24 '13 at 16:13
  • I wish this could work. Since this project is for an internal management interface that is already live, sometimes we need features rushed onto production mid-sprint. A lot of people are already using this tool, and some of the features are needed asap.
    – ppadru1
    Oct 24 '13 at 16:27
2

You seem to have at least two significant impediments:

  • No branches
  • No testing environment

Both have to be resolved if you want to ship a quality product. I'm sure you're all too familiar with consequences of shipping unfinished and untested code since you're asking the question.

I would really focus on those two issues.
First, introduce branching to code repo - if your team isn't familiar with the concept, organize a training for them. Let them learn.
Second - testing environment. If you're unable to get one (for any reason), maybe you could find a possibility to mark "not Done" features as "experimental" or something similar - anything that will inform your users that the feature might not work as expected?

3
  • I too think those are the actual impediments you're facing. Pushing something to production mid-sprint is no real issue if a) the feature is tested properly, and b) it isn't tainted with commits pertaining to other features that might not be done yet. If you're really concerned about putting code that fulfills there requirements into production mid-sprint, take a look at continuous deployment.
    – CMW
    Oct 28 '13 at 22:06
  • Thank you! We have a testing environment, but due to the complicated nature of our networking, we can only test some features in production. I think branching is a major impediment. An ideal situation would be to push to production only those stories which need to be tested on production, without pushing out code related to unfinished stories. We are our own clients, since our project is internal-only. I would love to read something on branching if anyone has some helpful articles?
    – ppadru1
    Oct 29 '13 at 14:19
  • My team uses Continuous Integration but I doubt this would do you any good (due to your need for selective delivery of features). It would be best if you discuss it with your team - I'm sure they'll be able to come up with a few interesting ideas. Also, here is a few links for you and your team: FeatureBranch by Martin Fowler and Story Branching by Atlassian. Hope they help! Nov 1 '13 at 18:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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