5

Our team has recently adopted agile practices and most of the team is new to agile.

In our product, we use some code developed by another team and only they maintain that code. For the last 4-5 years, the previous developers have merged the code they intended to use and not all of that. Over time, the code in our branch was customized as well. Now for 3 years, these code bases have not been merged. We are expecting a lot of changes and manual conflict resolve process to perform a merge, as all of us are new to this code and also the code has been out of sync for long time.

How should we approach this kind of task/story in Agile way? Is there any guidelines to approach such unclear task where uncertainty is very high and we do not know how many conflicts/bugs will come out?

EDIT:1 please bear with me if question is not clear, let me know in comments and i will try to clarify as much as possible. So lets me try one more time.

As a AGILE team what I (and team) has learn so far is, before 2 week sprint starts, we discuss requirements with PM, understand the work needs to be done, finalize the approach for any DB design if and then two week sprint starts. in the middle one day we also do another PBR session where any new concern's can be raised for current sprint or we just continue understanding new stories for next sprint. On the last Day of Sprint we do Sprint Demo, and next Day Sprint Retrospective.

Recently I came to know word Spike. many AGILE teams use the Spike as a 2-3 days of period between sprints either at the end of sprint to finish up minor remaining task and do not need to carry the whole stories to next sprint. Or Sometimes in the beginning of sprint to finalize the design/approach or to flush out Proof of concept kind of thing.

When I (team) saw this code merge task, we are like there is no way we will be able to break down this story to confined task as 90% of things are unknown. we do not have automate test around the code, we haven't merge this code before and again this is a Baseless merge on SQL side. what ever we estimate there are highly chances that we good amount of task may remain incomplete. now in retrospective this will become bad on team. and such task can disturb team velocity as well.

So My question is How other people include such task in there AGILE team. Does this really be executed as SPRINT? or this should be one time effort by team and not logged on AGILE board? In a way i am looking for guidance on how AGILE allows to execute such task. If not Sprint is there anything else ?

closed as unclear what you're asking by Bart van Ingen Schenau, Arseni Mourzenko, Martijn Pieters, gbjbaanb, ratchet freak Mar 13 '14 at 13:45

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Unclear what help you need. Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it’s hard to tell what problem you are trying to solve or what aspect of your approach needs to be corrected or explained. See the How to Ask page for help clarifying this question. – gnat Mar 10 '14 at 14:58
  • I have a similar project where I created a branch for a major change. Over time it became evident that these two branches needed to remain separate because they had fairly different uses even though they shared a lot of code. Eventually they diverged into two entirely separate products and we decided to separate the two projects even more by moving the branch to a whole new repository. Merging would have just made both products worse, and separating gave us freedom because we stopped being concerned about that day when we eventually have to merge this mess. – Phil Mar 10 '14 at 16:07
  • @Phil, Keeping separate is not an option for me. instead this will be regular process based on when the other team releases major improvements and does those improvement we need in our product immediately or not. – Anup Shah Mar 10 '14 at 16:18
  • 2
    @AnupShah it is Agile or agile not AGILE. Agile is not an acronym. Neither is Scrum. – Dave Hillier Mar 10 '14 at 23:01
  • 3
    There is nothing agile about not merging for three years. This will easily take a month long sprint just to merge the code. There could be another sprint just dedicated to regression. – Rig Mar 11 '14 at 0:59
9

There's nothing "agile" about a 3-year merge.

Your team is going to have to put "agile" aside for a while, probably considerably more than a single sprint. You're going to want to freeze current codebase before you merge and extensively test, so you'll know that the starting code is fully functional. Then you're going to have to do the full merge, introducing no unrelated changes for its duration. Then you're going to have to test at least as well as when you started, because no matter how hard you try, you will introduce bugs. Once you've got that done, you can go back to being agile, but all that stuff in the middle is a classic waterfall solution to a classic waterfall problem.

Oh, and be sure to tag the repository immediately before and after the merge - for a year or more, you'll be blaming every weird bug on "that $#@#@$#^% big merge we did", and you're going to want to re-examine the changes to convince yourselves that you're wrong.

  • yes, you are right for that first line and personally I feel that this kind of tasks are not fit for the AGILE process. its just team have to suck it in and get done with them as soon as possible. and that's why i wanted to listen community if some have similar experience. – Anup Shah Mar 10 '14 at 21:47
8

I agree with MetaFight, this is a tough one.

Just to throw out a contrarian view point, do you really have to merge the code?

You have two large blocks of code that share a common ancestor. They split off from each other at least 3 years ago. The blocks have been maintained by two independent groups who apparently don't talk to each other.

