Sprint Discipline: Releasing each iteration
My Thoughts:
The above is a recent post by Scott Knight on the Scott’s Thoughts blog which introduces the benefits of continuous deployment, and how we can improve our practice with the simple switch of doing real releases after each iteration. I think this post provided a great overview on the impact to Dev, Test, and PM in the process.
Really, a lot of the things mentioned by Scott are things we should be doing anyways, even if we aren’t doing a “real” release, but the fact that our code will actually go to the customer seems to make us do them more rigourously.
I would add that the DevOps team is impacted by this change as well, as deployments and updates to training/help documentation also need to occur with every release. Additionally, your support teams are usually impacted as new features are now needing to be supported by them every few weeks.
One of the things that I always hear about agile development and scrum in particular is the idea of creating a releasable piece of software at the end of every sprint. This is usually redefined into “a potentially releasable piece of software” at the end of each sprint. It tends to be a little more grey than that, some sprints produce a deliverable that is more potentially releasable than others so there are an infinite number of levels of potential between actually releasable and only hypothetically releasable. Almost all of the scrum teams that I have worked with over the last 15 years have all been on the “potentially releasable” and of that spectrum.
There’s a huge difference between “potentially releasable” and “releasable”; it’s the difference between having gotten a speeding ticket and actually being a race car driver. As an experiment, the team that I am currently the scrum master for…
View original post 794 more words
St-Cyr Thoughts 