Kommentare zu: Making Continuous Delivery work with Scrum and Sprints http://blog.hendrikbeck.com/2013/01/14/making-continuous-delivery-work-with-scrum-and-sprints/?utm_source=rss&utm_medium=rss&utm_campaign=making-continuous-delivery-work-with-scrum-and-sprints Tech Startup Craftsmanship Sun, 03 Apr 2016 21:59:00 +0000 hourly 1 http://wordpress.org/?v=3.8.1 Von: Fredrik Wendt http://blog.hendrikbeck.com/2013/01/14/making-continuous-delivery-work-with-scrum-and-sprints/#comment-74 Sun, 03 Apr 2016 21:41:00 +0000 http://blog.hendrikbeck.com/?p=344#comment-74 +1!
What’s the point of talking about what’s been done at the sprint review, in your mind? (I may be stuck on the words “do/been done”, as that’s not so interesting from a product point of view. What we’ve learned, and what attributes/features the product contains (and how they perform/impact users) should be more relevant than “this is work we have done”. But I’m guessing you’re also way passed that?)

]]> Von: hendrikbeck http://blog.hendrikbeck.com/2013/01/14/making-continuous-delivery-work-with-scrum-and-sprints/#comment-73 Sun, 03 Apr 2016 21:24:00 +0000 http://blog.hendrikbeck.com/?p=344#comment-73 A few additional words: I have come to value immediate or near-immediate releases of small features (hence reducing the amount of unreleased code) and immediate customer feedback *a lot*. The sprint review is more of a regular internal checkpoint of the team (and its stakeholders) to look at what’s been done and what that means going forward (e.g. re-prioritizing the backlog etc.). No need whatsoever in my eyes to wait for the sprint review before releasing features.

]]> Von: Fredrik Wendt http://blog.hendrikbeck.com/2013/01/14/making-continuous-delivery-work-with-scrum-and-sprints/#comment-70 Sun, 03 Apr 2016 19:52:00 +0000 http://blog.hendrikbeck.com/?p=344#comment-70 I completely disagree! The point of the Sprint Review is to inspect a product increment – ie the product – _as it is right now, with only Done functionality (new and existing)_ in relationship to the market (which is why stakeholders are there), so that we can adapt the product backlog to maximize the (potential) value of future work. “Future work” may include “release to market” if we haven’t done so yet. It may be “roll out to everyone” if a feature is currently in production, but turned on only for a subset of users.

]]> Von: thisGuy http://blog.hendrikbeck.com/2013/01/14/making-continuous-delivery-work-with-scrum-and-sprints/#comment-68 Tue, 17 Nov 2015 23:17:00 +0000 http://blog.hendrikbeck.com/?p=344#comment-68 sprint reviews are not supposed to be of items in production..

]]> Von: Witko http://blog.hendrikbeck.com/2013/01/14/making-continuous-delivery-work-with-scrum-and-sprints/#comment-61 Fri, 22 May 2015 07:52:00 +0000 http://blog.hendrikbeck.com/?p=344#comment-61 It really is the hardest thing to change! Quite a few people seem to be in the ‘shippable’ mindset not the ‘shipped mindset, as they see this as achievable within their sprint. Which restricts visibility of the whole and following things through to real completion.

I’ve found the idea of dark-launching quite simple as there are a few patterns to achieve this. Either by constructing your systems in such a micro way, versioning efficiently, or by using features gates.

]]> Von: hendrikbeck http://blog.hendrikbeck.com/2013/01/14/making-continuous-delivery-work-with-scrum-and-sprints/#comment-60 Fri, 22 May 2015 07:43:00 +0000 http://blog.hendrikbeck.com/?p=344#comment-60 Thanks a lot! :-)

And yeah, totally agreed on what you’re saying about #1. At the same time it feels like the hardest part to change people’s minds about this.

In addition to the “working code” you’ve mentioned I would also add the ability to deploy code that is not working yet, aka. “dark-launching” (in any one of the different flavors). What’s your opinion about or experience with that?

]]> Von: Witko http://blog.hendrikbeck.com/2013/01/14/making-continuous-delivery-work-with-scrum-and-sprints/#comment-59 Fri, 22 May 2015 07:18:00 +0000 http://blog.hendrikbeck.com/?p=344#comment-59 Great article.

I’m a lover of being able to continuous delivery combined with the lean mentality of putting working code into the wild sooner rather than later. Point 1 in your conclusion is a must for any team who wants to minimise all sorts of problems.

]]> Von: Juni Mukherjee http://blog.hendrikbeck.com/2013/01/14/making-continuous-delivery-work-with-scrum-and-sprints/#comment-58 Mon, 20 Apr 2015 21:50:00 +0000 http://blog.hendrikbeck.com/?p=344#comment-58 I share your vision. My book on “Continuous Delivery Pipeline – where does it choke?” is releasing on June 1:

http://www.amazon.com/Continuous-Delivery-Pipeline-Releasing-predictability-ebook/dp/B00VTZ2GSE/ref=sr_1_7?s=books&ie=UTF8&qid=1429554581&sr=1-7&keywords=continuous+delivery

I sincerely hope we can embrace CD and Agile a no-brainer.

Thanks,

Juni.

]]> Von: hendrikbeck http://blog.hendrikbeck.com/2013/01/14/making-continuous-delivery-work-with-scrum-and-sprints/#comment-55 Fri, 24 Oct 2014 12:27:00 +0000 http://blog.hendrikbeck.com/?p=344#comment-55 Thank you very much, happy to hear this. And hey, if you ever feel like picking my brain or sharing ideas and experiences, I’m very open to that. Always happy to meet likeminded people and learn and help… Good luck with your process!

]]> Von: jstalp http://blog.hendrikbeck.com/2013/01/14/making-continuous-delivery-work-with-scrum-and-sprints/#comment-54 Fri, 24 Oct 2014 12:17:00 +0000 http://blog.hendrikbeck.com/?p=344#comment-54 this is a great article. I am about to begin this process and found this extremely valuable. thank you!

]]>