agile journeys

...rants by Asheesh Mehdiratta on Coaching, Transformation and Change

Category: lean

3 Simple steps to build your Continuous Delivery Dashboard

September 7, 2013 /
Continuous Deliveryis gaining traction now, but it is never easy to get funding :-|| But using Lean Value Stream Mapsyou can now showcase tangible efficiency gains by following these 3 simple steps to build your Continuous Delivery dashboard.
In uncertain times, people always struggle with executive funding for resources (infrastructure asset purchases and/or dedicated people). This is where I have borrowed the Lean Value Stream maps (VSM) to showcase visible dashboards focused on process efficiency gains, resulting in hard $$$ savings, and help win executives approval, for funding the various activities under the Continuous Delivery initiatives.
Here is a basic definition for Continuous Delivery, which is a set of practices and  principles aimed at, building, testingand releasing software faster and more frequently. The practices would typically include configuration management, continuous integration, automated testing, deployment automation, build pipelines and an agile team delivering frequent releases.
From the Lean camp, the Value Stream Map (VSM)is a lean manufacturing technique used to analyze the flow of materials and information required to bring a product or service to a consumer.
But for our needs and this scenario specifically, we are only focusing on the value stream map for the engineering organization delivery to UAT stage (which may include the deployment operations team).
The primary VSM metric to measure is the Process Cycle Efficiency where the cycle time is the total time measured from the developer checkin to the deployment and testing of a ‘candidate’ release on a UAT test machine or similar or the complete time it take to do a ‘NULL Release’(“If we changed one line of code in our application (or system), how long would it take us to deploy it into production using our regular release process?”)
Formula for Process Cycle Efficiency (PCE)
Process Cycle Efficiency (PCE)  = (Value Added Time / Cycle Time)
where Value Added Time – time spent producing a product or service for which customer is willing to pay for.
Cycle Time – Total time from start to finish including the Value Added and Non Value Added time (defined as time spent in setting up systems, equipment turnover, handoffs or simply WASTE’s in the production process)
So the 3 simple steps to build your Dashboard are –
  1. Build Process Cycle Efficiency (PCE)  for Current State
  2. Build Process Cycle Efficiency (PCE)  for Target State
  3. Calculate and Track Efficiency Gains

Step 1 – Build Process Cycle Efficiency for Current State

Let us assume a simplified typical 3 stage process which includes Build – Deploy – Test activities. Each of these activities may include multiple steps and can be drilled down, but for simplicity we keep this at a high level. A typical PCE Value Stream would appear as below –

 and the typical timelines for each of the activities can be depicted as –
All data in MINUTES
ACTIVITY
Legend
Time Taken
Build Wait Time*
W1
180
Build Execution Time
X1
20
Deploy Wait Time*
W2
300
Deployment Execution Time
Y1
80
Test Wait Time*
W3
300
Test Execution Time
Z1
100
Total Cycle Time
TT1=W1+X1+W2+Y1+W3+Z1
980
Value Added Time
V1 =X1+Y1+Z1
200
Process Cycle Efficiency
PCE1 = V1/TT1 %
20.41%
* Wait Time = Non Value added activities, which could include handoffs, signoffs, approvals, hardware latency, software latency etc..

Step 2 – Build Process Cycle Efficiency for Target State

As you implement the core practices of Continuous Delivery- Continuous Integration, Automated Testing, Continuous Deployment, Build Pipelines etc., the Target PCE Value Stream would appear as below –

and the typical timelines for each of the activities can be depicted as below –
All data in MINUTES
ACTIVITY
Legend
Time Taken
Build Wait Time*
W4
0
Build Execution Time
X2
20
Deploy Wait Time*
W5
10
Deployment Execution Time
Y2
80
Test Wait Time*
W6
10
Test Execution Time
Z2
100
Total Cycle Time
TT2
220
Value Added Time
V2
200
Process Cycle Efficiency
PCE2
90.91%
*Wait Time – Reduction in wait times as a result of following the core practices or waste removal for the non value added activities.

Step 3 – Calculate and Track Efficiency Gains

The PCE can be depicted on a monthly or quarterly graph to show progress, as shown in the example below. Based on the financial data, costs can be further assigned highlighting the time savings and the resultant cost savings per quarter.
Therefore Total Cycle time Savings achieved are = TT2-TT1=  980 – 220 = 760 minutes ~ 
= 13 hours SAVED = $$$ Savings
          Continuous Delivery Progress Dashboard

Assuming that the above scenario was for a single platform and single build, but these savings could increase exponentially, based on the number of parallel builds/deployments, across multiple platforms in a large scale enterprise product.
Let me know if this helps you move forward in your continuous delivery journey and if you have similar experiences with your executives and what was your solution. Till then you may wish to mull the below quote, while you try to Sell the benefits and joy’s of Continuous Delivery!
I have never worked a day in my life without selling. If I believe in something, I sell it, and I sell it hard. -Estée Lauder`

Is your Agile dashboard == Business dashboard?

July 26, 2009 /

Agile dashboards include Burn down charts (productreleaseiteration), team velocity charts, backlog items (productiteration) = Agile denominators

Business dashboards have managers measuring the schedule, resources, quality.. ; CXO’s measuring the ROI ROCE… ; and the business analysts have the Quick Ratios quarterly stock price EPS expectations to ponder = Business (Economic) denominators

But do we measure and communicate the relationship between the agile denominators and the economic denominators? Can you say that if my project agile denominators are high (low), my organization economic denominators are high (low)?

Or is the agile denominator dashboard only for the masses (teams executing projects) and the ‘sacred’ economic denominator dashboard for the management?

It appears that most organization dashboards have not evolved yet to measure both the agile denominators and their relationship to the economic denominators. Very few companies have the P&L visibility at the team execution level and this is what makes it difficult to derive or even see the above relationship (forget measuring the relationship) ! Though a limited organization set may be measuring both the indicators but in my view most organizations cannot think of sharing these financial numbers, citing trust or confidentiality as the primary reasons. Did someone say self organizing teams with responsibility?

In my view this missing linkage, offers an excellent opportunity for the agile community, to break the tradition, and challenge the latent organizational mindset. The right choice appears to be the Product owners who can (need to) step up to the plate and make this linkage visible; since they know both sides of the story and can communicate both up and down the organization streams.

Product owners talk about user stories and themes but rarely bring the project cost structure (salarysoftwarehardwaresupport team’s costs) and how the agile process is impacting the economic denominators. I feel they need to act as THE Glue and assert their voice by providing a bidirectional business dashboard for the ‘masses’ with the ROI / development costs, along with the team vision and vice versa for the business audience. This information flow to all stakeholders would allow an opportunity to question and debate while increasing the sphere of influence for everyone in the organization.

Until the above linkage is established, the various functions in the software industry are all sub-optimizing the system each sub-system meeting it’s benchmark, while reducing the overall system throughput. This surely is against the Lean principle of “optimize the whole”

Product Owners : are you listening ?

© 2024 agile journeys

Theme by Anders Norén — Up ↑