Saturday, October 13, 2018

No Business Agility without Agile Software Delivery

Business agility is not possible only doing agile software delivery. Furthermore, business agility is impossible without doing agile software delivery.

The bad news is that using scrum without agile development practices is not agile software delivery (and will collapse faster than you think).

Agile software delivery:
- Requires to be capable to put in production and operate a continuous train of product increments during all the product life.
- Fast feedback for each step of the value stream.
- Requires automatic testing and requires to include quality in the process.
- Good feedback for the system in production (monitoring, observability, operability, etc).

So if you are a tech company (why every company is a technology company) and you want to improve your business agility, don't forget to improve your agile software delivery capacity. If you have doubts, DevOps and XP are a great start to complement your scrum process.

Related posts

Monday, October 01, 2018

Slides Taller Parallel Changes (Barcelona Software Crafters 2018)

Slides que he usado para el taller sobre cambios paralelos en la Barcelona Software Crafters

Presentación original:
Taller Parallel Changes (Barcelona Softwaare Crafters 2018)

Esta ha sido la cuarta versión de este taller. Gracias a todos los asistentes por el valiosisimo feedback que me habeis dado y que me va a permitir mejorar el taller.

Muchas gracias a la organización por haber contado conmigo y por todo el apoyo.

Si has estado en el taller y quieres dejar feedback:

Monday, September 10, 2018

Good talks/podcasts (Sept 2018 I)

Some good talks that I show lately:

Friday, August 31, 2018

Good talks/podcasts (Aug 2018 II)

Some good talks that I show lately:

Sunday, August 19, 2018

Cloud mindset (tech pill)

To create a significant software system using the cloud we need to think differently than when we are building a system to run in our data center or using VPS from a classic hosting provider.

Outside the Cloud (data centers and VPS),  the underlying computing resources are:

  • Effectively fixed because obtaining new resources requires months.
  • They are scarce because we try to buy the minimum resources needed.
  • Expensive since we have to pay them entirely and amortize them.

But in the Cloud, the underlying computing resources are abundant and fast to provision and this change the rules of the game and deserve a mindset change.

In the Cloud we should:

  • Consider the servers/disks/databases as disposable resources, treated as "just one more". This concept is called Pets vs Cattle and even if I don't like the analogy too much, it is true that it is interesting to read about it: The History of Pets vs Cattle and How to Use the Analogy Properly 
  • Always assume that anything will fail and design for it. The Cloud is based on commodity hardware that is not under our control and allows us to create massive scale systems. Due to the scale, we experience partial failures all the time (machines go down, disks broke, network fail...). As we can not predict at this scale, the best approach is to design for failure and improve the resilience of our system continuously. 
  • Define the infrastructure as code to allow rapid iteration. You can learn more about this concept in this previous blog post  Immutable infrastructure (tech pill).
  • Design to take advance of the elasticity of the Cloud. This includes architect for horizontal scalability so you can scale during peak hours without paying for this capacity during low activity hours.
  • Pay per use and rent not buy. When we design for the Cloud, we should try to use the resources as much as possible and deal with the variability in the load using the elasticity. The mindset should be, rent the most suited resources for the task and release them as soon as possible.

In summary, understanding the Cloud providers APIs and services is only a small part of your journey to the Cloud. The most critical step is to change your mindset and accept new underlying assumptions.

A new engineering challenge 
Construct a highly agile and highly available service from ephemeral and assumed broken components. (Adrian Cockcroft)