-1

Little background:

We have multiple teams working on developing an app and website. Sprints are 3-weeks long and they start each week for every Team. Meaning, 1st Team has their Sprint starting 1st to 19th, 2nd Team has Sprint from 8th to 26 and so on.

Technically we are having a release every week.

Now the issue is with the backend dev; as they working on microservices shared across Teams. So what's happening is when the release is happening, we have stories fully done from say Teams 1 and 2, but Team 3 is still working on a story and has few sub-tasks of the story completed. And this get pushed into Production while the story is not fully complete. Could someone suggest how should I write those sub-tasks so that I am sure whatever completed sub-tasks are getting released to production are of good quality?

Right now Teams write sub-tasks whatever way they feel like; Dev, QA, purely technical that can't be tested.

  • "Now the issue is with the backend dev" - what does that mean? "It's with the backend developer John"? "It's with the backend development work shared by all Teams"? "It's with the Scrum Team that works on backend development"? – Sarov Apr 11 at 20:52
  • I believe this question is more related to how the deployment process works rather than a pure management task. With that in mind, I believe that what you're looking for is Feature Toggles. Check this article at devops.se. – Tiago Cardoso Apr 12 at 8:06
  • Why are micro services shared across teams? And why is code from team 3 in a release build anyway? Do you use a version control software? – nvoigt Apr 12 at 11:21
-1

Sub-tasks for user stories are usually in two broad categories: technical bits that need to be built, and quality activities that need to be performed. For the problem you have of releasing weekly (which, by the way is great!), the most common approach has two main elements:

  1. Test-Driven Development (TDD) at the technical bits level. By using TDD properly, you ensure that any code that is committed is covered by passing tests and that developers have done a full unit regression run on their development workstations. This is a quality activity that should be included in the tasks for every user story. (Actually, most teams would add this to their definition of done.) I strongly recommend the book "Test Driven Development" by Kent Beck for details on this approach.
  2. Feature Switches at the user story level. Every user story gets a feature switch configuration parameter. It's "off" in production, but "on" in the development environment for a team until the team has completed the work on the user story. Sometimes implementing feature switches can be challenging if your current work requires changing existing in-production code. Therefore, it is also important for teams to have strong refactoring skills to keep the design of the system as simple as possible.

Please don't implement branch and merge for the teams. This will lead to huge problems as the complexity of your code increases. Even if you just branch for the duration of the Sprint, you will find that more and more time is spent merging at the end of the Sprint to prepare to release to production. Instead, great testing, refactoring and other quality and code-maintenance practices will help you avoid this path. I recommend two books for this: "Continuous Delivery" by Humble and "Working Effectively with Legacy Code" by Feathers.

In general, it sounds like you might not be making effective use of your definition of done. In Sprint Planning, your team can do task breakdown however they like... but by having a common definition of done for all three teams, you will avoid many common pitfalls. The definition of done aught to have some basic items like coding standards (naming conventions, patterns, etc.), testing standards (TDD, acceptance testing, etc.), and quality inspection standards (pairing, code reviews, etc.). Anything in the definition of done doesn't need to be called out as a separate task. Instead, tasks focus on the technical bits that need to be built such as UI layout, business logic and algorithms, database schema changes, integrations, etc. In many ways, good task breakdown is like a mini detailed design activity done during Sprint planning.

  • 1
    Recommending you do not use your VCS tools effectively is mind boggling. – nvoigt Apr 12 at 11:19
  • @nvoigt Seconded. If you're having trouble with merge conflicts, the solution is not to stop using branching! A solution is to rebase your feature branches onto the Develop branch more frequently. – Sarov Apr 12 at 14:09
1

Sub-tasks should usually be for the team however it helps them, like they're doing. It sounds like everyone commits to the main branch (which is a perfectly valid approach) but they are doing it in a way that means you want to release things from one team and can't because another team has made the code unstable (or that is the risk at least). This seems like the type of thing I would put back on the teams to solve. There are many solutions to it including different branching strategies, feature flags, or maybe just being more careful with commits. Either way, it's seems like the teams have both the technical ability and responsibility to solve this challenge.

0

I would go for feature flags, meaning that you can release to production with all code available but certain features will not be available because the flag is off.

0

I would also prefer feature toggles. However, a branching model could help to solve the immediate pain but -- as mentioned by others -- may introduce future problems with poorly integrated code.

To solve this it's maybe also a good idea to conduct some workshops (or establish guilds) for shared professions across teams to come up with a fitting solution for the technology at hand that can be taken back to the teams.

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.