What is agility in business?
This was Rebecca’s initial question, probably the main point is to make deliveries faster and with more value, where the business reaches greater efficiency, with constant measurements of hypotheses, and once we confirm them, then we can incorporate them.
And that’s very interesting because despite all this idea involved in the product launch cycle, we still haven’t gone back to the source after delivery to discover what to do next or if it was really efficient this delivery.
To make that happen, Rebecca says that not only is a preparation level of technologies, continuous delivery or continuous construction needed, but also we need to align and explore how to unite their assumptions with the constancy of learning from agile cycles.
The time of crystal balls has passed, now we need to take decisions based on data and strategically aligned.
The development of these agile times needs to start their journey with definitions of ready (DoD), aligning not only how close you are to delivering that new functionality or not.
The business must always be aligned.
Rebecca emphasized that being agile is a matter of principles!
We should have them in mind, not forced.
The second step for these teams is prioritization and work on internal quality, because this way we reflect on metrics, understanding internal system dependencies or how messy or delayed we are.
Knowing that, we can provide changes at the right places, without fear about the changes that are happening, about what will impact or when a functionality delivery decision will be impacted by impossibility to happen.
The third point according to Rebecca to achieve this productive environment is learning and application of principles from evolutionary architectures.
To follow this task, it’s necessary to pay attention to code testability because we can discover and evolve with fewer restrictions.
We also need to pay attention to the minimum possible information needed for complete functioning, like addresses and CEPs, we don’t need to restrict them all, just the important part of this information is CEP.
The fourth point is that teams know and share the idea of responsible last-minute decision-making, we need to know until when we can wait to take that decision because the more time we have to learn, the more information we’ll have to make our decision.
Additionally, the less we do, the fewer restrictions there will be.
Rebecca doesn’t suggest following a BDUF model but taking decisions at the right moment and sharing expectations of when we need to take these decisions; they should be late enough to have information for decisions that aren’t too far away that interfere with deliveries.
Evolutionary architecture is the base for this moment because only then can we change parts at the correct moments.
The fifth point is continuous delivery (CD), or having the code source always ready to be delivered and deployed into production.
To make that happen, we need to make deliveries smaller and more constant, so we won’t have big impacts on training and learning; learn/teach a little at a time is much more efficient and profitable than all at once.
After that, we need to automate everything, all levels of testing, building (build), and deployment (deploy), but this doesn’t mean it has to be done alone; Rebecca suggests having a big red button that when pressed puts the code into production without infringing on the notion, definition, or objective of constant delivery.
We cannot forget that we need to maintain a safety net, which sends us quickly forward but returns us as quickly as possible to the last stable version.
The sixth point starts to involve team members from Design, and this needs to be fully aligned with the continuous creation sense (Continuos Design) and transformation of how we interact and treat user experience (UX), we need to think, create, publish, and unpublish our assumptions as soon as possible and to the maximum extent.
When we have all these points aligned and resolved, we fall into a dilemma because cost prediction is related to stability, and changing even if orderly isn’t always that efficient.
Each company has its own point of balance just like its main source of profit.
Then we need to find this point and separate them into deliverable activities and valued measures.
A good move might be the start of managed portfolio work, where each block has its value and can be weighed, measured, and prioritized.
So, with truly adaptable systems that have less cost and risk for the product team to experiment showing at the end how we’re doing with feedback, we probably will achieve better results that serve the entire organization.