Initiative to value delivery flow

Business as well as technical initiatives flow through the value streams and the respective workflows in order to generate value outcomes.

Business initiatives are what drive the organization in respponse to client and market needs. Technical initiatives keep the organization technical platform up to date in order to motor the business. Initiatives need to be validated by a Definition of Valid (DoV)

Appropriate due dilligence is applied to viable initiatives and OKR’s set to track the progress alignment. This process, guided by the portfolio workflow and owned by the portfolio team, produces output that is reviewed and accepted against a Definition of Acceptance (DoA). The portfolio process outcome is the Initiatives Backlog (IBL).

The IBL feeds the Product Management process, whose workflow and team, will create the Minimum Buisiness Increments (MBI) and the appropriate release plan. MBI’s are then broken up into workable features and work items (both user and job stories) that are governed by a Definition of Ready (DoR); then reviewed and accepted as the process outcome: the Product Backlog (PBL)

The PBL will then guide the delivery teams in their quest for quality value (small batch work driven by tests) through iterative planning and execution, and governed by the Definition of Done (DoD). Working tested solutions are reviewed and accepted and released according to plan.

MBI’s that are ready for packaging and release are checked against a Definition of Releasable (DoRe) by the release management workflow and team, to ensure value deployment.

Through team’s ownership, transparency and feedback, quality is built iteratively into the value flow in order to guarantee that the organization is working on the right things, doing it in a right manner, and in a repetitive way to delight customers.

Unknown's avatar

Author: Mario Aiello

Hi, I’m Mario – retired agility warrior from a major Swiss bank, beyond agile explorer, lean thinker, former rugby player, and wishful golfer. I’ve been in the agile space since 2008. I began consulting in 2012 with a Scrum adoption in a digital identity unit — and that path eventually led me to design an Agile Operating System at organisational scale. What pushed me further was frustration: poor adoption, illusionary scaling, and “agile” that looks busy but doesn’t improve business outcomes. That’s why I developed the Adaptive Fitness System (AFS) — an approach that treats agility as fitness for change: fit for purpose, fit for context, fit for execution, and fit for continuous improvement. Today, I use AFS to help organisations sense what’s real, learn fast, and adapt with intent.