|Door:||Remko Vroomans, 28-07-2014|
Many teams making the transition from traditional waterfall projects to Scrum are struggling to fit the tollgates they previously had to pass into their work process. Although the testing tollgates, like systems tests and functional tests seem to fit fine within a sprint, when it comes to User Acceptance Testing, something feels not quite right. When do all the parties, all the departments or all the users officially test the product and accept or refuse it? Before I try to answer that question, a quick reminder of what User Acceptance Testing actually is.
|Door:||Prajeesh Prathap, 27-07-2014|
|Onderwerp:||Continuous delivery CD zero downtime deployment agile architecture|
One of the main problems teams face when practicing continuous delivery is to manage zero downtime deployments to the production environments. The goal is to deploy as soon as possible and depending on the heartbeat of the organization, this becomes a higher priority to manage active users without losing their data and sessions during a deployment process. In this post I'll share some of the ideas and approaches that are been used for achieving the goal of zero downtime deployments.
An important process for reducing risks and managing a zero deployment downtime is by following the blue-green deployment technique. In a blue-green deployment scenario, the approach is to bring up a parallel green environment and once everything is tested and ready to go, you simply switch all the traffic to the green environment and leave the blue environment idle. This also helps in easy rollback and switch to the blue environment if anything goes wrong in the current installation.
|Door:||Harm Pauw, 16-07-2014|
I often hear people say they really would like to do Continuous Delivery, but it is impossible because they use a certain product or technology. For example: instead of having a custom developed Java or .NET application, they use an off-the-shelf product for which they receive updates every x months and only configure it. While it is true that most examples for can find on Continuous Delivery use custom developed applications using Java,.NET or any other framework, it doesn’t mean you can’t do CD with other technologies. Even with off-the-shelf software that is only released every couple of months, you can do Continuous Delivery and get the benefits from it.
|Door:||Barry Overeem, 14-07-2014|
|Onderwerp:||Agile Teams Craftsmanship High Performing Teams Scrum Scrum Teams|
The daily scrum is the most used scrum meeting. This sounds obvious because it occurs every day. But it's also the first practice organisations and teams apply when starting with scrum.
Although the daily scrum is a very straightforward meeting with a clear structure and can be practiced daily, many teams fail to extract the potential value it offers. It is used merely as a status update meeting, performed mechanically and resulting in incoherent and ambiguous individual plans.
This is a shame, because a well-performed daily scrum should be energizing, inspiring and result in a shared refined daily plan that is created and supported by the entire team.
If your daily scrum has become unfocused, practiced mechanically and is an energy-drainer; using the best practice of a daily goal is a great solution!