Go to portal
Just like with diet and exercise, there is a tipping point where more of it diminishes returns. Speed without control is reckless. And with control I mean care, quality.
From the latest State of DevOps report it seems obvious that speed, stability and availability enable better performance as an organisation, which includes profit; productivity and customer satisfaction. That stability and availability translates into the quality of your application.
Balance
To have a sustainable product over time we need balance, that’s one of the items we cover in the course with Don Robins (so is the chart below, you can grab it for free here)
There is a natural tendency for the ‘visible features’ to try to capture more of the delivery. We, the stakeholders, the users, the customers… want more pages, buttons, components, automation… But as we have learned from past mistakes the items on the left (image below) have to be embedded in everything we do.
Lean
We also need courage is one of the values from Extreme Programming “Is the commandment to always design and code for today and not for tomorrow. This is an effort to avoid getting bogged down in design and requiring a lot of effort to implement anything else.”
Keeping things simple whilst preserving optionality allows you not only to finetune to reduce waste, but also to enhance and expand capabilities easily and to amend and refactor the existing ones. In a sense keeping things simple and modular allows you to manage future change less painfully, with minimal impact elsewhere.
Shifting left
Is the idea of incorporating feedback and testing way early and throughout the development cycle. That is to happen automatically and continuously, also being notified right away if something is not as expected, bringing the concept of monitoring not just for usage but for performance.
Shifting left supports feedback and integrates assurance, confidence and trust in the product. As further down the development cycle you find an issue the more expensive it is to sort it.
Image reference: https://www.stickyminds.com/article/shift-left-approach-software-testing
Definition of Done
This is one of the artifacts from the Scrum framework, but works a treat in any scenario. Is basically a way to convey agreement as a team to what means having a piece of functionality ready to be deployed.
The definition of done is the gap between the functionality being there and pressing the deploy button. What has to happen for it to be in prod in a blink of an eye?
Food For Thought
One thing you can do is gather data. Over time if the balance is not well looked after you will be surprised to know how much effort and time goes into repetitive tasks for anyone, for any team and for any organisation.
Gathering data around it and representing it visually, helps realisation and it should prompt conversations on how to elevate the repetitive efforts that are high volume into more systematic, automated and/or self-served solutions (as we spoke about in our story).
A system that needs so much manual intervention is just not sustainable over time.
