Agile and Sprint with Multiple Developers on Same Artifact

Hi,

I have a question that hopefully somebody can clarify.

Take a situation an Agile type situation if you have a Sprint and one of the artifacts in the Sprint has multiple developers working on it. So Project A and Project B in this example.

Let's say that all appropriate merging takes place throughout the process.

So, Project A has some of the work in progress of Project B.

Project A is done but Project B is getting moved to the next Sprint.

Project A still has some of the work in progress changes from Project B.

And the end of the sprint project A is going to be released into the appropriate environment.

However, it would be released with the work in progress items from Project B which have not been completed which is not a good solution to deploy.

How would/could this be handled appropriately?

Any information would be great!
LVL 1
davismAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

sarabandeCommented:
Project A has some of the work in progress of Project B
sprints may not contain projects but tasks. then 'some of the work of project B' is task x and is part of the sprint planning of Team B. if x is completed both teams A and B could start new tasks within their sprints that were dependent on task x.

And the end of the sprint project A is going to be released into the appropriate environment
sprints are a set of tasks where the team agreed on in advance to get it completed within the sprint period. you may call this set a 'project' and have a 'release' at end of the sprint but actually this is not the idea of agile developing in my opinion as it would make the sprints inflexible and construed what is the contrary to agility.

Sara
davismAuthor Commented:
One can construe a "Project" and "Task" the same. I understand what you are saying with "task" but I used the term Project meaning the same thing.

I understand it's what is agreed upon to get completed at the end of the sprint and if all it well and good a proverbial "release" at the end of the sprint to the next environment or what have you is a viable approach. BUT what if what is agreed upon doesn't come to fruition and you end up in a situation I described? Then what? That is the root of the question.
sarabandeCommented:
the problem is that 'project' is too big. you need to divide the work load into units which are about 2 days work for one team member. bigger tasks produce the problems you described and also tasks where two or more members are working on same time. the idea of scrum is that all team members could help at end of sprint to complete all of the task the team has agreed on. if some work is not completed it has to be moved to the next sprint. the priority of a task which might be needed by another scrum team is another thing. you could solve that by putting all tasks of the sprint into a priority order what you have to do anyway if some tasks of the sprint have dependencies among themselves.

Sara
Your Guide to Achieving IT Business Success

The IT Service Excellence Tool Kit has best practices to keep your clients happy and business booming. Inside, you’ll find everything you need to increase client satisfaction and retention, become more competitive, and increase your overall success.

davismAuthor Commented:
No, again, mixing up the terminology there. Let's try it this way. Change all references of "project" to "task".

Obviously, the team "agreed" upon the task which is a smaller "unit of work" to do. BUT "task b" wasn't completed. And only parts of it were put in. So, "task A" was completed but it has those parts from "task b" in it.

So, the "task b" got moved to the next sprint. But the artifact from "task A" still has some of the parts from "task B" still in it's code.
Jessica RigaProducerCommented:
I think I understand the issue you're describing, dependencies between work items, which can get hairy really quickly. Unfortunately I don't believe there's a one-size-fits-all solution and the answer would be heavily informed by the kind of work.

For example: Can you move forward with releasing part A, but omit the navigation links so end-users cannot access it until B is complete?
davismAuthor Commented:
Yep, that's the dilemma. It's not necessarily dependencies between work items. It's associated with parallel/concurrent development on the same artifact.

Obviously, agile isn't so agile in that sense. One solution just as was with the case with waterfall, is weigh the options of leaving it in until it's done, remediate that portion so it's not engaged OR you remove it and retest the final. That is the same type of decision that had to be made with waterfall as well.

I would think that this wasn't a unencountered aspect. I'm sure it has been but I'm looking at how others have remediated the situation. Absent, leaving it in there.
Jessica RigaProducerCommented:
If they are separate work items without dependencies and rather we're talking explicitly about development on the same artifact, I'm wondering why parts of B are ending up in A.

Won't A and B be integrated individually? Allowing for release of A in it's entirety while B rolls into the following sprint and merged later?
davismAuthor Commented:
They are separate TFS workitems yes. But they both involve the same artifact.  

Let's say this, "task a" involves a modification to test.cs in the method TestOutput and adds a field (TestAField) to the output.

"task b" also involves a modification to test.cs and that involves a modification to a method TestInput which is to accept a DOB (date of birth) date.

Week 1:
 Now, "task a" has made the modification to get the TestAField from the DB but needs to modify the contents but decided to check the code in to TFS for safety.


