English | EN 
In my (IT) business (and many others) there has been a lot effort in defining rigorous methodologies, and also a lot of focus on processes. In contrast, cross-functional autonomous teams communicate and act instead of spending too much time on either planning or following a complex process. The autonomous team actually remove much of the need for processes by automating as much as possible, and I like to set the bar high by saying “-Every manual step is a bug.”
There is a lot of talk about automation these days, and even if there are many interesting technologies, like Robotic Process Automation (RPA), offered as advanced products and services, I always like to start simple. There is a lot that can be done using simple scripts on a schedule or triggered by some other event, like a commit of a source code change. When it comes to setting up the development environment for a developer, a nice goal to aim for is that it can be done with a single click (or command). After that, each commit to the repository should trigger a build, followed by automatic tests, and then either deployed (for webs, APIs, etc) or distributed (for apps and connected things). Scripts are like automation prototyping, in that you can quickly test different solutions until you find something that works. Then you can make use of more advanced tools for efficiency, like simplifying maintenance so that less technical people can manage and maintain the automated tasks. When using automation on top of another (legacy) systems, you have to realize that you’re making it harder to change (or replace) that system, even upgrade to a new version of that system. So it’s always a good idea to consider a “real” automation of the process before adding another layer of automation on top of another system.
In my experience, a beautiful delivery is not only about creating something beautiful, but also to create the right thing. As creators of digital solutions we most often live in a belief that we have a good idea about what users want, but unfortunately we are almost always wrong. We are not only wrong on the detailed level, but even on fundamental assumptions about what people like. Therefore, a crucial aspect of making sure to delivery the right thing is to involve real users, and not only at the beginning and the end, but continuously as often as possible, and ideally each time your team make a new build. These users need to be well aware of their role, to be part of the process of creating something of value, rather than judging something as if it was a final product. You can read more about what I mean by beautiful delivery in Use Beautiful Delivery to Speed Up Your Digital Transformation.
Many of my fellow architects share similar experiences, and that is why we agreed on the following general principle:
Because the customer knows best we involve her each
step of the way, iterating on fulfilling her needs with
constant feedback, being agile, and using automation.
It’s something we strongly support and promote, and therefore it has been included in our Architecture Manifesto.
It’s also reflected in one the of the core values of the manifesto:
Service contracts and automation over technology standards and processes
I already covered the other part of that value in Service Contracts Over Technology Standards.