What value does the business get from this merge effort? You know it's going to be expensive, difficult, and take a long time. It might be cheaper to maintain 2 code bases indefinitely than to spend dev-years merging them. (Production-phase code maintenance is a lot cheaper than development-phase effort)

  • 1
    @Dan Pichelman, yes, we need to use the code because it has some Client side code common to all products in company. for example how the client starts up, company branding logo, Devx/Grid manager customization, Default Grid Views available to all product etc... only one team works on those UI and/or some db performance enhancements, but all other product can just pick it up and they do not write their custom code for same functionality. – Anup Shah Mar 10 '14 at 16:13
  • 8
    @AnupShah: Would it be possible to extract/refactor these chunks of common code into small, stand-alone projects, and then do the merge in such small projects? – FrustratedWithFormsDesigner Mar 10 '14 at 16:22
  • @FrustratedWithFormsDesigner, to divide in a small stand alone project we need sufficient insight of the code or changes so far has been made in original branch. even if we manage to divide in small projects but thing is until we finish complete merge we will not be able to get successful build on half merge projects. we will have to get to the point where at least our client and service are up and running with complete merged code. as "Patterson" mentioned this doesn't seem 1,2,...n sprint task.it is unknown how much time it will take. – Anup Shah Mar 10 '14 at 21:59
7

This is a tough one.

Having to merge two branches of code you're unfamiliar with is tough to begin with. Add 3 years of divergent development and you've made it something I would quit my job over ;)

But let's be constructive.

There is no easy solution for merge conflicts. You'll have to resolve these manually.

And, unfortunately, with every merge conflict comes additional risk of regression.

If you're lucky your code and the code to merge will already have very good automated test coverage. This is important because nobody on the team knows what the intended behaviour of the innards of the application is. Your tests will know this for you.

The idea is that, after merging both branches, your automated tests will highlight any regressions resulting from the merge.

On the other hand, you might be unlucky and find that there is very little to no test coverage. In this case you'll have to start writing automated tests. You can write these unit and integration tests against your code, and hopefully the other team will agree to do the same with theirs. Otherwise, you'll have to do it yourself.

Depending on the size of the application, achieving 100% functional coverage might not be possible in a reasonable amount of time. The only thing I can suggest here is to focus on the most important functionality and then dedicate some time for manual regression testing to cover the rest.

  • 1
    Would it be fair to sum up your suggestion as "merge the tests first"? – DougM Mar 10 '14 at 16:28
  • @MetaFight, you explain what will happen correctly and also marked out uncertainty points correctly but my concern was to know any mechanism AGILE propose to handle such situation. other wise if we go to regular Estimation/SPRINT path, i am sure we will have lot of consequences and those are also unknown. – Anup Shah Mar 10 '14 at 22:09
  • 1
    DougM, I guess that would be fair, yes. @AnupShah: I did think about how this kind of task could be handled in an agile setting, but I couldn't think of anything helpful. I suspect it's because estimating the size of a task like this is nearly impossible, and breaking it down into smaller pieces of work can be difficult too. It just doesn't fit nicely into a fixed-length iterative approach. You'll probably want a code maintenance spike to be able to handle it outside of your normal agile process. – MetaFight Mar 11 '14 at 1:23
6

Sounds to me like it could be a big mistake to to treat this as just a big example of a merge, something that is going to involve an unusually long set of sessions sitting in front of a merge tool and pressing 'accept/reject changes'.

Instead, I would:

  • Spend an appropriate amount of time, perhaps a week, reading both sets of code.
  • Decide which one has the better architecture and tests; make that (call it system A) the baseline
  • Ensure there is a decent set of automated tests for system A; probably mostly integration-style near end-to-end tests.
  • extract a list of the required set of features from system B
  • put those features on the system A backlog
  • as those features are implemented, consider mining the system B for useful bits of code. But really you are reimplementing the features, with at leat the normal amount of testing; perhaps a bit more.
  • as subsystems of A become feature-complete wrt B's requirements, swap them into production on both systems, discarding that part of B.
  • repeat until there is only one part of B left: make that the 'do-B' subsystem of A.
  • Exactly! Break up the big merge into smaller steps that have actual business value. – flup Mar 11 '14 at 0:19
  • @flup/@Soru, as I mentioned in the other comments the task is more like a mendatory and/or technical work that we will need to do to make sure all products are using common code in the base and not creating their own solution for same functionality. from business value perspective i do not think it will show any value because there is nothing to show to management about that. but i see the common response from all other users as well that this should break down in smaller pieces and then it will get done in iterative manner. – Anup Shah Mar 11 '14 at 13:54

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