2 days after "task a" checked in, "task b" does a get latest and checks out Test.cs (at this point has what is in "task a" in test.cs, and has identified the field in the file which needs to be imported, modified the method which imports the method to reading that field from the file. Decides to check in the code.

Week 2:

"task a" did the get latest and checked out. (at this point, it has was in "task a" initially into test.cs and what was done in "task b" in test.cs. "task a" does the necessary work and completes test.cs for the outputting of the field to the output.

"task b" comes to find out the date was not in the format expected and will need to have it go through other modifications or scrubs to verify it's date. That impacts the agreement to have those done in the sprint. So, those changes are put it into the next sprint.

So, at this point test.cs has everything from "task a" and a part of "task b".  The assembly is generated with the test.cs. Now, that assembly works for "task a" but will have problems on the inputting as the date issue has not been worked out.  

How is that to be handled?

The end result is part of it works and part does not.
Jeffrey Dake Senior Director of TechnologyyCommented:
Is this theoretical or do you have an issue?  I would approach this differently depending on which version control system you are using.  I use Git which makes this situation a lot easier.  In this situation I would have Project A and Project B on different branches.  The best way to move forward to keep them separate, especially since you said Project A is ready to go live and it could.  If Project B was created as a separate branch then you can merge in changes from Project A into Project B as needed, but you would not need to merge Project B's branch back into your release branch.  This way you get Project A in a releasable form, but can still continue to work on Project B which has dependencies on Project A.

If you have a choice on version control systems, I would definitely use Git. This makes it a lot easier to work with these interesting branch scenarios.

I hope this helps answers your question.
davismAuthor Commented:
We don't use GIT. We use TFS. TFS does have a branching strategy per project. Its one we chose not to deploy. It can leave a multitude of branches indefinitely. That can lead to a maintenance nightmare and a lot of confusion.
Jesse HouwingScrum Trainer | Microsoft MVP | ALM Ranger | ConsultantCommented:
The fact that the product is not in a done state, makes both A and B undone. neither should be shown at the sprint review and scrum is quite strict in the fact that the product is not in a releasable state. The team can possibly undo the work done for B to put the product back in a releasable state.

In order to prevent these types of issues there are a few things you can do.

 1. Limit work in progress. Have the team concentrate on finishing A, label the code or create a build mid sprint that would be releasable. Then start working on B. That way you can always show and release the "saved" build if B should not be finished.
 2. Work on smaller items. While limiting work in progress works quite well, it may be hard depending on your team composition. Another good way to keep your increment in a shippable state, is to break up your work into smaller steps. Each of these smaller changes should return the product into a releasable state. It may require additional effort to build your product this way, but it will add more flexibility.
 3. Use Branches and only merge the work once it is finished. While still highly recommending to limit the work in progress, branches can help create separate versions of your code with either A and either B in it. During the sprint the team can decide to merge a branch to the main branch, test it, build it and then see if there is something else to merge. There are dangers with this approach though. A and B may build independently, but may introduce unexpected behavior when merged. Branching is easier when using Git than when using TFVC, as Git is able to perform more complex merge operations with a slimmer chance or breaking things.
 4. Use a plugin based architecture/design for your projects. Code your features as plugins and deploy the base product with only the completed plugins. This way you almost always have a releasable product and separate functionality can be updated independently. Features "interacting" with eachother can still introduce strance behavior wen deploying specific features and versions together, so testing the combination you want to release is important.
 5. Use Feature toggles. Feature toggles are a way to turn certain functionality on or off using a software switch. This can be a license file, permissions or a config file setting for example. Before starting work on a new feature, introduce a new feature toggle and switch it off. When a feature is done, switch it on in the main branch. This way you can release a product with unfinished features, just switch them off. If this is a release that's shipped and installed on  3rd party system, the switch should probably be more robust (e.g. cryptographic, license file) then when deploying to your own webserver. You can also enable features for specific users or groups, e.g. allowing internal users to see the features, while external users can't yet.
 6. Dark launching. These are a special kind of feature toggles, dark launching works by using some kind of special code, cookie, url parameter, environment variable etc. When the special code is present, the feature turns itself on, otherwise it's off. This is a simple way of allowing external people to test and provide feedback, while other users can't see these features yet.

Another small remark that I feel I should make is about what you said about "Project B is moved to the next sprint". This may be a bit "white robe" of be, but as a Professional Scrum Trainer, I want to make this point anyway. When a team is unable to complete work in  a sprint, it moves the work back to the product backlog. Not automatically to the next sprint. This gives the product owner a chance to re-evaluate the work. As it stands it may be less valuable/important than other work at the top of the backlog, the additional effort required to deliver it may make it less valuable to deliver, and as such may cause the product owner to decide not to invest in this feature any further. This is also why it's important for the team to be able to back-out/disable/undo the work done for Project B before the next sprint starts. This has two advantages:

 1. The product owner can decide to ship A, since B is no longer making the product undone.
 2. The product owner can re-prioritize B

If the team is unable to back out B, the product owner is faced with two things he cannot change (and thus reducing the his agility considerably):

 1. he can't ship A until B is finished,
 2. he can't work on anything else on the product backlog until B is finished or reverted.

So he must put B on top of the backlog and thus have the team take it into the next sprint. Or add a new Product Backlog Item to the top of the backlog to undo the work done for B.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
sarabandeCommented:
It was a good discussion with valuable solutions where in my opinion a few of them were suitable to avoid the issues the Author has described.

Sara
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Agile

From novice to tech pro — start learning today.