Agile, but still really not Agile? What Pipeline Automation can do for you. Part 3.

Organizations adopting Agile and teams delivering on a feature-by-feature basis producing business value at the end of every sprint. Quite possibly this is also the case in your organization. But do these features actually reach your customer at the same pace and generate business value straight away? And while we are at it: are you able to actually use feedback from your customer and apply it for use in the very next sprint?

Possibly your answer is “No”, which I see very often. Many companies have adopted the Agile way of working in their lines of business, but for some reason ‘old problems’ just do not seem to go away…

Hence the question:

“Do you fully capitalize on the benefits provided by working in an Agile manner?”

Straight forward Software Delivery Pipeline Automation might help you with that.

Read more →

Agile, but still really not Agile? What Pipeline Automation can do for you. Part 2.

Organizations adopting Agile and teams delivering on a feature-by-feature basis producing business value at the end of every sprint. Quite possibly this is also the case in your organization. But do these features actually reach your customer at the same pace and generate business value straight away? And while we are at it: are you able to actually use feedback from your customer and apply it for use in the very next sprint?

Possibly your answer is “No”, which I see very often. Many companies have adopted the Agile way of working in their lines of business, but for some reason ‘old problems’ just do not seem to go away…

Hence the question:

“Do you fully capitalize on the benefits provided by working in an Agile manner?”

Straight forward Software Delivery Pipeline Automation might help you with that.

Read more →

Agile, but still really not Agile? What Pipeline Automation can do for you. Part 1.

Organizations adopting Agile and teams delivering on a feature-by-feature basis producing business value at the end of every sprint. Quite possibly this is also the case in your organization. But do these features actually reach your customer at the same pace and generate business value straight away? And while we are at it: are you able to actually use feedback from your customer and apply it for use in the very next sprint?

Possibly your answer is “No”, which I see very often. Many companies have adopted the Agile way of working in their lines of business, but for some reason ‘old problems’ just do not seem to go away…

Hence the question:

“Do you fully capitalize on the benefits provided by working in an Agile manner?”

Straight forward Software Delivery Pipeline Automation might help you with that.

Read more →

How to create a Value Stream Map

Value Stream Mapping (VSM) is a -very- useful tool to gain insight in the workflow of a process and can be used to identify both Value Adding Activities and Non Value Adding Activities in a process stream while providing handles for optimizing the process chain. The results of a VSM can be used for many occasions: from writing out a business case, to defining a prioritized list to optimize processes within your organization, to pinpointing bottlenecks in your existing processes and gain a common understanding of process related issues.

When creating a VSM of your current software delivery process you quite possibly will be amazed by the amount of waste and therefor the room for improvement you might find. I challenge you to try this out within your own organization. It will leave you with a very powerful tool to explain to your management the steps that need to change, as it will leave you with facts.

To quickly get you started, I wrote out some handles on how to write out a proper Value Stream Map.

Read more →

Continuous Delivery is about removing waste from the Software Delivery Pipeline

On October the 22nd I will be speaking at the Continuous Delivery and DevOps Conference in Copenhagen where I will share experiences on a very successful implementation of a new website serving about 20.000.000 page views a month.

Components and content for this site were developed by five(!) different vendors and for this project the customer took the initiative to work according to DevOps principles and implement a fully automated Software Delivery Process as they went along. This was a big win for the project, as development teams could now focus on delivering new software instead of fixing issues within the delivery process itself and I was the lucky one to implement this.

This blog is about visualizing the ‘waste’ we addressed within the project where you might find the diagrams handy when communicating Continuous Delivery principles within your own organization.Read more →

Continuous Delivery Essentials: Expect it to break

Expect it to break

In a Continuous Delivery environment it is important to maintain a stable system so new features can flow into production whenever they are ready. A broken system requires developers to focus on problem solving and applying fixes rather than to introduce cool and new features, making it of prime importance to make the system as robust as possible.

Many systems are built on the happy flow and do not give thought on handling error conditions. However, modern systems run 24 hours a day, 7 days a week and depend on other systems, making errors inevitable.

So expect the system to break, anticipate on errors and build the system to cope with errors gracefully and resume normal operations when the error condition is resolved.

Read more →

True & Reliable Continuous Delivery

True & Reliable Continuous Delivery

True and reliable high quality Continuous Delivery is not just about fixing isolated issues with regard to teaming, deploying or tesFive Areasting. It’s about implementing individual topics in an integral manner while optimally balancing the investments and efforts that you make for each of these topics.

– Agile Teaming – for quick and continuous delivery of new features

– DevOps – a move from project teams to product teams that feel end-to-end responsible for a working end product.

– Quality on every aspect – quality of teams, code, releases and systems.

– Software Craftsmanship – components should not fail at the first glitch of a system.

– Automation where possible – error prone manual interventions are now longer allowed. Servers can be delivered within the hour, applications can be deployed within minutes.

Read more →

How to setup MongoDB in production

Interesting story on how to setup MongoDB in production. It talks about 2, 3, 4, even 5 replica sets, it’s pros/con’s and shows you how these setups deal with reconfiguring primary / secondary configurations on the fly. Apart from that, a fair amount of the presentation explains what parameters are important for sizing your HW configuration in terms of RAM.

Chris Harris and Alvin Richards present “MongoDB in Production”.
Chris Harris is European Solution Architect at 10gen and Alvin Richards is Senior Director, Enterprise Engineering at 10gen

How should we setup MongoDB in production and what resources do we need?
This session covers how to setup up replication for data protection and high availability to protect you against server failure, network failure, power outage and complete data center collapse. Understand the metrics used to decide your working set and disk setup. We also cover an introduction to MMS as a monitoring system as well as an overview of backup strategies.

Performance on Amazon AWS

The following story I find really interesting.
Bhaskar Sunkara, VP Product Experience at AppDynamics, presents “Performance on Amazon AWS”.
Among other things, AppDynamics is known to be used by NetFlix to monitor thousands of JVMs on Amazon AWS.

The presentation tells you about how Netflix partnered with App Dynamics to monitor their systems in a (more than) dynamic cloud infrastructure by AWS.
A large part of the presentation explains about what the important design principles are to be aware of when developing for the cloud.

Main message: machines will come and go, systems will go down. Application availability is in the hands of the developer. Develop for availability.