“OUTCOME” or “OUTPUT” driven Agile

Hello All,

 

 

Nowadays IT industry is bombarded with articles on Agile with loud and clear message #BeLean. Everyone around teaches AGILE as in #GOAGILE, #BEAGILE, #AGILITYLEADS and many more hashtags around #ONLYAGILE. Lean Engineering gurus have been coaching corporates to go #AGILE and be #LEAN. Literal English meaning of being Agile is to be nimble, to be able to adapt to the changing needs of company to achieve goals as to what is desired by business. But why do we need Agility, is it to be able to achieve outcome i.e., #BusinessesNeed with speed i.e., #Velocity? I am perplexed with what I keep hearing around Agile practices and I firmly believe we should try to understand the rational for being Agile by choosing right “O”, either go #Outcome or #Output. What will you prefer without reading this blog, Output or Outcome?

 

Let me take you two decades back when there was a need for transformation. Transformation from big-bang i.e., #waterfall to iterative i.e., #lean, to meet business needs continuously, early on and focus more on the business value (i.e., #netbusinessvalue). Conventionally building a product using a big bang approach was the norm. Based on lessons learnt and maturing project management practices there was a pressing need to fine tune operating model by being Agile, Iterative and Lean. Focus shifted from “long wait” to “short jump” to get business value #ADOPTOUTCOMEDRIVENCULTURE. Lean principles brought a major shift in approach from Push (Waterfall) and Pull (Agile).

 

Agile - Art of Grooming using Intelligent Lean Engineering.

Agile: Client Value (#Outcome) + Velocity through Operational Efficiencies(#Output)  

 

Agile is sometimes perceived to have intangible benefits because most of us do not use right measure(s) to gauge the success of Agile. Tuning to the Agile practice is all about change in mindset to bring #AGILITY in processes and execution practices. From my POV fundamentally Agile is based on 2I’s and 2C’s (ITERATIVE, INCREMENTAL, CUSTOMER VALUE (#Outcome) and CONTINUAL PACE (#Output).

 

 

Let us understand who all are the key stakeholders in Agile Scrum methodology. For Scrum, we have Product Owner, Scrum Master, Developer and Testers. There is a reason for each of these stakeholders to be in Scrum. Here is the rationale why we need them:

• Product owner:  Get the right product (Key objective is to drive #Outcome)
• Scrum Master: Get the product on time (Key objective is to drive #Output)
• Developer\Testers: Get the product right. (Key objective is to focus on #Quality)

During my discussions with Agile coaches and Scrum masters in various formal and informal forums, first measure of success is always defined as Velocity by majority of the Agilest. To me this is one of the biggest blooper by any Agile SME. My 2 cents, we should never ever measure Velocity as the measure of success for any Agile project. Expecting continual high velocity from scrum teams is like pressuring team to pick pace where as we should focus solely on Business outcome. For Agile model, we do not have to balance factors like Schedule, Cost and Quality equally but being Agile we should focus primarily on # BusinessOutcome. Typical KPIs tracked to measure the success of Agile by Scrum masters are as below:

• # of story points delivered by individuals.  
• Overall Sprint Velocity.
• # of defects per sprint.
• Burn Down chart
• Burn Up chart

As per 11^th Annual State of Agile Report, “Velocity” is the top most measure of success for Agile projects, followed by Iteration Burndown, Release Burndown and so on so forth before “Business Value Delivered” really get attention and assumed the importance of measure of success at 12^th level in order. This clearly depicts there is a major scope of improvement and change in mindset to deliver goals why we should adopt Agile.  Refer snapshot below which is published by as 11^th Annual State of Agile Report by VersionOne.

 

This calls for a corrective action and requires organizations to focus Business Value i.e., #Outcomes and stop driving #Output based delivery. Most of the Scrum based projects fail to delivery Minimum Viable product sprint on sprint, because industry measure velocity as the measure of success rather than outcome i.e. business value. This approach defeats the whole premise of adopting Agile. Many projects started naming it #HybridAgile where Project managers or leads in the name of Agile stopped producing basic documentation be it Functional Specification or Design specification required while executing it in waterfall model. Team started to struggle because of this and quality got impacted badly. Per my view and experience there is nothing called “Hybrid Agile”, either we should go with “Waterfall” or “Agile” but should not mix and match practices as that creates gap and chaos. There are different school of thoughts and hence few SMEs might not agree with my thought process and it is up to an individual to be comfortable with whatever they pick and practice.

 

Here are certain techniques and tips organizations should adapt to execute # ValueDrivenAgile i.e., OUTCOME Drive Agile.

• Scope Management by Product Owner.
• Identify and Measure Business Value Objectively.
• Stop running Agile projects with Project Managers.
• Use Agile Management Tools.

Scope Management by Product Owner.

As highlighted above, it is the sole responsibility of the Product Owner to define and prioritize Value Driven Epics or user Stories. PO should liaison between business and Scrum team to help bridge business gaps. PO should help teams understand the business objectives and enable team to focus on Outcomes.  
 

Product owner = Get the right product (Key objective is to drive #Outcome)

 

Identify and Measure Business Value Objectively.

Product Owners while doing the scoping should give weightage and % to each Epic based on Importance and Value that Epic/User story will add if delivered. Let me help you understand how to do it with example.
 

Let us assume for a specific release there are 5 EPICs identified by Product Owner.

 

Let us assume these all EPICs and User Stories to be delivered in 3 sprints, and at any point in time if US1, US4, US5 and US7 were delivered what business value is delivered. It will be 22% of the business value.
 

Either there is a gap how product owner explained the business value or Scrum master did not prioritize right user stories in order. If team would have delivered US3 and US8, business value would have been 65% which was approximately 40% higher than what is delivered now.
 

Crux is Product owner should clearly provide weightage to each EPIC\User Story based on business Value delivered and Scrum master should prioritize in early sprints, keeping dependencies in view.  
 

Stop running Agile projects with Project Managers.

Let Agile project be executed and managed by Scrum master who understand the basic principles of Agile and try to practice and empower cross functional team to pull prioritized user stories in orders. Do not measure velocity and question individuals if it is low. Do not focus on “Speed of Delivery” and “Velocity”.
 

Use Agile Management Tools.

Leverage Agile Management tool, there are plenty of tools like Jira, VersionOne, Lean Kit, TFS agile etc. Important is to configure them correctly and not to use it for managing swim lanes progress only, which can be done by Post It on board. Leverage other features for Agile and derive and measure Agile metrics out of the box. Do not focus on any single measure, look holistically to get the right progress and decision making.  
 

Let me conclude this blog by calling out, Agile is Value Drive Methodology hence focus should be on Outcome Drive approach rather than Output Driven. With so much of momentum and opportunities around Agile, it is important to focus on right measure i.e. OUTCOME. This goes with the first agile manifesto “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
 

MEASURE AGILITY WITH OUTOME.

 

Thank you
Outstanding Outlier: “AG”