Are they the seeds to be nurtured to bring in automation, innovation and transformation. There is a saying, necessity is the mother of invention. I would say, innovation is amalgamation of creativity and necessity. We need to understand the ecosystem, to apply creativity and identify the ideas to bring in change. We need to be competent with changing ecosystem and think beyond the possible. What is the biggest challenge in doing this? "Unlearning and Learning", we think the current ecosystem is the best. Be it health, finserve, agriculture or mechanical domain, we need to emphasize with the stakeholders, to come up with the strategy to drive. The very evident example here is the quality of life is changing every millisecond. Few decades back the phone connection was limited to few, but today all the millennials are having a mobile phone. Now phone is not just a medium to talk, but are so powerful devices that an innovative solution can be developed on it.
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 11th
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 12th 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
11th 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”
Outstanding Outlier: “AG”
Comments
Post a Comment