"Tell me how you'll measure me and I'll tell you how I'll behave. If you measure me in illogical ways, do not complain about illogical behavior." -Eli Goldratt
Measuring things can be difficult when it comes to complex systems and things like agile adoption. Metrics are interesting, but it has a terrible reputation. When we say the word metric, most people roll their eyes. This is because agile adoption is about improving the entire system for all future outcomes, not just one specific thing. In other words, this is a core investment, and these types of investments take many years to pay off. Most people feel they're either forced to do it, or their manager makes them do it. For some reason, people have no idea why and what we are measuring, especially with C-suites who want to know the ROI but have a hard time understanding it. Leaders want to hear about percent completed, utilization, and some earned Value metrics. So it is not just about the return on investment. We have to teach them what kind of return they can expect. You may have noticed that when the runner finishes or the swimmer finishes, the first thing they do is look up at the clock. Well, they're probably looking up to see if they won, but they want to know if I improved over the last time? These metrics should be viewed as a tool or feedback loop for them to use to improve.
To handle the above challenges, I have used a Goals Questions and Measurement (GQM) (https://en.wikipedia.org/wiki/GQM) method to align and help leaders understand the value of Agile adoption. Whether you are focused on the team level, the program level, or the organization as a whole; GQM can help you clarify what you are trying to achieve, the questions that need to be answered to know if you've achieved it, and what metrics allow you to measure your success. We create GQM for each domain at every level.
GOAL: A goal is defined as an objective, for a variety of reasons to improve the performance:
- Products: Artifacts, deliverables, and documents that are produced during the system life cycle, E.g., specifications, designs, programs, and test suites.
- Processes: Software-related activities are usually associated with time, E.g., specifying, designing, testing, and interviewing.
- Resources: Items used by processes to produce their outputs, E.g., personnel, hardware, software, and office space.
QUESTION: A set of questions is used to characterize how the assessment/achievement of a specific goal will be performed based on some characterizing model. Questions try to describe the object of measurement (product, process, resource) for a selected quality issue and to determine its quality from the selected viewpoint.
METRIC: A data set is associated with every question to answer it quantitatively. The data can be •
- Objective: If they depend only on the object being measured and not on the viewpoint from which they are taken, E.g., number of versions of a document, staff hours spent on a task, size of a program. •
- Subjective: If they depend on both the object being measured and the viewpoint from which they are taken, E.g., the readability of a text, level of user satisfaction.
Goal: Reduce the training expense by 10%
Questions: What is the current training expense? What is the budget cut for training for this year.? What is the morale of an employee after the training cut?
Metric: Metric % budget cut for the year x, % of people leaving the org because of not able to get training.
Another example image is Attached (Sourced from https://slideplayer.com/slide/5119730/)
How to Align on the Goal:
A key success factor in any Agile adoption is understanding WHY Agile – why we want "Agile". What do we really want?. The goal here is not to implement agile but. When we are talking about return on the investment, we need to understand what kind of return the leaders are looking for. It may change from business unit to business unit. So the first thing is to Align leaders on what kind of returns they are looking for. Agile adoption is generally about people behaving differently to create value for customers. To measure the adoption, we need to understand what behavior changes we are looking for.
Michal Sahota explains a very powerful Why workshop in his blog (https://shift314.com/agile-is-not-the-goal-workshop/), which talks about bringing all the leaders together and aligning them on the return they are expecting. The ROI of going agile depends on what you're trying to achieve. Most of the time, leaders will come up with these high-level goals but having them pick what problem we want to pick helps us focus.
Once we understand the goal, we can ask ourselves at what speed we are achieving our Strategy, and finally, how we know, we are successful. What are the leading and lagging metrics against that goal?
Another helpful question can be:
- Do we have the right system of delivery?
- How our product management is aligning with Strategy? Can we confirm that we're doing Strategy articulation right?
- Are we funding the right problems?
- How do we do corporate governance right and corporate compliance at scale?
- Do we have scalable enterprise architecture and technology
- How do we increase the capabilities of our talent?
- How are we nurturing our Culture
- How we are increasing the capabilities of our leadership
Let us explore what can be done at each level with an example:
Let's assume that our goal is to achieve predictability, or is it predictability supposed to help us achieve some other goal? It can be a goal by itself. But if you look at those other business drivers like early return on investment, for instance, innovation, you know, quality, things of that nature. To improve perdicatbility, the program layer has to create a healthy backlog, and teams have to create a goal of meeting the commitments. At the program level, we can measure the engagement and how many stories are ready to be developed state, and at the team level, what % we are meeting our commitment.
At the same time, combining it with The three measurement domains can help create a system of improvements at every level (Portfolio, Program, and team). These domains are:
Outcomes: Do our solutions meet the needs of our customers and the business?
Flow: How efficient is the organization at delivering value to the customer?
Competency: How proficient is the organization in the practices that enable business agility?
Creating a maturity model showing improvements in each area helps leaders understand the return on the investment. Image Attache to show why maturity Assessment is required(WhyMaturity.jpg). This also allows Leaders insight into health from a team to an organizational level; they will be better able to see trends across the company and find organizational impediments. A sample Maturity Assessment area can be seen in the image (Maturity Assessment)
To conclude, the reason a lot of people struggle with answering the ROI of the agile adoption is that they don't even have an understanding of why they're implementing agile. They haven't figured out what problem it's supposed to solve. It is like I have bought a tool, but I am not sure what the tool is supposed to make better, and so that makes me wonder how they would measure it. The key to satisfying the needs of stakeholders while ensuring the team is healthy - effectively "enriching the organization" - is gained by combining multiple aspects in measurements and relating them to each other. GQM is the way to help clarify the ROIs the leaders are looking for and help them realize the value agile can bring.
“Mom, Why I have to go back"”
My son asked at the reopening of school’s post pandemic.
took my son out of cocoon where he was told to participate in group dance to put a show in 9 months. I was surprised to learn kids reactions as some of them were anxious, some were crying that I want mommy. What I loved about the teachers were that they created psychological safety and learning cannot happen without psychological safety. Never matter how much frustrating the class went; at the end of the class every single child got a chocolate and a sticker. My son started looking forward, developed new micro habits and over time I noticed evolution. I was surprised to see that in nine months they prepared a great show which was acknowledged by all. Through that I got a Return on investment of learning, and could see my child grow through it, became confident that he could do something he was not good at.
Ohh, I mentioned Return on Investment. So, what is Return on Investment or ROI?
When you put money into an investment or a business endeavor, ROI helps you understand how much profit or loss your investment has earned.
Why we want to pursue ROI?
As an Agile enthusiast, we started on to agile journey and faced bunch of challenges and applied techniques to address them. This urges us to ask whether our investment worth of.
Companies are dying, because there is no concept of delivery of minimum viability, lot of waste and rework, bad risk reward decisions. So, businesses go for agile transformation.
Learnt through a book called “Value for money “by Wiley.
ROI methodology is the most used evaluation system in the world. Endorsed by United nations in 2008.
Agile adoption over traditional method
Over the past decade, agile has become the cure-all to improve software delivery. Agile adoption is now almost universal: “15th Annual State of Agile Survey” findings indicate significant growth in Agile adoption within software development teams, going from 37% in 2020 to 86% in 2021.
As we aknow that there are numerous benefits of agile adoption as value helps in calculating ROI. Attachment as Value.png and Risk.png shows the comparison of Agile and Traditional Development.
We seek to improve project and portfolio return by focusing on fundamental elements as below :
Reduced WIP + Reduced Waste + Reduced Risk + Reduced Project Investment = Increased Project and Portfolio return
Therefore, agile over traditional software development helps to squeeze cash out of work in process, drive risk out of the project and increase project and portfolio return.
Traditional methods lockup capital as cost goes in different phases of SDLC as shown in attachment Traditionallockupcapital.png
Typical IT project Cash Flow attachment as Cashflow.png and how chunking resolves this attachment chunk.png
Agile portfolio approach gives better view over budgeting attachment AgilePortfolio.png
How to calculate ROI ?
As a financial executive if we need to calculate ROI of Agile adoption. A fair question “When adopting Scrum to the fullest what will it bring?”,” How much money does a company gain over cost? “
David Rico reported Agile methods have an ROI that is four times than traditional methods. However, data is of an indicative nature.
Let’s get into actual business of calculating ROI
Parameters to consider for ROI
- Project delivery timelines
- Value delivered to the customer
- Improvement of team efficiency
- Reduction of waste
- Payback period
Attributes used for identifying ROI of Agile:
- Value delivered to end user / customer
- Achievement of Business goals
- Reduction in cycle time
- Reduction of costs, defects, waste, delays in the organization.
- “Breakeven point” i.e., the point where the value generated covers the costs incurred on Agile transformation.
ROI a measure of cost and value. Value can be measured with respect to the aspects ie Happy employees / customers, shortened cycle , flexibility, higher quality and so forth.
- Value Delivery
With Agile you deliver value early and often so from value standpoint customer get it sooner (value points delivered)
2. Time to Market
This is basically shortening of the concept-to-cash timeline.
Metrics: Burndown/Burnup charts
3. Increased agile maturity
We measure this in our organization by preparing a due diligence report by rating various aspects mentioned in the attachment report below.
Metric Attachment: Due Diligence .xls
4. Assess customer happiness and product quality
Amount in which end-users , customers are happy with the results delivered. Keeping customer at the center of our efforts ,testing the validity of our assumptions by regularly releasing work and obtaining feedback. Customer feedback surveys are sent to track steady revenue growth as well, the number of support calls ,their happiness index etc.
Attachment: Usersatisfaction.png, quality.png
5. Increased delivery reliability and project Visibility
This is basically sprint predictability. We propose to measure this benefit by measuring the percentage of stories (or story points) that teams have forecasted in their sprints that have been delivered.
Metric: Project Plan, Release plan. Risk Mitigation report
6. Employee satisfaction
Happy employees are better connected to the company and are more productive. Happiness metric survey used in our organization to measure this as happiness.xls
7. Increased velocity
Propose to measure the cost per story-point delivered. If we also measure the value delivered per story point, we can continuously monitor the return-on-investment.
Productivity metric: Burnup chart
8. Plot Costs and Risk
Early feedback in agile reduces the risk. Cost increases due to risks because unlike in agile there is lack of information, inaccurate estimates and schedule, unplanned change.
Also, there is benefit realization risk.
9. Check Engagement of people
Intrinsic motivation is compelling where teams can shape the work and work in a self-directed way, engagement, creativity, and productivity go through the roof.
10. Adaptation to landscape
Agile brings transparency and empirical data. We can use this to focus on only what is important and limit having too much work in progress.
11. Net Promoter Score
At the end of the day, what matters is whether customers will recommend your company’s product or services.
12. Cost per Call
Ability to make better and higher quality software with fewer defects, better usability, which should ideally result in the customers having fewer problems to report.
13. Reduced Total Cost of Ownership
TCO accounts for the lifetime cost of the product, including maintenance, enhancement, and support. In many cases, this accounts for 60-90% of TCO, making the development cost looking minimal. By only developing features customers care about, we can repurpose investment into more product places.
14. Market share
Combining all the above effectively tends to result in increased market share and eventually market dominance.
Other KPIs to measure value is:
Usage index: usage index of different product features, we’re able to measure what’s valuable to our users to help in priortisation and higher ROI.
Innovation rate: Capacity of a team to build value-driven features versus non-discretionary work like detect fixes and application support.
On-product index: Efficiency of how a team is run and contribution to product’s growth.
Installed version index: Measures the number of versions of an application that require support. Each supported version increases the required support needs, thus lowering a team’s ability to focus on value-driven features and innovate.
Monetize these benefits by simple scale for measurements and then transparently share the value scale with bill to get a clear sense of ROI.
ROI formula = Value/ Cost
Steps to calculate ROI used in our organization :
1) Stakeholders estimate value of each item in product backlog using say value poker or whatever method that looks more deemed say i1, i2 , i3.
2) Dev teams estimate the size of Product backlog i.e., i1+i2+i3 say P and their likely velocity each sprint say v.
3) Divide size by velocity say P to get the projected number of sprints say s.
4) Divide the total estimated value of the Product backlog by the projected number of sprints i.e., P/s to get projected value per sprint i.e., vsp
5) Estimate the cost for funding each sprint (considering team size, salaries, fix costs etc.) as c
6) Projected ROI per sprint = projected value per sprint(vsp)/estimated cost i.e., vsp/c
Warren Buffett quoted that “There seems to be some perverse human characteristic that likes to make easy things difficult “.
So with that respect we tend to think too hard around ROI, its calculations and related stuff when things are quite apparent.
Please refer to the mindmap,I have created, Agileathon solution 1.png for a quick reference.
Agile being the mindset , measuring its Adoption for any project or any organization is tricky.
ROI of Afile adoption is measuring how well and how much the methodology is implemented during the transformation. Focus needs to be on measure than expectation and stereotypes.
The very first challenge is to call out the parameters underwhich it will be considered. A few being
- Business value and benefits - The value it adds to the company and the benefits associated with it
- Customer benefits - the benefits and usage of the product for the user /customer
- Project needs - Nature/Design and architecture of the project
- Investment needs - Capacity planning,Skills needed and resources
- Market trends and needs - Trending technology and solution in market and its competiotion
Once the parameters are identified and mutually agreed to , different metrics can be used to achieve the same.
- Cycle time - Time taken for the ask to become a requirement and eventually a product
- Development cycles to be shorter with workable product being delivered increasingly in phases during sprints/cycles
- Quality of the delivered product to be observed thrugh Defects matrix, its priority,severity and bug leaks
- Number of sprints to deliver the expected actual product
- Committed Vs Delivered /Do -Say ratio decides the velocity of the team to achieve the goal defined
- Self organising teams to collaborate to achieve the goal together through development and scrum events .
- Impediments raising,tracking and its resolution
- Business value increase , backlog getting added for the product and its prioritization
- Breakeven point where the value generated covers the cost incurred for tranformation
- Continous improvement with retrospectives,customer feedback and hence automation
- Happiness metrics to check the pulse of the team and team member burn out
All these collectively are evidences to arrive at the conclusion for the ROI of the agile transformation
Case study : Swiggy - IF wiggy was to follow waterfall for every feature , during the lockdown to minimize the restaurants delivery or to stop it , they had to close down the app, while they chose agile to just grey out the restaurants or create a separate list based on the zones and display it with a generic message indicating it. All these were done within hours catering to the above metrics/evidences. The cost incurred to do this was minimal compared to the impact they created and time to reach their vast customer base.
Cycle time - less than 2 hours
Development cycle - few hours
Quality - Automation and strategic testing to deliver bug free
Business value increase - quick yet impactful and faster than the competitors.
Breakeven point - minimal
Happiness metric - Good , with clear call outs and skilled labour
Continous improvement - Fast to market and then stedy improvements and enhancements to it
With all these calculated properly with right mindset and expectation the ROI is well translated for Agile transformation.
Return on Investment (ROI) is an important as well as crucial profitability metric to evaluate any project acquisition and it is part of cost benefit analysis. Irrespective of any life cycle model, organization is keen to define unique business model to define proper cost structure and revenue streams. ROI helps the organization to achieve financial independence through generating necessary cash flows and that leads to profitable growth.
According to investopedia, ROI definition:
Return on investment (ROI) is a performance measure used to evaluate the efficiency or profitability of an investment or compare the efficiency of a number of different investments.
Let us discuss, how ROI can be measured in Agile projects.
ROI Calculation for Agile Projects
One of the important aspects for Agile adoption is to respond faster (deliver value to end users) to the changing market demands and needs iteratively and incrementally. So it is important to gain profits incrementally as well.
Hamilton-Walker goes on to assert that one of the biggest benefits of developing software in an iterative or agile way,
“… is that you can start realising the benefit of your work before the project is officially ‘finished’. The objective is to front-load the project with the most profitable or highest value deliverables and release them as soon as possible so that they can start making money for you. If you’re using a Lean approach, you’ll release them as soon as they’re finished, if you’re using a Scrum approach, you’ll cluster a few into one (or more) releases at the end of each iteration.”
Refer “Figure4”, explained by SAFe consortium.
Scott Ambler + Associates (SAA) is a boutique consulting firm that specializes in helping organizations adopt disciplined agile strategies, particularly at scale. Scott Amber has done a survey classifying the approaches into Agile, Lean, Ad Hoc, Iterative, Traditional in 2013
The results shows that software development through iterative methods, Agile and lean helps the organization to reap ROI effectively. Refer "Figure1.png" for the details.
As everyone is aware, formula to calculate ROI is: (Profit/investment) * 100. In terms for Agile language, it is (Value delivered/investment) * 100. It is very crucial to calculate "value" as it forms the basis for Agile projects. The value can be measured in Agile projects through various methods. Even before that, it is very important to identify the features that creates an impact among end users. The steps are explained as part of "Figure2.png"
Let us understand few terms before proceeding further:
- KANO model -> This is one of the models can be used by product owners to cluster and differentiate stakeholder requirements w.r.t customer responses in four buckets:
- Basic needs -> Must be there
- Exciters -> to gain customer delight
- Performers -> to stay competitive
- Dissatisfiers -> that would make customers to feel disgusted
- Indifferent -> customers won’t bother about few features
Hence it is important not to invest on “Dissatisfiers & Indifferent’” features because that would lead to zero profits.
The next step is to assign value to the prioritized features. We can apply 2 methods:
Method1: Assigning business value based on below usability and user experience factors:
- Ease of use
- Joy of use
- Image of use
Method 2: Weighted Shortest Job First (WSJF) and this is defined by SAFe consortium. Formula is listed for reference alone
WSJF=(Cost of delay/job size or duration) and Cost of delay = UserBusinessVaue + Time Criticality + Risk Reduction and/or Opportunity Enablement.
Once value is determined, calculate the investment cost for that feature. Investment cost includes fixed costs, variable costs, economies of scale, economies of scope..etc
What does “value” mean would differ from company to company and it can differ from one project to another project within same organization. So, it is very much important to identify what does value to any project and then choose the method to define value.
Once value is determined, calculate the investment cost for a particular feature or overall product development. Investment cost includes fixed costs, variable costs, economies of scale, economies of scope..etc. While calculating the investment cost, ensure to consider overall Agile product development cost including infrastructure costs, any specific investments w.r.t certain features..etc
Case Study -> Experience sharing
In our company, we had launched several initiatives towards organizational agility. Though it is obvious that impact has been created within the organization, management wanted to know actual business value delivered to the participants and how it supports the organization holistically. So we worked out a model to measure the value created by these initiatives quantitatively. We have derived one formula and it is explained as below:
At the end of every session, small survey is hosted to measure how much learning can be applied in their daily work and thereby they can increase their productivity. The participants have to choose any one number from Fibonacci series “0,1,2,3,5,8,13,20”.
Fixed factors to calculate business value:
- Working hours per day -> 8hrs and in minutes, it is 480.
- Rate of one hour in USD -> 8$
Let us assume, 5 participants have chosen 0, 10 participants -> 1, 5 participants ->2
Improvement in Productivity (%)
For one participant
Total Effort saved in Mts
300 (productivity lost for 5 people -> no effort saved)
4.80 ((480 * 1)/100)
48 (effort saved for 10 people)
48 (effort saved for 5 people)
Cumulative effort saved in hours
((48+48) -300 )/60 => -3.40
Cumulative business value per day
-3.40 * 8$ => -27.20$
Cumulative business value per month
-27.20$ * 20 working days = -544
This shows that organization has lost 544$ due to this initiative. Similarly, business value is calculated for all the initiatives and ROI is calculated against the effort spent by organizers.
Calculating ROI in Agile Projects -> points to be noted
- It is important to define the granularity level for calculating value to a requirement. Identify whether value needs to be defined at Epic/Feature/user story level.
- How to scale up ROI -> at project/portfolio level. In waterfall, this service is done by PMO but in Agile it is expected to be done by Product Owner and hence it is important that PO is aware of all such business knowledge
- Impact of cost of dela.ying a feature needs to be analyzed proactively and must be considered during product backlog prioritization.
- Ensure to re-assess ROI at regular intervals because scope gets changed during software development.
- Measure ROI post every delivery and observe the trends. Necessary measures should be taken to prevent huge loss.
In waterfall model, ROI started to happen after few years from the date of product release. In Agile, ROI can be achieved in accordance with release cycles by focusing on delivering needed features to changing market needs. “…75% of organizations with high agility report a minimum of 5% year-over-year revenue growth… compared to only 29% of organizations with low agility.”-- Project Management Institute
To be explained in simpler terms, both Bhalla and Baahubali gained enough strength and skills through learning from childhood and they reaped ROI during the war whereas Baahu just taught one skill (using 2 arrows at a time) to Devasena to handle the current situation and ROI started to happen from that moment onwards -> Refer "Figure3.png". Hence delivering right set of features "Just-In-Time" is important in Agile projects to reap ROI.
Based on the recent Annual State of Agile survey, Agile has become the cure-all to improve software delivery and Agile adoption is at an all-time high now. Stats show that companies are making huge investments in optimizing the ROI in the search for profitable organic growth. And most companies are now focusing on customer experience. But how do we know if our Agile ways of working is giving us right Return on Investment (ROI)? How to quantify the value of Agile adoption?
Agile manifesto says ‘Our highest priority is to satisfy the customer’ but in this highly competitive world a mere customer satisfaction is enough? I strongly propose a change to the 1st principle of Agile manifesto.
Our highest priority is to delight the customer
Because satisfaction means joy/happiness, but delight means extreme happiness.
If your customer is satisfied with nth version of your product, then customer delight is giving nth version with icing on the cake on time with great quality.
I talked about ROI of Agile adoption, and I am also covering customer delight.
What is the connection here between ROI of Agile adoption & customer delight? If organizations can aim to delight customers (not just satisfy) then we automatically get greater value & ROI because they love our products, they refer and bring in more business.
What is Return on Investment (ROI)?
In financial terms, ROI is an indicator that describes the monetary efficiency of any initiative. The purpose of calculating ROI is to validate and make informed decisions about the purchase of a product or a service.
What is the ROI of money spent on family vacation? We may not quantify it, but we value it more. So in this context, Value and ROI are different, and ROI can be one part of value (attached pic). Here the value that I refer is not just quantitative but quantitative + qualitative value.
What could be the ROI for agile adoption other than money?
Employee Happiness, Customer happiness, Collaboration, Focus etc.
I strongly believe that anything can be evaluated by asking these simple & straight questions like
- Who – who want this? (desirability)
- Why – why do we need this? (value)
- What – what is it about? (usage)
- When – when can we use it? (frequency)
- Where – where is it available? (availability)
- How – how do we deliver it? (feasibility)
Return On Investment (ROI) can be measured in different ways & at different levels.
ROI = (Net Profit) * 100% / Cost of Investment to develop a feature
Ex: A program incurred expenses of $250000 and outcome of program is $200000 growth in profits over a period of 2 years.
Total gain = $200000 + $200000 = $400000
ROI = ($400000 - $ 250000) / ($250000)) = 0.6 => 60%
Scenario of a Scrum team: Here is one of the ways of calculating ROI based on feature value:
- PO estimates the value of each feature
- Developers estimate the size of product backlog and their average velocity each Sprint
- Projected no: of Sprints = Size / Velocity
- Projected value per Sprint = Total estimated value of Product Backlog / Total projected no: of Sprints
- Estimated cost for funding in each Sprint = Team size, salaries, other fixed costs etc.
- Projected ROI per Sprint = Projected value per Sprint / Estimated cost per Sprint
While a method may work for one organization, and it may not be the size that fits all. Again, here we can be agile in our measuring ways i.e., inspect & adapt.
So, here are a few ways of measuring ROI of Agile adoption based on my experience which depends on the following: (attached pic)
- Time to market: Ability to quickly deliver key capabilities, services, or products.
Goal: Minimize the amount of time it takes for the organization to deliver value.
- Release Frequency: No: of releases per time period.
- Predictability: Likelihood at which a team produces intended outcome.
At Pega, we measure this to assess how predictable each team is in their delivery which is helping teams to assess the risk at release level. (Attached calculation reference and team predictability data)
- Usage index: Measurement of features in the product that are frequently used or rarely used. Ability to deliver solutions/features that better meet customer needs.
Goal: Maximize the usage
At Pega, we have dedicated teams to measure each product’s feature usage index. This helps us in analysing the no: of cases/leads and opportunities which helps us in making informed decisions as needed.
- Quality: Ability to deliver exactly as per customer expectations/wishes/wants
Goal: Improve quality
- Customer defects: Defects escaped to production which means which are not caught during development & testing.
- Defects Age or Mean Time To Resolve (MTTR): Average amount of time it takes from when a bug is detected and when it is fixed.
- Technical debt: Extra development & testing efforts needed later as remediation when quick & easy solutions are implemented now. At Pega, we categorize and measure this in couple of ways like
- Known technical debt: test cases which are candidates for automation but not yet automated (legacy base)
- Unknown technical debt: Once in a year, we have dedicated time in refactoring unused code or dead code or to simplify the code base.
- Feature technical debt: This is not technical debt but features which are most important but not prioritized yet for known reasons. We prioritize this atleast 10-15% per release.
- Cost: Total expense of time and money for the product including operational cost.
Goal: Reduce cost and maximize ROI.
This can be measured as total expenses and costs incurred for the product or system along with IT, infra, operational costs, billing per employee etc.
- Employee happiness: Analysis to gauge employee engagement, energy & enthusiasm.
Goal: Improve satisfaction and happiness.
Employees can feel safe only if the environment in the team is healthy and also they should feel safe to speak their mind. So, we at Pega use two ways in improving employee happiness. At Pega, we measure this on a quarterly basis and plan to improve the low scoring areas. (Attached docs: team health assessment and psychological safety)
Employee happiness = healthy team + psychologically safe team
Regardless of the approach, the key attributes for measuring ROI of agile adoption are:
- Value delivered to customer,
- Achievement of business goals &
- Reduction in cycle time, cost, waste, defects & delays etc.
But do not forget to consider time for learning, innovation, validation etc.
Now that we understood customer delight is the key to increase ROI but how do we achieve it? Start building a customer-centric organization with the focus on the following: (attached pic)
- Connect: Connect with your customer
- Develop: Develop emotional connect with your customer base (attached pic)
- Accelerate: Accelerate the delivery
- Zero complexity: Deliver products that are zero complex to use
- Maximize efficiency: Avoid waste and delays in delivering the intended outcome
- Retain & Improve: Retain and improve the customer base by delivering products with great quality and on time with icing on the cake.
- As per the goals stated in all the above attributes and factors, if we are on the path of continuous improvement journey then we can safely say and assure that we are on track to get the right ROI of our agile adoption.
Advantages of measuring ROI of agile adoption
- Customer engagement,
- Cultural alignment
- Reduced Total Cost of Ownership etc.
Research and stats show that most effective way to maximize customer value is to move beyond customer satisfaction and establish ‘emotional connect’ with customers so that they love our products, refer, and bring in more business. Companies in financial services, retail, health care and technology are now investing in research and big data analytics to get a detailed understanding of emotional connection to retain and to attract most valuable customers.
Emotionally connected customers not only generate greater ROI but also value. Improving customer value & delight requires prioritizing and managing investments that span multiple functions across the organization.
So, let us focus and build what customers truly value & customer delight can achieve greater levels of growth and profitability.
Most of my training’s start with an exercise (See attachment 1). I ask the participants to count the number of occurrences of letter ‘O’ in the given paragraph. I get varied answers ranging from 24 to 36. Now, for a requirement where there is only one possible right answer; we get different outputs. I ask them to treat this as customer requirement and then find out some ways to improve the situation (i.e. to reduce the variance and increase the accuracy). Some of the solutions I get are:
- Highlight the letter ‘O’
- Count row wise
- Sum each row and get total
- Select the paragraph
- Press ‘Ctrl+F’
- Replace ‘O’ with something and then you will get your answer in number of replacements
If you notice, we are writing some steps to increase the quality of output. In other words, we need some ‘PROCESS’ to be in place to improve the ‘QUALITY’ of output; OR ‘PROCESS’ helps in improving the ‘QUALITY’.
Agile is also one such process framework which aims at improving your product quality OR deliverable.
Increased QUALITY results in:
- Less rework OR More Productivity
- Higher Customer Satisfaction which leads to MORE business opportunities
- More Business opportunities to better employee benefits
- Happy employees lead to LESS attrition and many more…..
Therefore, ROI of an Agile adoption can be measured in many ways. But it is important to know WHY your organization is interested to adopt Agile. If WHY is clear, then HOW becomes easy.
So, WHAT is ROI?
With any investment, whether it is time or money, there is going to be a financial gain, loss, or break-even point. ROI is the analysis of this financial performance in the business world. Having the foresight to determine if an investment will result in a positive return allows you to make financial decisions that will ultimately help you successfully grow your business.
Hence, ROI = (Net Profit ÷ Cost of Initial Investment) x 100
Cost of Initial Investment for Agile Adoption = Cost of Hiring Agile Coach + Agile Coach Compensation + Cost of Training + Cost of Infrastructure changes or tools needed for Agile Environment etc.= $3.5M (for example)
Let’s understand the reasons on WHY Organizations adopt Agile and how ROI can they be measured.
- Improve Quality OR Reduce Defects: When businesses fix time, cost, and scope; the only thing developers have left to manage is quality. Agile fixes time, cost, and quality; and gives us the tools to vary the business and technical scope of the solution. You might not get everything you hoped for, but you can trust what was delivered.
Average cost to fix a defect = (Number of people * number of hours) * cost per person-hour
ROI = ((Initial cost of fixing the defects – Cost of fixing defects after Agile adoption)/3.5)*100
For example: (($5M - $3M)/$3.5M) *100 = 57%
- Faster Time to Market: Lots of folks that decide to go agile are pretty fed up with 18-month delivery cycles that quite often deliver the wrong products to market; one’s that our customers just aren’t interested in buying. The idea of two-week delivery cycles and quarterly release cadences is appealing. Our markets and our competition are just moving too fast; we’ve got to get better at getting working product out the door faster.
ROI = (Revenue earned in 3,6,9,12,15,18 months – Revenue earned in earlier 18 months)/3.5*100
For Example: ($500M - $350M)/$3.5M*100 = 4285%
- Increase Productivity: A team can deliver 50 story points per sprint but is doing only 35 story points due to various impediments. Practices such as daily scrum and retros help us focus on impediments and help team deliver more OR work at its maximum speed.
ROI = (Increase in number of story points * Revenue earned per Story point)/$3.5M*100
For example, = (1000*$100)/$3.5M*100 = 2.85%
- Higher Employee Engagement: Agile holds the promise of creating teams of empowered individuals. Teams full of people working on the highest priorities of the business with a shared sense of purpose. When agile is done well, it creates fun places to work. There is nothing quite like being part of a team of people working hard toward shared goals.
ROI = (Amount of revenue added in increase in employee productivity + Money saved from less absenteeism + Money saved from less turnover)/$3.5M *100 (See full details on calculation of employee engagement at https://www.15five.com/blog/employee-engagement-roi-calculator/)
- Early feedback from customer which means early risk reduction: Agile doesn’t treat risk as a separate area to be managed, Agile is risk management. By delivering early and getting feedback, we reduce the risk of building the wrong product. By focusing on architectural risk in the early sprints, we reduce the risk that we won’t have a solution that can be build in time. At least we’ll know it early. By continuously integrating and building defect free software, we reduce the risk that our stuff wasn’t built right just before we need to bring it to market. Tom DeMarco that said “Risk Management is Project Management for grown-ups”?
ROI = (reduction of risk ‘$’ – cost of control)/cost of control. Find full details @
(Source: https://www.cisecurity.org/insights/blog/the-one-equation-you-need-to-calculate-risk-reduction-roi) Agile adoption cost can be part of cost of control.
- Improve customer satisfaction: Building products our customers can use makes them happy. Being able to frequent add new features based on their feedback makes them happy too. As a software customer, I’m not sure there is anything worse than investing in a product that doesn’t work, doesn’t do what we need it to do, and not being unable to see any path forward for making it better. I’m willing to buy a first iteration product if I know it is going to do nothing but get better over time. As a matter of fact, it can be fun seeing the product emerge as the development team gets more feedback. Agile helps us build this kind of partnership with our customers, one where we are working together to get problems solved.
Customer Experience ROI = (Benefits – Investments) / Investments. Agile adoption cost is one such investment cost.
- Alignment: Agile suggests that we have cross-functional teams that support products. This is really a simple expression of alignment. People don’t usually ask for ‘alignment’, but they want connection between effort and real business results. Major delays happen due to communication and coordination challenges. With proper alignment we can reduce this cost of delay.
ROI = Change in cost of delay/$3.5M * 100
- Better Predictability: Most companies are bad at giving any idea of when they are going to be done, and what they are going to get the business for their money. The business has gotten to the point where they almost don’t care how fast you build something; they just need you to get predictable doing it. In the absence of predictability, we have no idea what to tell customer. With stable velocity practice in place, the planning and predictability becomes simpler. This is an intangible benefit of Agile.
Other intangible data we capture to measure Agile adoption are Agile transformation survey reports. (See Attachment 2 and 3).
ROI parameters can change over time. Factors that affect this change are:
Change in Vision
Addition of new customers
Shift in business goals
Change in legal/regulatory bodies
Change in strategy
Change in leadership
ROI is a lagging economic measure and may not be useful for measuring early-stage investment. Satisfactory definition of profit and investment are difficult to find. Business units having higher ROI and some other units having lower ROI are impacted differently by using ROI as investment selection criteria.
Finally, we need to be aware of using ROI as a performance indicator as you risk having it quickly become manipulated. All the above thoughts are entirely based on my personal experience and research. I strongly feel many organizations struggle or overlook the importance of establishing and assessing ROI. Agile coaches need to train and coach the leaders in this aspect.
“The aim of Good Investments is the ones that offer a high value product that is needed by the target market at a reasonable price and potentially fast ROI which part of the profits will be constantly used in order to improve the existing business and keep building positive image with charitable investments as part of the profits.” ― Manos Abou Chabke
Agile has taken over software companies around the world by storm. It is no longer just a software development methodology, but more so an idealogy, which has become the cornerstone for cutting-edge businesses. Agile is adopted not just as a means to increase efficiency, but also effectiveness, which means that software development companies, can deliver better value, and get it to the market faster. The benefits of Agile transformation are well known - happy employees and customers, shortened cycle times, decreased costs, increased revenue, flexibility, higher quality, shorter learning cycles and so forth. Given the extensive list of benefits, it is no surprise that ISVs are so quick to adopting agile.
But how does one measure the benefits of going agile?
- How can you quantify the value of the results we achieve and the work you do?
- How can you quantify hard to measure gains such as customer and employee happiness?
- How can you measure the value of direct effects, such as earlier product delivery from indirect effects, such as customer happiness?
- How much of an increase in revenue does a company gain and at what cost?
What is the GOAL?
When discussing the ROI aspect of Agile transformation, it would be a wise idea to focus on measuring results rather than expectations, since expectations tend to focus more on following operational protocols rather than value delivery. First, it is important to have an organization wide understanding of exactly what goals are expected from the agile transformation. Once you understand that, you should have a better idea how to measure whether the agile transformation has been successful or not. The ROI of going agile depends what you're trying to achieve.
Higher efficiency: If your emphasis or the key reason for choosing to go Agile is to be more efficient, you will likely see the results you expected. If your goal is to get the product to market sooner, you can consider comparing time to release. However, even though you may get the product to the market faster, this doesn’t necessarly mean that you will be able to increase revenue or product value. No matter how much you are reducing time or cost, the revenue metric is what ultimately determines whether or not you have a successful business.
Higher quality: When your goal is to improve the quality of your product, you can consider numbers that measure how many bugs were generated and reported compared to before the agile transformation.
The ROI of Agile Transformation can only be measured once the teams have been trained and gained the experience needed to be executing well. Expect to measure the metrics at the start, mid-point and end of the transformation to have truly accurate ROI.
- Cycle Time: Cycle Time is the time taken to turn a request or requirement into delivered business value (production).This is a very objective measure that can not be altered, is easy to measure and it has direct meaning to all stakeholders.
- Shortened development cycles: This metric takes into account the shortening of the concept-to-cash timeline. You can measure this by the time it takes from idea to solution and to which extent is this time has shortened since the transition to Agile.
- Increased Agile Maturity: You can measure this progress by the amount of sprints that deliver working and tested software, the extent in which business value is driving the product backlog ordening, and the extent to which teams are self-organizing and continuously improving.
- Increased business value: This metric is the amount of business value teams deliver from their sprints. You can measure this benefit by measuring the value output from each sprint and the extent in which this is increasing from the Agile transformation. Consider doing this with value points delivered (and the points to be defined by the Product Owner).
- Increased delivery reliability: How does the estimated/promised output compare to the actual output. Teams simply become more reliable in their predictions. As such the promises made to customers regarding future deliveries are better kept. Consider measuring this benefit by measuring the percentage of stories (or story points) that teams have forecasted in their sprints that have actually been delivered.
- Increased velocity: An increase in the velocity implies an increase in team output at the same cost. This metric can be measured per story point delivered. This enables you to measure the impact of Agile transition by the increase in the amount of work produced at the same cost as before. This also gives you a direct view of how the Agile transformation is impacting your bottomline or ROI.
- Customer happiness: How happy are your customers with the results delivered? This happiness metric is a tell-tale sign of how well your transition has happened and whether it has worked for your organization.
- Employee happiness: Happy employees are productive employees. How has the transition affected your employees? Are they energetic and excited about having such a transparent approach as Agile?
- Net Promotor Score: At the end of the day, what matters is whether or not customers will recommend your companies product or services. It’s a difficult metric to game and it focuses on customer value.
- Cost per Call: If you have a consumer facing product or any product that has a helpdesk, you should be lowering your cost per call and reducing the number of calls to your helpdesk because by going Agile, you should be able to make better and higher quality software with fewer defects, better usability, which should ideally result in the customers having fewer problems to report.
Going Agile has the power to reshape the productivity of your business and optimize opportunities for business growth. With the competitive edge it offers through its intensely collaborative and iterative nature to stay current in today’s fast paced environment, it should be strongly considered by every software development team. Once Agile has been adopted, measuring the impact of the transition to Agile should evolve over time. Initially organizations will do well to collect process-related metrics such as throughput, cycle time and so on. These will help identify what the other problems are and with a fair bit of trial and error, you will eventually discover the right business metrics to determine the ROI of the Agile transformation.
ROI (Return on Investment) is a measure to determine efficiency of an investment. In a financial world, this is typical calculated as a ratio of net income and investment. However, for an agile adoption, ROI is not only limited to financial aspect but also subjected to the Objective with which agile adoption was started i.e., Objective of an agile adoption, which varies from organization to organization, decides what ROI an organization is looking for. And hence every organization may have its own way to measure ROI of their agile adoption.
Having said that, I have personally been part of few such agile adoption and based on what I have seen, I can certainly say that few of the common objectives across such agile adoptions were on the line of – “Together become Faster, Better and Cheaper”. Now let’s see how ROI on these objectives can be measured followed by couple of case studies.
Faster - Faster means how fast and how soon can teams deliver working software to end user/customer. It can be primarily measured by 2 metrics – Cycle Time and Frequency of Time to Market.
- Cycle Time Reduction – Cycle time is calculated as median using the difference between the Start date and the End date. It’s a great measure to understand how agile adoption had helped to quickly deploy the working software into production environment.
- Faster Time to Business Value – Calculated as how frequently business values are being delivered as compared to pre agile adoption scenario. This helps in achieving greater customer satisfaction as teams can respond quickly to frequently changing business needs.
Better – Better means how are we improving on regular basis in term of our services to customers, robustness of our system. Few of the metrics to measure these aspects are – NPS (Net Promoter Score), Availability of Systems, Defect Reduction.
- Higher NPS
- Increase in availability of systems
- Reduced production bugs
Cheaper – This parameter is closely associated with the finite value of any investment and can typically be measured by 2 ways – had the agile adoption increased organizations customer count or for existing customer base, are we able to reduce organization’s operation cost.
- Increase revenue – Adding new customers or offer new products/services to existing customers
- Reduce Operational cost – Automate solution, reduce resources but still serve your customers with agreed commitments
Together – This is an important parameter which takes human factor in count. e.g., How many people in organization have learned new agile skills, what new avenues have been started to increase collaboration, how much support we have from senior management etc. Though this parameter may not always represent accuracy in terms of ROI, they can certainly act as an indicator of how deep agile adoption had gone into roots of organization and changed people.
With above few categories, here I am presenting 2 case studies – one is of a telecom giant and other is of a global bank. To keep anonymity, I have merged the details of these two in below table to represent agile adoption objectives and ROI parameters which are aligned to – “Together become Faster, Better and Cheaper”.
Actual Client Objectives
Like we calculate ROI for any investment , while adopting Agile (or Adapting to Agile ways of working) a successfull business would want to know the ROI this could generate for business.
While the fact could be easy to explain in summary, i.e. By moving to Agile ways of working, we are trying to Fail early and hence saving a lot, or getting a better ROI.But to define this "better ROI" we wil have to define what would be our attributes of measurments. Now these attributes would differ organisation to organisation on what they would value more, below are some of those :
- Value delivered to the end user/customer
- Achievement of Business Goals
- Reduction in Cycle Time
- Reduction of costs, defects, waste, delays in the organization
As the first step of any Agile transformation, an organization needs to understand where it currently stands from Agile readiness perspective. This helps the organization to know its current state, how well it is prepared to go for Agile, what are gaps it needs to bridge and investment required before it can move to Agile.
It is important for any organization to define the parameters on which it would calculate and review its return on investment. Only with clear and precise parameters, Return on Investment (ROI) of Agile Transformation can be identified. The organization can also use collaboration tools like Innovation Games to identify the current pains areas, which can be used while defining parameters.
Following are some of the parameters that can be considered for ROI:
- Change in project delivery timelines
- Value delivered to the customer
- Improvement of team efficiency
- Reduction of waste
- Payback period
In a nutshell, Once you know what are your targets of why you are moving to Agile ways of working (low cost, faster TTM, Less waste etc), they might be well inter-related and get you to better implementation.The next would be measuring how you're doing in your current process and then measuring in quick intervals of how you're on the path of improvement or the path of being Agile.
Thanks for reeading !
Traditional (Waterfall) Approach Problem Statement
We all can agree that Waterfall model in software development turned out to be inefficient in terms of time to market and meeting the ever-changing context as stakeholders’ needs evolve.
Given the traditional development model value is achieved after full development lifecycle, as shown below:
Initial system is evaluated or the business need identified.
Upfront elicitation of the system requirements from stakeholders that could take around 4 months.
The whole project planning, that could take up to several years, is done upfront:
- how the system will behave: features, tasks, intended processes.
- under what circumstances: non-functional requirements like “ilities” (reliability, etc.)
- what business need it will solve: intended users, line of business, outcomes.
Design, Development, Testing.
All these activities are done as planned ahead and no changes usually occur, moreover, they are usually suppressed. Also, low awareness of project completeness usually takes place that adds more issues.
Then what usually happens after a deadline, which is between 6-12 month or more, is:
- system is not ready upon a deadline: features not completely done, defects, bugs, etc.
- system does not do what is needed by stakeholders Now: cause rework, refactoring, etc.
- time to market increases dramatically as system is not ready and must be reworked
Finally, after failed deadlines, rework, additional costs, and loss of trustworthy and reliability system is delivered to stakeholders.
Maintaining and supporting system that probably lacking of structured documentation for support team because of all rework done ASAP.
Agile Approach Implementation Benefits and ROI
The value of implementing Agile approach is all widely known, so I will specify them with ROI factor for each.
Time to Market
One of the main purposes of Agile SW delivery is “to deliver working software frequently…”, as specified in one of the agile principles.
Agile enterprise may deliver a potential shippable increment (PSI) every release, that could be any period from 60 to 120 days (generally 90 days). This means that organisation can potentially release a working product (MVP) and monetise it within 120 days of project initiation.
This leads us to the first ROI measure that is Time to Market: delivered piece of product in a dramatically shorter time frame (up to 4 times quicker!) than with a waterfall approach.
Cost of Delay
In addition to Time to Market (TTM) I add Cost of Delay (COD) measure which basically refers to a TTM of a particular product feature.
Long story short, with Waterfall all features have same COD that equals the length of the whole product delivery time. When Agile multiple features are delivered in a PSI which potentially happens every 60 to 120 days.
Moreover, prioritisation come into the equation that could be based on things like: user value, decrease of his value over time, opportunity enablement/risk reduction. All these factors result in a COD for each feature that could influence things such as:
- Company’s market share,
- Customers acquisition and retention,
- Competitive advantages.
These is the second compound measure of ROI of Agile adoption by organisation.
Cost of Rework
As was mentioned above, with Waterfall approach high cost of rework (COR) occurs due to low alignment with the stakeholders in the moment of time. This problem is solved by short iterations (two to four weeks) ending with a customers’ demo of a working piece of software.
Demoing of actual working piece of software assure alignment with ever changing stakeholders’ needs by receiving feedback in a very short period of time compared to a waterfall model.
Frequent meetings with stakeholders and feedback loops bringing third measure of Agile adoption ROI – decreased Cost of Rework. I would add refactoring and bug fixing to this chapter as a benefit of iterative development.
Cost of Development
This could be quite ambiguous at the first look but given the standard Agile teams metrics like velocity and burdened cost of an iteration for a particular team we can easily calculate cost of a particular team that gives us better predictability of iteration cost by summing up costs all affected teams.
Given this, the relative high-level cost of release could be estimated and this will be a more precise cost estimation than a fixed budget of Waterfall approach which in most of the time is blown up to multiple times after rework.
So, I would specify this like a lower Cost of Development but I understand that lots of other factors must be considered and this is not the most precise ROI measure.
My list of ROI measures of Agile adoption is as shown below:
- Time to Market,
- Cost of Delay,
- Cost of Rework,
- Cost of Development.
While I believe other relevant metrics exist in my opinion these are most important ones for analysing the progress and evaluation of Agile adoption by the organisation.
- Agile Software Requirements by Dean Leffingwell.
- Agile Manifesto official website.
Agile adoption is not just about efficiency; it is also focused on effectiveness. By helping organizations going towards gaining more value (ROI is one such value), agile adoption changes the way output of any project is measured.
However, organizations need to understand what they are going to measure and why they want to measure it as an outcome of agile adoption. At the end of the day the measure of a successful agile transformation is: Has it helped the organizations achieve their desired outcomes?
As a scrum master, I have seen project doing transitions from hybrid to pure agile way of execution. As the measure of success, it was not only the ROI (revenue in numbers) that we as team tracked and measured. Other than this, we also tracked below matrices and found signification returns over the course of time:
- Continuous Improvement: Improvements from writing efficient codes to better project execution, and from more promising deliveries to optimizations in all aspects of business functions. ROI surely gets improved this way.
- Employee Engagement: Low attrition, self-motivated teams and people willing to go the extra mile saves so much of efforts and cost of hiring and engagement of poorly motivated team.
- Customer Satisfaction: "Everything we do is for customer satisfaction" and when they see position outcomes using your product or services, this is definitely an indicator of better business.
- Market Responsiveness: The ability of the organizations to ride quickly toward ever-changing market demands is possible only with agile transformation.
- Quality: The product or service meeting the expectations of the market for its purpose, usability and reliability is ultimate goal of organizations. When they save money by improving quality of their project/service deliveries, organizations keep the ROI in green (profits and increased margins)
Hope these points can help in measuring the success of an Agile Adoption.
Sprint1 : ROI of an Agile Adoption
Sprint Name : Sprint 1
Sprint Goal : Measuring ROI of an Agile Adoption
Planned User Stories: 9
As an Agile enthusiast I wish to calculate the Say-Do ratio or Commitment Reliability so that I can understand the contribution of this factor in the measurement of the ROI of Agile Adoption
In Agile Methodology, with Scrum framework, we use different iterations to deliver the product. For every iteration, we perform a Sprint Planning to plan the activities for that particular iteration. This way as a team we commit on the work items that we are going to implement in that Sprint which are aligned to the Sprint goal.
At the end of the iteration or Sprint, team understands how much they have achieved on what they have committed.
To calculate this, we can use the formula:
Say Do Ratio or Commitment Reliability = (Achieved Story Points/Committed Story Points)* 100%
If Team has committed for 40 Story Points and achieved all the 40 Story Points, then Say Do ratio is : 40/40 = 1 * 100 = 100%
If Team has committed for 40 Story Points and achieved 20 Story Points, then Say Do ratio is : 20/40 = 0.5 * 100 = 50%
This value helps in predict the future roadmap with a level of confidence.
This proves that with help of Agile adoption, we are able to understand the performance of the team Sprint by Sprints and also plan future work with confidence.
As an Agile enthusiast I wish to calculate the quick or short development cycles so that I can understand the contribution of this factor in the measurement of the ROI of Agile Adoption
In Agile methodology, with Scrum framework, we use iterations or Sprints as Development cycles. All these Sprints are of a length like 2 weeks or 3 weeks. At the end of the Sprint, always a Working product is delivered by the team. This working product is a shippable product. With short Development cycle, team is able to deliver a working product. This is also possible only in Agile methodology.
For this, number of shippable features that are delivered gives the clear picture in measuring the ROI of Agile adoption.
As an Agile enthusiast I wish to calculate the total Business Value that is delivered by team so that I can understand the contribution of this factor in the measurement of the ROI of Agile Adoption
In Agile Methodology, in SAFe framework, every Feature that is picked as part of PI (Program Increment) is given a Business Value. These Business Values can be set as 1 to 10, as 10 being the highest Business Value.
It is always important that we pick up high Business value Features because they also hold high priority.
Localization framework implementation - High priority and Business Value
Documentation support in Chinese - High priority and low Business Value
The first Feature is targeted for a global market, so the Business value of the feature " Localization framework implementation " is also high. Whereas the second Feature " Documentation support in Chinese " is targeted only for China market. Even though it is of high priority, the Business value is Low.
At the end of every PI, it is very important that we should calculate as a team, how much Business value we have delivered. This gives a clear picture of team's contribution in Business.
Delivery of Business Value calculation helps in measuring the Agile Adoption.
User Story: 4
As an Agile enthusiast I wish to receive the feedback from Stakeholders so that I can understand the contribution of this factor in the measurement of the ROI of Agile Adoption
Factors like Short Development Cycles, Sprint Reviews, Delivery of working Product adds extra credits when following Agile. To get the feedback from Stakeholders, it's very important to conduct a Survey with Stakeholders and understand their feedback. This feedback is one of the major measure in calculating the ROI of Agile adoption.
User Story: 5
As an Agile enthusiast I wish to calculate the Cycle time so that I can understand the contribution of this factor in the measurement of the ROI of Agile Adoption
In Agile methodology, in KANBAN framework, Cycle time helps in understanding the time taken to turn a requirement into Production. This gives a clear detail to Stakeholders on time taken and this helps in measuring the ROI of Agile adoption.
User Story : 6
As an Agile enthusiast I wish to calculate the Cycle time so that I can understand the contribution of this factor in the measurement of the ROI of Agile Adoption
In Agile methodology, in KANBAN framework, Throughput helps in understanding the number of requirements that got deployed into Production in a specific period. This gives a clear detail to Stakeholders on time taken and this helps in measuring the ROI of Agile adoption.
User Story : 7
As an Agile enthusiast I wish to observe the retrospective feedback of teams so that I can understand the contribution of this factor in the measurement of the ROI of Agile Adoption
In Agile methodology, in Scrum framework, we follow Retrospective meetings which help us in understanding the team's culture and how we are improving by following "Continuous Improvement". This also helps us in understanding at Org level, how as a team we are getting into the culture of self-organization. This also is a way to measure the ROI of Agile adoption.
Agile maturity at Team and Org levels are also helps in measuring the ROI of Agile adoption.
User Story : 8
As an Agile enthusiast I wish to observe the quality of deliverables so that I can understand the contribution of this factor in the measurement of the ROI of Agile Adoption
In Agile methodology, in Scrum framework, we follow different Quality Practices to enhance the code quality. As we are shipping small blocks of Products, it is also a good fact that we can deploy the quality practices easily than in deploying in bigger piece of software.
Measures like Code Coverage, Design of Unit Test Cases, Sprint level testing, Documentation coverage at Sprint level, CI/CD measures in deployment level helps us in ensuring the quality of deliverables.
Quality is also a measure in calculating the ROI of Agile adoption.
User Story : 9
As an Agile enthusiast I wish to observe the Product scope so that I can understand the contribution of this factor in the measurement of the ROI of Agile Adoption
In Agile methodology, it's easy to understand the defined scope of the Product with the help of the Product Backlog and what is planned for a release and if any changes all are tracked with the help of versioning tools in Agile Management like JIRA, Azure Devops etc.
Knowing what is the priority order and what needs more focus are additional features of Product Backlog.
So availability of Product Backlog in Agile methodology definitely helps us in understanding the scope and roadmap of the Product very clearly for all the Stakeholders, So this plays a major role in measuring the ROI of Agile Adoption.
When I decided to go for Scrum Master Certification I was very happy as If I would be able to get all the desired knowledge from my Mentor. After my certification I got an opportunity to be the Scrum Master of one of my Team in my Organization. I was going with values , Principle and Scrum Books. Initially it was good but with time I understood that there is no ready made recipe which can be used while working with Teams.
I would like to mention few misconceptions which came in front of me while working with Teams , Leadership and Management
- Firstly we are AGILE as we are following SCRUM - [This use to be delivered in the meetings , town halls ]
I used to think :- [“Mind Blowing” …but Is the SCRUM framework the only factor to judge that we are Agile. Are we actually thinking about the team health , Client expectations and Challenges ,
Leadership Challenges and the most important thing how the Organization is going to sustain in future and what Values are we bringing with the Agile Adoption].
2. Being Agile Vs Doing Agile was another common Hashtag in every forums and Articles inside the Organization
[As Scrum was Implemented so Being Agile is accomplished. Appreciate everyone in the meetings by saying - Thanks to everyone , we accomplished this much due to the efforts of the Team and everyone was knowing that actually the team is drained out in the releases and there is no motivation inside the team].
Luckily I was part of the Agile Community which consists of Agile Gurus and Warriors. We all knew that the actual Agent to change is the Current MINDSET of the teams who are working in the Organization.
The expectation was to be Agile with no implementation of Values and Principles only driving the releases with SPRINTS. Teams were not happy with Scrum Masters , Managers and the way of working so they hesitated in attending stand ups and refinements , thinking that meetings were just a waste of time.
The Agile COP group decided to work as one Team and the mission was to bring - Revitalization inside the Teams/ Organization. The idea of Big bang change was not possible in this situation but then Change is needed so we thought to bring Iteration level changes by creating a Roadmap of Changes. This idea was clear that we can't create Agile Teams in Non Agile Organizations as Agile needs good Mindset and Trust between the people to give Values to the Customer and satisfy Teams so there was a requirement to bring a workaround by going to the Hybrid Agile Culture and keeping stick with the Project/Product requirements.
Few System Problems which we emphasized to improve :-
- Inclusion and Diversity - Start with the Leaders and Top managers - Upskill the knowledge of each leader as they can drive the cultural change in the Teams. Leaders should talk in detail about bringing differences in Inclusions Like Gender , Country level changes. There should be more conversations - How can we make our environment more INCLUSIVE and how to continue to foster. Allow people the space to be vulnerable and they will not be judged too. This should be a daily practice to create your Team space very friendly and Allyship amongst each other.
- Started Programs to remove the Unconscious BIAS among each other by some activities and games. Each and every person should read on Bias theory - What should we do and What we not ? We should Inspect and adapt ourselves. Start from YOURSELF and then go to TEAMS. We welcomed excellent Coaches and Psychiatrist for giving sessions monthly and let the team talk with them.
- Created a different Program inside the Organization - Where people will stand up for Causes. When teams meet in small groups they interact more and this is how they will start COMMUNICATING with each other. For different programs funding was organized by the managers for the same and a sense of urgency was created by advertising it on everyday basis.
At the end each and very person should have that Zeal in bringing change in Organization. Organization who are not practicing Agile needs to start from somewhere and it is good to start with iterations. Most important thing each and every member should motivate not only others but self motivate too to go twoards AGILITY.
Most of us would have received this remark, “How you could think like that” either positively or sarcastically. The same with Agile projects in non-Agile organization. Let us understand about Agile and non-Agile(traditional) organizations as per the insights shared by McKinsey. The “traditional” organization (designed primarily for stability) is a static, siloed, structural hierarchy – goals and decisions are driven based on top-bottom approach, with the most powerful governance bodies at the top. It operates through linear planning, monitoring, and controlling the projects by project managers, group managers, department leader and to achieve project deliverables. The skeletal structure is strong, but often rigid and slow moving.
In contrast, an “agile organization” (designed for both stability and dynamism) is a network of teams within a people-centered culture that operates in rapid learning and fast decision cycles which are enabled by technology, guided by a powerful common purpose to co-create value for all stakeholders. Such an agile operating model has the ability to reconfigure strategy, structure, processes, people, and technology toward value-creating and value-protecting opportunities in volatile, uncertain, complex, and ambiguous (VUCA) conditions quickly and efficiently.
My experience (Bosch/India)
Towards Q3/2009, my customer counterpart division decided to create an integrated development environment for embedded developers using Agile methodologies. There were about 20+ components to be integrated as part of this product and all the components were decided to adopt SCRUM. Around 10+ components were to be developed from India and that’s where my journey towards Agile had started. In my company at that time, no one had worked with Agile and we were seen as lab rats :-) (Refer Figure2)
I have shared my experience based on the change model defined by Mr. Kurt Lewin. Refer the figure1 to get the details about the model.
Prepare & unfreeze -> Team onboarding
As a first step, entire team needs to be educated about Agile & Scrum and the requirement was given to HR. It took almost 1 month to train the team about the concepts.
Post training, biggest concern for me as a leader, how to make the transition only with 3 roles: Product owner, Scrum master & team. Because team including myself was very much used to the traditional titles like software engineer, specialist, expert, architect, associate project manager & project manager..etc. First, we shared the purpose of this transition clearly to the team to get their buy-in and the same has been displayed in the cubicles. Lot of visuals about Scrum and Agile has been displayed near daily meeting boards.
We did lot of mini workshops/meetups to setup the team and slowly figured out few ways to address their concerns w.r.t career path, performance discussions and brought a clarity to their responsibilities as per Scrum framework.
Prepare & unfreeze -> Setting up Artifacts & estimation using planning poker
As per waterfall model, it was very easy to decompose the requirements because there was clear process inside the organization established like requirement document review checklist, review procedure..etc. But all sudden, it was the PO and team have to groom the backlog based on stakeholder requests. So initially, team has struggled to define DOR including acceptance criteria for every user story and putting them into actions.
Another challenge is to enable the team to do the estimation in story points using planning poker. It’s kind of muscle energy to do the estimations in hrs/days without much effort. Also in traditional organization, estimation was done by senior member alone and developers were expected by that time somehow. With Agile, estimation was done democratically, and it has touched the ego of few senior team members and actually team went to storming stage ???? Then guidelines are defined by the team to estimate user stories in story points based on complexity and amount of uncertainty factors.
Step2 -> Change -> first 6 months
The infrastructure except automating the operations like continuous testing, integration & deployment, was made available to the team and team has started to deliver the results on sprint basis. The sprint duration is 4 weeks. During the transition, we need to meet organization needs as well as customer needs. Organization (our entity) were looking for below artifacts:
- Milestone checklist -> an excel with all features agreed for a particular milestone and it has columns to ensure RDCT is followed including review and rework. Every developer has to update this sheet and PM have to track it. With Agile, this was achieved through DOD. Nevertheless, quality team has demanded this checklist from Agile teams and ended up in double work.
- Metrics. Before adopting agile, we have tracked metrics like review defect density, test defect density, productivity improvement, %of doneness..etc. Post transition to agile, we have started to use burn down charts, sprint velocity to measure team capability, lead time..etc. organization demanded productivity metric at any cost and reverse engineering got applied to provide this data to quality team.
Step3 -> Stabilize -> Emerged as role models
What you are afraid of is never as bad as what you imagine. The fear you let build up in your mind is worse than the situation that actually exists -> Spencer Johnson
Within one year, team has matured to apply Agile principles and got experienced with growth mindset. By this time, many projects were adopted Agile and there was a strong need for the organization to enhance process, methods & tools to support various Agile frameworks like Kanban, Scrum, test driven development..etc
Obviously, the teams who were the early adopters called to share the experiences and I am part of core team to define process, KPIs, methods as well as rolling out various initiatives to create an awareness within the organization.
Now it’s officially declared to get rid of all the non-applicable metrics, milestone checklists and our scrum team had become the ambassadors to influence team members in other projects.
By this time, we have established continuous integration, testing & deployment and has started to deliver the value much faster to end users. In waterfall model, measures will be defined to fulfill minimum product quality characteristics like maintainability, reliability, robustness, ,.etc and we replaced this concept with technical agility and now we are heading to define the process methods and tool to support Full SAFe framework.
The other side of the story -> The road less travelled
In my case, my organization has started to adopt Agile in 2015 and all the struggles yielded great results to the projects as well as to the individuals. It can happen that only few projects would continue to be in Agile where organization won’t adopt Agile at all. In that case, survival becomes very hard. It is more like talking to the brick wall, kind of being lost in the crowd or becoming one of the roads less travelled.
- Team’s mission remains top secret
- Surviving with growth mindset becomes nightmare for SM,PO & team
- Command & control-ism Vs Servant leadership style -> confrontations & conflicts
- Ambiguity in career paths and multiple reporting structures
- At the worst case, sponsor would cancel the contract and business may go to our competitors
From our own journey, Agile projects in non-Agile organizations are emerged as trend setter and created a legacy within the organization”. Personally, I had an opportunity to experience various roles right from scrum team -> SM -> PO -> Coach -> Corporate trainer -> Consultants to quality team.
In the projectized organizations, though team member delivers the results and at the end, they don’t have a home base and it impacts sense of belonginess to the organization and we might lose great team members provided that their needs are not fulfilled. The same case with Agile projects in non-Agile organizations. These teams made the change possible and demonstrated value delivery by responding to the changes faster. Also these projects might end up in influencing other non-Agile projects to adopt few Agile practices like daily standup meetings, retrospectives and growth mindset. Hence, at any cost, organization should not make them to feel strange in their own territory. This will impact overall health of the organization.
Planning to do an agile project in a non-agile organization sounds like trying to prepare a pizza in a proper Hyderabadi biryani joint. You can convince the restaurant owner saying that pizzas are preferred choice over biryani among kids, they can be served hot and can be customized to need of the customer. But you will have challenges right from infrastructure set up, ingredients, tools, workforce, billing, customer expectations etc.
Similarly, when you run an Agile project in a non-agile organization, it comes with its own set of challenges. Let us go through some of them.
Before the start of the project
- Agile Contracts are different - The third value of Agile Manifesto states “Customer Collaboration OVER Contract Negotiation”. In agile environment we expect the Product Owner who is our customer representative to be part of the scrum team and must regularly collaborate with the team. Secondly, as per Bill Wake, a good story focuses on six attributes and they follow INVEST criteria. Where “N” – stands for Negotiable. We want to avoid creating User Stories that feel like contracts, with every detail specified in advance.
Hence, such kind of values/environment which helps us succeed in Agile makes and Agile Contract quite different from Traditional Contracts.
Unreasonable expectations and distracting confrontational relationship over scope are set in traditional contracts. Traditionally we practiced, fixing the scope and thereby deciding how much time and resources it would take. But in Agile, it’s completely paradigm shift where we fix the resources (dedicated scrum team which aids good results) and time (sprint 1-4 weeks) and then decide how much scope can be achieved. This requires a total mindset shift! – (Refer Attachment 1)
- Working with Support Functions - It is important to convey the implications of practicing Agile on other functions so that you get maximum support from them. Support functions such as HR, Marketing, Finance, Facilities must be kept well informed about the changes that Agile transformation can bring in the way they are going to perform their duties.
HR function may have to think about new ways of accessing individual performances. Scrum teams start out doing extremely well until annual review time comes around. Suddenly, everyone realizes they will again be assessed, and receive raises, based entirely on individual performance. The annual review might have one field for assessing whether an individual play well with others, but at the end of the day individual contributions and heroics bring home the raises and promotions. Also, HR has an important role in improving skill index of the team and removing people who are causing hindrance to Agility.
Facilities may have to create an infrastructure to hang index cards, burndown charts etc. and Video Conferences for distributed teams. It’s much easier to be agile when the whole team sits together. An ideal workspace will support team members as they learn to work in an agile manner.
A project management office (PMO) that is engaged in and supportive of transitioning to Scrum can be a tremendous boon. Members of the PMO often view themselves as protectors and supporters of a practice, so a PMO can help implement agile.
It will be important for both the marketing and finance teams to understand that an evolutionary design will be practiced, and they need to release the funds accordingly.
- Agile planning, work sequencing and DevOps - Remember working software is the primary measure of progress in Agile. Including operations, architecture, security, compliance, and analytics team members into delivery groups will be huge challenge. We need to get a waiver from compliance on few aspects.
During the project
- Change in existing role definitions –
(a) Analysts: They may become POs. On traditionally managed projects, the analyst’s mission is to get as far ahead of the team as possible. On a Scrum project, just-in-time analysis becomes the goal. The new aim is to stay slightly ahead of the team and they must shift from writing to talking.
(b) Project Managers: They may become a ScrumMaster, product owner, or team member, depending on experience, skills, knowledge, and interests. Else they will continue as PM to: Do career planning with team members, Improving skill index of team members; drive innovation; Coordinate external dependencies, suppliers, packaging, distributing; Be responsible for the team meeting the commitments made to management and Facilitate program-level demo & progress reviews.
(c) Architects: They will work closely with the product owner to educate about the architectural implications of the items on the product backlog. Their main responsibility is to consider change and complexity while the other developers focus on the next delivery.
(d) Programmers: They are expected to sit in a group space, engage in discussions, help others with problems, and participate in pair programming.
(e) Database Administrators: They need to evolve to support the evolving applications built on them and learn how to do it incrementally which was earlier viewed as a part of a project’s up-front work.
(f) Testers: They should also talk with users, customers, and other stakeholders. An increased emphasis on test automation becomes a hallmark of Scrum teams.
(g) User experience Designers: Their primary job is to make sure they finish whatever work committed for the sprint and then looking ahead at what team is going to build in the next sprint or two. They must spend time in gathering data, mock up designs etc.
- Build in ability in team members to do Agile –
(a) Provide coaching and training to think and work as a team and to create working software within short timeboxes. Employees need to know they will be held accountable for applying the new skills the organization is paying them to acquire.
(b) While developing the ability to be agile, team members will be crammed with new information and challenges. Provide opportunities for them to share information and problems by building some communities of practice.
(c) Encourage teams to select realistic, actionable targets to mature in Agile adoption. Not all teams can start practicing TDD from day one.
- Challenges with Estimation - Estimations are more difficult to deal with in Agile projects where requirements evolve dynamically, schedules are nailed-down, scope is volatile, stakes are high, and teams are distributed. Also, estimates set expectations and if the outcome varies either with time or with respect to features, it will result in losses which will have a magnified effect. Hence in the agile world, besides being empirical, estimations should also be evolving and adaptive. (See Attachment 2, source:staragile)
After the project
- Creating Transparency with New tools - Transparency is one of the major pillars and backbone of Scrum process. Product direction in the form of roadmaps, release plans or definition of done is made visible to the team so that they are aware of the goals and expectations. The team makes progress visible by regularly updating JIRA to reflect proper burn down charts. They closely work with stakeholders and allow feedback to flow in both directions and share the risk of taking a certain direction. The Scrum Master ensures that the events and artifacts are completely transparent.
- Frequent Releases - Release on Demand is the process that deploys new functionality into production and releases it immediately or incrementally to customers based on demand. The decision as to when and what to release is a crucial economic driver that requires careful consideration. Have an infrastructure set up to release on demand is a huge challenge.
- Sustenance - While one can get all support when things are implemented and be successful, it is important to focus on Sustenance model. All Agile teams must create quality solutions and define their own built-in quality practices. Work quality also directly affects the ability to deliver predictably and meet commitments. To avoid rework and delays, quality must be ‘built into’ value creation, not ‘inspected in’ later. In addition, by working in small batches, different individuals in cross-functional teams will be able to update work artifacts frequently. To support their ‘collective ownership’ of artifacts, code, and other content, Agile teams adhere to standards and processes. They also continually improve their product quality through refactoring and by reducing technical debt. Establishing different set of engineering practices like test driven development, behavior driven development (See Attachment 3; source : scaled agile) etc for one team is a huge challenge.
Finally, Agile projects in non-agile organization is not impossible but highly challenging.
The story so far
Every organization is different. Big/small/flat/divisional/ businesses/government; these all are different kinds of organizations. I will focus my write-up on comparing small vs big organizations in context of having an agile project, in a non-Agile organization.
Small organizations with limited businesses are very different than large organizations with multinational businesses. Small businesses, for example, will openly take a chance on new approaches, processes, open-source software, and tools. Their IT infrastructure can be easily modified to handle it. Larger corporations cringe at switching approaches, regardless of benefits. It may be accepted in smaller groups, but not as a corporate standard.
Agile was formally launched in the year 2001. However, after more than 20 years of fact, corporations are still figuring this out; especially big organizations with waterfall approaches and tightly coupled systems. So, when in a non-agile large organization, it is decided that "we will use agile in this project", people fake to be optimistic but do not look convinced.
What does going Agile mean in a non-agile organization?
To keep it simple, going agile means following these principles:
Challenges and Mitigating the challenges
Transitioning from non-agile to agile requires changing processes, working practices, and the culture of an organization. On a team level, agile might work nicely, but the challenges occur once interactions with the top management are required. The challenges to run an agile project (in non-agile org) can be
- The business does not understand the need to engage with the development team frequently.
- The existing governance does not support quick decision-making processes.
- The budgeting is not flexible enough to accommodate the planning and re-planning of agile projects.
- Approvals and rigid processes are so time-consuming that they keep on adding to delays in overall work.
- Differences in organizational cultures including communication, staffing methods, values, and language barriers
- Managing the transition to agile and learning how to co-exist with the non-agile part of the organization
- How to report agile progress to demonstrate governance over projects and to decide what information should be provided and at which level of detail.
One of my recent experiences was working as a scrum master/agile advocate in transition projects, that are transformed into agile projects from being waterfall ones. Despite initial hiccups, the projects were successfully transitioned. It was a multinational and cultural change. Thanks to reasonable brainstorming and determination of leadership.
Keeping in mind the above challenges, the leadership made a framework for transition and transformation. The first shift was challenging. However, then projects are getting executed in agile (scrum) way and things are going smoothly so far. Thus I confidently can say
An Agile project in a Non-Agile Organization is a welcoming first step toward a big organization-level change.
Some of the practical suggestions to run an agile project in a non-agile organization are (while these might look ideal scenarios, difficult to implement; however, they worth giving a good try):
An example how things change when we do an agile project (to support step 2 in above visualization)
How Things change in an Agile Project
Sprint progress, burn down, burn up
Result at the end of the project
Result throughout the project
Scope and requirements are fixed
Scope evolves and requirements are always changing
Client approves service delivery
Client collaborates in service delivery
Project phases are sequential
Project phases are iterative
Ideally, once an organization has a few successful agile projects on track record, decision-makers will be more willing to consider adapting these frameworks to accommodate more agile work. But, the very first attempt at co-existing with the non-agile part of the organization is challenging. It needs significant effort going from bottom to top in an organization. Howbeit, challenges are opportunities in disguise. The more one faces, the more he learns!
Agile projects in Non-Agile Organization, what will be your take?
Building a product that delights customer is everyone’s end goal so that both organizations and customers are happy. Any mindset, model or a methodology should help us in
- Faster value delivery
- Risk mitigation
- Faster feedback.
But often software organizations run into innumerable issues and challenges along the way. Apart from paying close attention to the latest technology and industry trends, organizations should also ensure they are becoming better organized, efficient, and also effective. So, it really depends upon the mindset and/or model and way of working in producing greater outcomes & value and there are various models/ways.
Non-Agile ways of working
Non-agile model is also known as Waterfall or linear or any traditional method for creating software. It splits the SDLC into different stages where we handle one at each stage. We can proceed to the next phase only when we are 100% done with current phase. Non-Agile approach like waterfall methodology assumes that time & cost are variables and requirements are fixed. Please find the doc attached.
Initiation (Define scope, purpose & duration) -> Analysis (work breakdown structure, schedule, budget, quality, risk & mitigation -> Design -> Build –> Test –> Deploy –> Maintenance
Ex: OS installation for 100’s of systems is a large-scale project. This can be executed with the regular sequence of steps like planning, execution, quality control, maintenance & risk management.
Non-Agile ways of working: Pros
- Standard direction: Everything is planned upfront. This allows team to focus on it throughout the project.
- Change control: Any trivial change has to go through change control process & approval by manager. This prevents deviations from original scope.
- Status: Status reporting to stakeholders and senior management during every stage at cadence.
- Accountability: Accountability lies with one person making it clear for everyone. Generally, project managers are accountable.
- Documentation: Clear documentation in each phase about everything.
Non-Agile ways of working: Cons
- Heavy weight process
- Customer is not involved till the end of the release.
- Delay in delivering value.
- No guarantee on the quality as testing is at the end.
Agile: Agile is a mindset and also an iterative and incremental way of delivering value where it gives importance to customer early feedback, teamwork, and flexibility. It works where upfront planning is not needed & emphasizes on delivering high value early & often which delights customer.
Scrum (doc attached) & Kanban are two most widely used Agile frameworks/models.
Agile methods adopt the empirical process against defined process. Agile is meant for systems which are unpredictable & where software development processes are highly complex.
- Light weight & Flexible
- Shorter iterations & incremental delivery
- Value delivered early & often
- Changes are honoured as per priority
- Just enough documentation & design
- Early feedback
- Engineering practices for ensuring quality
- Risk is minimized as customer is involved throughout
- Opportunity to inspect and adapt
- Happy teams as they are empowered in decision making
- High visibility & collaboration with stakeholders
- Demands more time & energy to continuously collaborate with customer
- Challenging to build cross-functional teams
- Empowerment may be misused on the name of freedom
My approach is to influence leadership & teams by using coaching and evidence-based model in making an organization Agile.
Step 1: Understand organization’s and teams’ current problems, challenges, and other pain points in their current ways of working.
Step 2: Educate them on the difference between Non-Agile and Agile w.r.t. 3 important constraints – time, scope, and cost.
Please find the attached doc (Traditional vs Agile)
Please find the attached doc (Traditional Iron triangle vs Agile) w.r.t. 3 important constraints.
Step 3: Share them the stats on why different organizations move non-Agile to Agile.
- Improves collaboration - 54%
- Enhances quality - 51%
- Enhanced customer satisfaction - 48%
- Time to market - 42%
- Reduces development cost - 42%
Step 4: Coach both leadership and teams by asking right questions in choosing the right way between Non-Agile & Agile.
Please find the attached questionnaire doc which helps in deciding which method to use in this VUCA (Volatility, Uncertainty, Complexity & Ambiguity) world. If answer is ‘YES’ then the obvious choice is Agile.
Step 5: Help them understand the factors in determining if org is Agile or Non-Agile.
It depends on the following factors:
- Culture – people & their ways of working w.r.t customer collaboration
- Structure – hierarchy in org which supports self-organizing teams
- Infrastructure – underlying foundation of an org which supports continuous delivery
- Expenditure – spending on right technology, tools, people with right skills etc.
- Mixture – mix up of skills that are required in a cross-functional team to deliver value
- Architecture – good design and patterns
- Feature - characteristics and offerings in our products
- Manufacture – building
- Nurture – help teams grow in delivering working software frequently, to work with business and have attention to excellence in quality.
Step 6: Inspect & Adapt, Experiment with small pilot teams
Approach: Big bang approach for entire organization may be disruptive. Training & coaching can be both top down & bottom up. Implementation can be at team level as a pilot. So, we can start slow & then scale up.
How to improve our way of working, achieve agility and scaleup to the org level?
- Develop Cross-functional teams: Have people with right skills to deliver product E2E and for this if required mend your regular hiring model.
- Develop Self-organized teams: Ensure to provide a psychologically safe environment not just for developers but for everyone in the organization and give them the autonomy to make decisions.
- Shorter release cycles: Agile divides a project into multiple sub parts named iterations. Plan & deliver in short cycles.
- Customer engagement – Engage your customer not just at the start or end but throughout during every iteration.
- Build right product & build product right by having frequent inspection & adaption. Please find the doc attached (Product Agility).
- Prioritization: Prioritize based on value with techniques like WSJF (weighted shortest job first), Kano model, MoSCoW & 100-point method etc.
- Continuous Improvement: Strive to improve incrementally by focusing on right METRICS (Measure Everything That Results In Customer Satisfaction).
Agile Metrics: Please find the attached Agile metrics doc. Focus is more on customer happiness & time to market which are the driving factors for any business in today’s world.
8. Risk management: Manage risks by continuously validating your outcomes with frequent customer reviews.
9. Quality: Focus on high standards of quality not just in development or testing but right inception to delivery with shorter feedback loops from customer.
10. Value driven delivery: Generate value by delivering increment early and often.
Key areas to transition from Non-Agile to Agile: Following 6P’s
- Principles &
Verdict: There are projects where Non-Agile ways may work well like when requirements are fixed, clear and documented, risk is zero with clearly defined sequential stages and tasks etc whereas Agile allows customer to get involved at each stage, increment can be inspected and adapted which delights the customer. Therefore, Agile project management is the real winner for majority as it not only allows greater team & stakeholder collaboration but also overlays way for best results due to its flexibility. Having said that nothing can be force fit and I propose the tools, techniques and approach covered in this solution to assess what works well for each org and finally inspect and adapt is the key.
Agile is, above all, a mindset. Agile teams or an individuals set their mind to achieve the result best suited to the customer's needs, to always improve, perhaps not always but, undoubtedly, to do, learn and adapt fast, so that when you fail to improve, you can bounce right back to the improvement saddle. How I define agile is shown in the image(What isAgile.jpg). This way of thinking tends to clash with classical management. If you work in a non-Agile company, you can still be Agile in your work. This means being flexible and adaptable, responding quickly to change, and working collaboratively with others. You may need to be more proactive in seeking out Agile opportunities and sharing your Agile values with others in the company. But we need to explore will it is enough to achieve business agility.
To give my opinion on the topic, I would like to define what an Agile Project is and what a non-agile organization is.
What is an Agile Project?
As leaders, we develop patterns and habits for how we approach things over time; they have worked well for us in the past. However, when we get used to them, we can forget what the situations require and rely on them. That's why Dave Snowden's Cynefin framework is conducive to us both thinking about ourselves and thinking about how we address things with teams.
Snowden's framework distinguishes between things that are predictable and things that are unpredictable. Things can be expected to repeat in the predictable world. Basically, they just go about their business. The unpredictable world, however, is a very different place. It is not necessarily true that they will happen the same way as they have before. As a result, he further divides the predictable world into two categories: things that are obvious and those things that can be agreed upon by everyone. There is an obvious connection between cause and effect. There's so much research behind that stuff that there are best practices. It's like when you bake a cake once and know how it's going to come out; when you bake it again, it will be the same way if you follow the same recipe. The same ingredients are used in the same recipe. Best practices and recipes, checklists, and other things in the obvious space should repeat predictably time after time.
In the complicated space, which is the other domain Snowden talks about in the predictable world. In the complicated space, it's different; there is a connection between cause and effect, but it's kind of fuzzy, and you need experts to figure it out. So things repeat over time that you need a lot of experience or domain expertise to know which approach to take. This isn't the place where we'd have best practices because experts might disagree about these things. This is the place we'd have a good practice, where solid experts with really good research or experience would say, I think you should go this way. Another expert might say I think you should go this other way, but in general, they're going in the same direction. Things like really hard things that have lots of moving parts can be in this category things like bringing a person to the moon, making a rocket ship go to the moon that lives in this domain in fact, so you get engineers and scientists and people in charge of rockets and fuel and all those folks each work together on their own piece you put it together and you have a machine that will take you someplace wonderful.
When you cross over into the unpredictable domain, actually, the rules all change, and how we act as leaders also needs to change. Over here, you can't tell what's going to happen simply because it's happened before. You need to come up with new approaches and novel approaches safe to fail experiments to figure out how to nudge the system in a new direction. People say parenting isn't rocket science but actually, rocket science is in the complicated domain parenting is in the complex domain. Leading people is a complex domain. Culture change is in the complex domain. These are things that just because they happen one way once, you can't count on them happening that way again. Then Snowden offers us the chaotic domain, and in chaos, there's no connection between cause and effect. So the agile projects are the ones where we have uncertainty and more disagreement about the solution. (Image shows what kind of projects can be Agile Cynefin.png)
What is a non-Agile Organization?
Frederic Laloux in his book Reinventing organizations talks about how the organizations have evolved, and human behavior has changed to get the work done. (Image shown to understand the evolution)
Red – This is the earliest stage of organizational development and is characterized by a high degree of chaos. There is no clear leader, and everyone is fighting for power. This stage is often characterized by a lot of infighting and backstabbing.
Ambar: Formal hierarchy and control organizations are typically found in large businesses and corporations. They are characterized by a clear chain of command, with each level of management having a specific area of responsibility. This type of organization is often seen as being inflexible and bureaucratic, but it can be effective in ensuring that all employees are aware of their roles and responsibilities.
Orange – This stage is characterized by a clear leader emerging and a hierarchy beginning to form. There is still a lot of chaos, but it is starting to be replaced by order.
Green: these organizations are looking to flatten their hierarchies and create a strong, shared culture. This allows employees to have more ownership over their work and to feel more invested in the company.
Teal: This stage takes self-management to a higher level. A self-managed purpose-driven organization is an organization in which individuals are autonomous and self-sufficient in achieving the organization's goals. The organization's purpose is clear to individuals in the organization who are committed to achieving it. This type of organization is characterized by decentralized decision-making, flat hierarchies, and an emphasis on collective rather than individual achievement.
The point is when we say non-agile organization, either they are Red, Amber, or Orange organization. Most of the big corporations will fall under orange characteristics. There may be some parts of the org which is more evolved than other, but as a whole org, it is more Orange.
To answer the question, yes, teams or individuals can be Agile in a Non Agile organization, but they may not get the benefits of being Agile. Even explains in his theory of constraints, "An organization can only be as agile as its least agile division!". As a company grows and develops, it does so through the addition of new products, processes, services, departments, and divisions. Each of these new additions will have its own way of doing things. They will have their own processes, their own tools, their own methods, their own cultures. The problem is that the more divisions there are, the more silos there are, and the less agile the company becomes. The answer is to find ways to break down the silos and make the company more agile. One way to do this is to create an "agile transformation office." This is a dedicated team that is responsible for helping the company to become more agile. They will work with all of the different divisions and departments to help them to understand what agility means and how they can adopt agile practices. The transformation office will also help to create an environment where agile practices can flourish. This might include setting up agile working practices, such as scrum, or introducing agile tools and techniques, such as Kanban.
There are many doodles done by me to establish this pictographically , please refer to the numbers on attachments
Agile is all about
A - Ability to create and walk towards the vision
G- Go to market fast with good quality
I - Improve continously to maintain quality standards
L - Learn and Unlearn - technical aspects/skills/reports/processes to support the change and speed
E - Enable team and empower them to achieve the goa;s
. AGILITY is the swiftness to change and more of adatpting to change , its the mindset that comes with practise. Though it is popular in software development coplanies , it is also being explored, experimented across other domains.
 Delighted customers is the motto whether its AGILE or NON AGILE .
With the current trend of digitalization that owns all the domains of work , key factors that really matters is :
a. Quick delivery to market
b. Quality and user friendly products
c. Continous feedback from stakeholders and users to be added to backlog
d. Continous improvement to meet the market trends.
Whether OLP/Waterfall/V- Model - all the organizations are pseudo agile as they ae all customer centric.
They might not be following the framework like Scrum/Kanban etc to achieve it.
Scrum facilitates the 4 values to its prime focus to achieve the happy customers.
a. Empower people over processes and tools. 
b. Working Software /Product increment 
d. Embrace change 
With all of these we enable teams to be cross functional and skilled .Technical excellence is celebrated. Different scrum events are engaged among the team members to increase the team collaboration .
Team makes their daily decisions to achieve the goal. Any impediments are called out and moved towards resolution.Transparency ad trust is always called out. Backlog is refined periodially with feedbacks from stakeholders/customers/technical debts. A vision is created with the roadmap for the product. And work is chunked out as sprint backlog to plan the sprints. What to do is discussed and prioritized . Once 'what ' is clear, the 'How' is planned during sprint planning according the capacity and velocity of the team . Buffer is better than burn out. so that is calucated and accomodated. Work is broken into tasks and estimated.Validation is done for all the products with the issues/defects identified. Sprint execution sails. We also Introspect, Retrospect and Adapt.
Happiness metrics are important to avoid burnouts and promote sustainability. Happy teams yields better.
Agile supports the projects to sytematically deliver the output incrementally. Hence whether called out or not , most of the organizations are pseudoagile!
Cycling on uneven surface uphill.
Generally, it is perceived as hard exertion due to the friction it creates.
Likewise, analogy is perfect to give an insight into the challenges it brings with it.
So, what is an organization?
A group of people that organize themselves to convert ideas into value.
We accept that will have to breathe in every situation be it Agile / Non-Agile. Most important are the principles that help us to coexist happily.
The beauty of Agile lies in its potential to deliver value at every phase while remaining flexible and open to change.
Agile is the widespread software development approach. But many projects are still working with traditional methods. Thus, problems arise on the interface of agile and traditional due to their fundamental differences.
Somethings are viable but don’t survive long say in non-agile organization. Why?
Embracing Agile Projects in Non-Agile ecosystem comes with many challenges because the supporting functions, such as marketing , human resources or finances wth taxing details are still operating in their established ways.
Standish group, in 2002 analyzed 2000 projects that considered as successful, they looked at features delivered by projects. 45% features were never used, 36% were in use and 19% were never use. Attachment: Standish_wasteful.png
Having two third features never used is concerning.
Can we avoid these bloated products?
Attachment shows the snapshot of the tickets that go through from one stage to another in workflow.
Wasteful activities say rework, waiting etc. add to the time it takes to convert idea into product. Attachment: IdeatoValueFlow.png
Agile thus addresses a conundrum that many industries face: How can we maintain controlled development and implementation, while also promoting innovation and creativity?
Sharing my story that ours is a fintech product-based company working with treasury product.
We were living in waterfall model ecosystem having issues with timeline and quality, stepping on each other’s toes.
Organization was heavy with lot of misalignments . It was hiding behind SLA’s and encouraged contract negotiation over collaboration.
Attachment shows the J-Curve that comes in picture when we are learning, or change is there.
Attachment : JCurve.png
Desired state from current state is not instant but takes lot of time .
How was the business tolerance to period of disruption?
It was generally shorter as we don’t give enough time and then say that it did not work for us. We also say Agile not working for our organizations. Really??
Attached diagram shows that we get too excited about the changes but ignore the principles . That is why many organizations are agile in name but not in beliefs and values. Mechanics are right but no value.
Attachment : OrgIceberg.png
Having agile or non-agile depends on whether we are company oriented or people oriented?
Moving from non-agile to agile urges to encourage collaboration and cultivation.
Barriers / challenges came across working in non-agile ecosystem were as below:
- Traditional plans are specified and only updated when necessary. Thus, it is difficult to synchronize with agile plans which are only detailed for a short period of time, and which are adapted each iteration.
- Hierarchical organization
- People perceive growth as getting bigger titles rather than making true impact.
- Slow decision making due to misalignment or lack of synergies between various units
- Support function needed outside teams and their SLA’s are different for instance database administration activity, infrastructure i.e. server setup. An interface problem is a problem or challenge occurring on the interface of agile and traditional approaches, e.g., caused by the conflicting underlying principles or processes.
- Conflicting priority
- Agile team members get frustrated due to unsynchronized feedback from traditional stakeholders. More interface problems were mentioned, such as a fixed budget and project plan at the project start or having to adapt to the surrounding stage-gate process.
- Roles and Responsibilities missing
- Lack of training
- People outside agile projects feel ceremonies are only way of being agile over the mindset.
- No Buy in from higher management
- Failure indicates complexity in the system and it is better addressed with adaptability in a management heavy organization where failure is there all energy goes in putting more processes which at times becomes counterproductive.
- One size fits all approach
- Processes are rigid instead agile teams should be flexible in designing their own processes .
- Technical Agility
- Can we get the business agility without technical agility when IT is key enabler? Tight coupling and complex dependancies.
- Lack of tools and infrastructure due to shared environment
- IT operation challenges
Standish contrasting report attachment : Standishreport.png
Why can’t organizations be Agile?
- Silos established and discouragement of collaboration
- Mindset to deliver everything at one go.
- Not clear what being Agile is. Mechanics are not important what is more important are the values and beliefs.
- Agile Values as
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
While there is value in the items on the right, we value the items on the left more.
Non-Agile environments just at time value the item on right more .
Being Agile is all about being mindful in applying techniques of agile to environments.
Being Agile is all about focusing on value i.e., what you want to do and why you want to do it also level of collaboration.
Living in agile projects with non-agile ecosystem?
From my experience,key is sometimes in the way of convincing organizations as at times we solve the wrong problem/approach . Every cloud has a silver lining.
Some common reasons are too many stakeholders, huge demand, and supply mismatch, too many interdependencies between the work requests. Mismatch between demand and supply this will results to flow jump and team will cut corners and thus delaying the delivery .
Few steps to be taken :
- Get a dedicated PO to mitigate the risk of command and control
- Break things down (Decomposition) Divide the work requests instead of doing a big work request.Prioritize and focus on most important thing.
- Combining work requests and doing quarterly releases. More control and more visibility.
- Get feedback and adjust your plans as needed.
- To address technical agility created technical backlog think about tools and infrastructure, adopt good practices i.e. pair programming and test driven development.
- Check over balance between strategic vs tactical.
- Team collaboration –tools that encouraged the team collaboration to maximize effectiveness. For instance, pairing metrics that keeps log of who is pairing with whom to help in pair rotation.
- Build feature teams instead of specialization teams to minimize dependencies.
- Add feedback loops i.e. sprint review, retrospectives etc.
- Agile training and coaching
Let us generalize the model of working with agile projects in non-agile environment should follow GQM goal template as :
- Identify and analyze common existing problems on the interface of agile in a non-agile environment to create a classification in the context of organizations developing software or systems from the perspective of research and practice.
- Refine this goal into several research questions such as Which interfaces of agile entities to a non-agile environment exist? Which problems do appear on the identified interfaces? How to classify and group these problems?
Once we have the above state ready, we proceed as:
- Perform a workshop with few employees, all experienced in agile and some in systems engineering.
- Discuss this topic at public conferences. We were able to collect further problems from practitioners and discuss most important problems to identify concrete solutions.
- Afterwards, an initial classification was developed.
- Finally, this classification was used to categorize the identified problems on specific interfaces according to the dimensions of the classification.
- Publish Results in matrix that supports classification of interface problems and solutions.
“It doesn’t matter what you do, so long as you don’t frighten the horses “– Edward VII
A very famous quote by Edward says that don’t be too obvious when applying agile principles to non-agile environment. Some will follow one way of working others will follow different what is more important is focusing on the value of what’s being done/delivered.
more around concentrating on the value it gives and work over the challenges that stops it making it effective.
Non-agile organisations are typically organised in so called functional silos where management typically communicates tasks down once on a time with little to no communication in between. Same happens with every function - developers sit and communicate with other developers; business analysts, program managers, product mangers co-located with each other and often reports to different departments; testers probably report to QA.
All these functions are typically unavailable to the developers and latter are constantly frozen waiting for answers.
Project planning problem
Another problem located in the Project planning and execution. Agile approach simply won't work in the environment where management planned all ahead and is not trained to respond to the and typically avoided it. Moreover, those who typically used larged specification and requirements documents to "communicate" their needs will hardly understand the lightweight requirements approach.
Last but not the least, calculating the cost of agile development is not real with a traditional approcah and again training. When development calculated "year ahead" meeting unambiguity and changes constantly the project most likely will be doomed.
Resources: Agile Software Requirements by Dean Leffingwell
Agile Project Management is an iterative approach to planning and guiding project processes that breaks them down into smaller cycles called sprints, or iterations.
The Organizations /teams those looking for transistion to Agile from SDLC only focus on the 2 keywords from the above definition of Agile Project Management i.e Iterative and Smaller cycles called sprints .
Organizations wants to follow agile while using the Project management practices established based on the SDLC model.
This is the case with most of the organozations who wants to implement agile across the projects.
This process of implementing agile only in certain phases of SDLC Project Management process like development phase helps teams to get feel of agile and they call its a iterative and delivering in sprints.
while inclduing agile frameworks like Scrum ,Kanban etc during the development phase helps the customers /stakeholders to see the demo's per sprint and continious feedback to the team and vice versa .
However i feel all these are false alarms as we are just trying to implement agile in SDLC and see only the ones that we would like to see and believe as benefits .This way of implementing Agile with assumed benefits slows down the actual Agile implementation across the organization and teams way of interpreting agile projects and processes.
I belive the organizations need to iterative in all phases of the projects not just selective phases to run agile projects .