Delivery Process — The series
How many projects actually meet the end goal for what they were created in the first place? How many organizations launch good initiatives that end up canceled because of bad adoption policies, incomplete or vague initial assessments or as result of overwhelming sales cycles? Why do projects fail?
A few years after I started working, I found myself looking for ways to optimize the Process of Software Delivery. Living through a series of experiences in several projects made me feel like things were being done in ways that weren’t optimized, to the point of asking too much of the client, business analysts, developers and management. I sometimes found myself repeatedly thrown into similar situations waiting for different outcomes.
A clear and independent analysis would have immediately identified a completely wrong path. For example, embracing projects with complex scope using mostly junior developers (for the sake of meeting company targets) can create big future problems. In most cases, commitments made by less experienced people are difficult to unwrap.
The Process of Software Delivery is much more than the development and deployment pipeline. Nowadays, organisations have a strong awareness for processes that govern the development/deployment pipeline. The DevOps concept — which is gaining more and more traction and exposure — is currently one of the most mature processes in the organizations I have worked at in the past. But when it is not well connected with the rest of the structure it is insufficient:
- who decides what is to be to developed?
- When to develop?
- When to deploy?
- What feedback should be analysed and processed first?
These and more questions need to be addressed; the DevOps concept by itself is probably not enough to answer all of them. All the different elements involved in the Process of Software Delivery need to be aligned, aware, and committed.
The part of this process that concerns me the most, is the one that needs to be put in place when the organizations have to change their mindset regarding some aspects of software delivery. The part that needs to be disruptive enough to create fast results, but at the same time ‘soft’ enough so that people feel engaged with it. In the end, what is not needed is one more new process that ends up on the bottom of the CxO’s ‘Failed Procedures’ drawer.
This need led me on the adventure of trying to find and/or create a process or set of rules/principles that will create an approach to tackle different kinds of projects. I have already started a little here but I truly believe that there is still a long road ahead. In future articles I will discuss the importance of ownership, the fallacy of junior teams, how DevOps work as part of the Process of Software Delivery… and much more ;)
This question marks the beginning of this journey.
The reason…
Due to an enormous number of reasons, organizational participants including CxOs, managers, business analysts, tech leads, developers, and others, are sometimes not completely aware that some of their decisions are negatively influencing the current process. Instead of being productive and driving the delivery process to a good term, they are in fact slowing the organization down. In some cases, we just need to fine-tune the current process in order to put the delivery process on the right track. In other cases the situation is more critical and the challenge is bigger!
Organisational culture plays a big role in this process and unless there is a real commitment to change, the process of changing will be extremely difficult to accomplish.
A few months ago, OutSystems launched The Digital Transformation — Foundation Playbook and the more I read it, the more I felt connected to it’s message. This playbook describes a high level “how-to” for a new methodology — Low-Code Digital Factory — that can be used as a guide for organizations to apply to their digital transformation initiatives.
It is true that not all initiatives or projects we work on, have to include a Digital Factory right away, but my experience shows that in time, when clients start to become more aware of the true power of the OutSystems platform, the solutions landscape starts to grow and the process to govern that landscape needs to evolve.
As a result of several experiences, OutSystems decided to share this methodology with the world. More than anything this playbook tries to operationalize a mindset change and this particular type of change is everyone’s task and for everyone’s benefit. It isn’t a single person job!
To be continued…
This article is the start of a new series with this topic where I will introduce this methodology and hopefully drive from it several use cases where it can be applied. Not a recipe but more of an operational “how-to”.
