6

I am working in an organisation with 11 scrum teams developing on the same code base. Currently, all development is done in trunk, and at the end of a sprint everything MUST be releasable, or it must be backed out (an arduous process) as a release is cut.

My opinion is that while work in a sprint is (ideally) 'done' at the end of the sprint, this doesn't necessarily mean ready for release. You may be at a point where you do not have a Minimum Viable Product to release, but have some stories complete. If a story is not done, or the story is only part of a larger feature, it should be easy to keep this separate from the release ready code. At the moment it is all backed out, the release cut is taken, then it is checked back in. A huge waste of time!

We use continuous integration, which is the main argument for everyone developing on trunk. Occasionally teams use a team branch, but this is currently frowned upon.

I've been considering simply having a 'dev' and 'release' branch, and pushing features to release when they are an MVP, or having a branch for each story or feature, but this is very admin heavy in TFS. Have other people dealt with similar issues in the past, and what are your thoughts on the best way forward? Unfortunately, we are tied to TFS in the short term.

6

Looks like you are completely borked with that lack of branching. At the very least you should be developing on a Dev branch and merging completed code onto Main when your code is working and 'releasable'. This would stop the stupidity of reverting committed work if you failed to meet your deadline and re-committing it afterward. The days of using VSS are long gone!!

Every team should have their own dev branch, but I can understand if you all want to work on a single Dev branch.

CI should be applied to both Dev and Main branches, and extra analysis on Main too - we used to put some very long running static analysis, doc generation and testing on Main that would have slowed Dev down too much.

Microsoft recommends using a Main branch (or trunk) with Dev branches and Release branches in their TFS model. (the old docs are here, though they say they are outdated.. but neglect to link to their current views)

3

The scrum guide is very clear: The work of a sprint is to deliver a potentially releasable increment of 'done' product at the end of each sprint.

There are a number of reasons for this but the main one is to avoid incurring unnecessary technical debt. Until you have made your product potentially releasable, you do not know how much work remains to be done, or how long it will take to release.

It looks like you have an excellent branching policy in place and it's great to see that you are doing continuous integration. I wouldn't change a thing.

One issue I do see though, is where you describe a story as being part of a larger feature. I can understand why this would cause issue with your branching policy. But I think the problem is with your pbi. A good product backlog item should be independent and I'd be more inclined to look at improving that to resolve the problem, rather than compromising on branching.

  • Thanks Derek, I agree but can't see logical ways to break some larger things. For example, we have a complex report to produce that is going to take around 6 sprints of work. In the first sprint the team committed to deliver the header, footer, and 1 section of data. This is a logical (and theoretically useful) step, and an end-to-end piece of the project (it has the report generation) but is clearly not releasable into production as the full report is needed. I can't see ways around things like this. – SpoonerNZ Aug 7 '14 at 15:58
  • A partial report is still considered working software; it just hasn't fulfilled all of the requirements. – JeffO Aug 7 '14 at 17:43
  • Breaking user stories down in to vertical slices of functionality that are independent and have value is certainly hard. There are many resources from agile authors on how to deal with this. Here's a simple blog article from Rachel Davies, for example: agilecoach.typepad.com/agile-coaching/2010/09/… There are many others, too. Story slicing is a great skill to have in your agile toolbox. – Derek Davidson PST PSM II CSP Aug 8 '14 at 7:26
  • I think this answer is taking my question off track - our stories are adequate from an agile point of view. They are complete and releasable, but we have not reached a Minimum Viable Product yet - on their own they compromise the end product. They would be fine for releasing to a staging environment, but negatively impacting the product if released to production. My question is how to deal with such stories in TFS or improve our branching strategy. – SpoonerNZ Aug 8 '14 at 9:09
  • 2
    they have a truly shit branching strategy - "everyone works on trunk" and if they don't finish their work, it gets "backed out". WTF?! – gbjbaanb Aug 8 '14 at 10:02
1

What you could do is define epic stories with substories.
Create a branch for that epic story and then branch off that one for every substory. When each substory is done, merge its branch back to the epic story branch. When the epic is fully finished, you can merge that branch back to master and release everything.

I have to agree with Derek Davidson though; it sounds like you are building your features one part at a time, instead of incrementally (which sounds like the same thing, I know).
It reminds me of a picture I saw on Twitter about how Spotify does things. Instead of immediately building a car one wheel at a time, they went from building a skateboard, to a kick scooter, to a moped, ...
I'm aware this is easier said than done, but keep in mind that there's always a way, even if you can't see it right now. You could start by asking what the report is for and trying to reason what the absolute easiest, simplest way would be to fullfill that goal.
It could be something completely different than a report.

  • Thanks Stefan - Unfortunately I can only mark one answer correct. I do see this as a valid approach we could take however. – SpoonerNZ Aug 8 '14 at 12:24

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.