DEV Community

Discussion on: Frequent delivery - how?

 
nestedsoftware profile image
Nested Software • Edited

Assuming such a testing team had 2 week sprints, then the delivery frequency of shippable features would remain the same.

An alternative approach would be just to have a single development sprint. During the sprint, developers would hand finished features to QA for testing and would fix problems that were identified. Only features that had passed QA during the sprint would be considered shippable. Some work that had been completed as development but not passed QA yet would just be moved to the next sprint. That's a bit simpler and ought to work also.

If a separate testing pass is not needed, that's fine, but I think there are valid cases where features have to be tested separately after they've been developed. It depends on the kind of software in question.

Thread Thread
 
brpaz profile image
Bruno Paz

In your example, I guess the Testing team would be shared across development teams. If its one to one relationship, then I would say it doesn't make sense to have that barrier between development and QA and just have a single cross functional team.

Lets imagine the following. Two development teams are working in 2 weeks sprint. The same as QA team. We are in the last day of sprint and a developer from one team finished some feature and it goes to QA. but QA Team is busy testing a very big feature from other team. That team will probably not be able to deliver the feature on time.

How would you handle this situation? Have both development teams in different sprint schedules? Or would just be a matter of managing priorities or better planning?

Still, even with a better planning or priority management, not everything goes as planned, so there will definitely be cases where the Testing team could be the bottleneck for some teams to get work done. That would be avoided if they dont have a strong dependency of a external team. Talking about QA in this case, but could be Ops, for example.

But yeah, every organization and project is different, so what works for some might not work for other.

Thread Thread
 
nestedsoftware profile image
Nested Software • Edited

Thanks for your comment! I was actually thinking that a given QA team would only be working with a single team of developers. I did not consider sharing the QA team. So it was still, in a sense, a single cross functional team in my scenario. I agree that sharing a group like that is departing rather far from the core idea of what a process like Scrum is trying to do.

I was trying to reconcile two things: a) the need to have a separate testing activity after the developer considers a task completed and b) the fact that in Scrum, it's considered quite important to finish the tasks one commits to in a given sprint. The latter is not going to happen 100% of the time in the real world, but still, the whole philosophy of Scrum is to minimize the distractions so a team can make a commitment and stand by it in each sprint.

If we assume that it's not good enough for only the developers to consider a job done1, then if we keep a single sprint, we'll have work that a developer has completed just at the end of the current sprint going into the next sprint to be checked by QA. At the time, I thought we could mitigate this problem with separate sprints. However, now I think that's a bit of an artificial distinction, and maybe it creates extra structure without a clear benefit.

Probably it's simpler to just have a single sprint and accept that we'll need to carry over several tasks each time into the next sprint for QA. Maybe that makes a case for having a more fluid project structure like Kanban in the first place, where we just don't bother so much with this idea of a single sprint.

1In an ideal world, maybe we can expect the quality of work done by a given developer, or pair of developers in the case of pair programming, to be high enough, that we don't need a separate QA activity at all. I think that in practice, there are a lot of cases where this won't work though, even if we do have high quality being delivered by the development team and they're working hard to thoroughly test their own work first.