0

We are trying to do CD where we have a sprint per release on each board. So we are working off a board, and when we either get all the tickets to Review, or just decide to pull a release, we make a new board, and our tool (YouTrack) will flow undone items to the new board.

The question is what does this process look like in most orgs? My feeling is the actual cutting of the new board should just be mechanical because whoever called for the release, there, you got what was agreed to.

One other issue we are trying to figure out is splitting tickets. So I might have been adding some feature to a number of places, but I didn't finish. I should split that ticket somehow so I can show what went in the first release and what is still awaiting another release.

Question is how other teams are doing this process of flowing stories onto CD boards. Mainly I feel now that the tools just do not support the obvious reality that most projects/stacks require multiple, separate releases. Even something as stupid as being able to have links to the 3 platform sprints that are currently being worked on (e.g. iOS, Android, backend) is impossible in YouTrack, so we waste a lot of time going back and forth between sprints. Of course we could make a single sprint, but then we don't have the clarity of a sprint that maps to a specific release.

Improve this question
4
  • 3
    I think you’re not really doing Kanban as intended. In Kanban, you don’t drain a board or queue and then create a new one. The board(s) and queues are long-lived, and should provide for continuous flow.
    – Todd A. Jacobs ♦
    Commented Aug 24, 2019 at 7:46
  • Not that it will influence the answer, but curious - are you using a virtual or a physical board?
    – Tiago Cardoso
    Commented Aug 24, 2019 at 10:39
  • We are using a tool called YouTrack, I said that? @TiagoCardoso..
    – Rob
    Commented Aug 25, 2019 at 13:23
  • @ToddA.Jacobs technically they are sprints on the same board is how the tool does it. Never mind though, user error, yeah my fault. Thanks
    – Rob
    Commented Aug 25, 2019 at 13:25

1 Answer 1

Reset to default
1

There is no one right way to develop software, so I can't say that what you are doing is wrong or right, but I don't think you can compare it to CD or Kanban best practices because you don't seem to really be doing either.

CD

Continuous Delivery is exactly that: continuous. There are no release batches in continuous delivery. Now, it is fair to say that due to some constraints, it is possible that you have continuous deployment to a staging environment and you kick over to live on an interval, but that gets messy and is often best avoided if possible. Due to this, you also don't have the splitting problem you mentioned. You you probably handle caching in small pieces from the start - each deployable on its own.

Kanban

Kanban is actually pretty flexible in what you do, but a few things are required. First, you visualize your process, so deployment would probably be just a part of that visualization. Also, you observe a whole item go through the process. You wouldn't cut partway through something. The board switch thing is very confusing to me and I don't think it fits in Kanban. In addition to visualizing your process, you are supposed to measure andanage flow of items from end to end and limit WIP,. It seems like the switching boards thing would make that very difficult.

My goal here is not to tell you that how you develop software is wrong, but that simple comparing yourself to other CD and Kanban practices is potentially problematic and could lead you down the wrong path because that isn't what you are practicing. If anything in this post triggers a good idea, then that is great, but I'd be very careful with it and, at the least, apply things experimentally.

Improve this answer
4
  • This is why there are so many agile haters now. Every freaking simple question is met by some priest who blubbers about how you are not following the gospel. Jesus what a joke. Ok, I'm not doing either one, thanks father lemme get my rosary out...
    – Rob
    Commented Aug 26, 2019 at 18:07
  • I'm sorry you took this so hard. My intent was not to pass judgement. My understanding of your question was that you were asking how other teams are practicing CD and Kanban, but this is problematic, because those things may not carry over to your context. For example, you mention caching. If I was using CD and Kanban, I would see introducing caching to a large system as problematic because of the cycle time involved and the large batch to deploy, so I'd break it into smaller parts. I'd never break stories in flight or transfer boards in those practices.
    – Daniel
    Commented Aug 26, 2019 at 18:13
  • Ok, I see. That was just meant as a simple illustration. I thought your comment that you would never split a story was really bizarre. Partial work is part of what iterative is: we cannot see the future perfectly, and sometimes, we will have to release something that is in essence a subset.
    – Rob
    Commented Aug 26, 2019 at 18:16
  • Added some more details, guess I could have been a bit clearer, thanks.
    – Rob
    Commented Aug 26, 2019 at 18:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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