"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.

For example:

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.

Attachment: AgileAdoption.png

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.

1. 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.

Pic: ROI.png

                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.

Introduction

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:

1. 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:
   1. Basic needs -> Must be there
   2. Exciters -> to gain customer delight
   3. Performers -> to stay competitive
   4. Dissatisfiers -> that would make customers to feel disgusted
   5. 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:

• Usefulness
• Ease of use
• Joy of use
• Aesthetics
• 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

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

1. 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.
2. 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
3. Impact of cost of dela.ying a feature needs to be analyzed proactively and must be considered during product backlog prioritization.
4. Ensure to re-assess ROI at regular intervals because scope gets changed during software development.
5. Measure ROI post every delivery and observe the trends. Necessary measures should be taken to prevent huge loss.

Conclusion:

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.

References:

1. https://www.investopedia.com/terms/r/returnoninvestment.asp
2. http://www.ambysoft.com/surveys/success2013.html
3. https://www.productplan.com/glossary/kano-model/
4. https://www.scaledagileframework.com/wsjf/
5. https://premiosgroup.com/calculating-roi-meaningful-agile-projects/

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:

1. PO estimates the value of each feature
2. Developers estimate the size of product backlog and their average velocity each Sprint
3. Projected no: of Sprints = Size / Velocity
4. Projected value per Sprint = Total estimated value of Product Backlog / Total projected no: of Sprints
5. 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.

1. Release Frequency: No: of releases per time period.
2. 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

1. Customer defects: Defects escaped to production which means which are not caught during development & testing.
2. 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.
3. 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

1. Known technical debt: test cases which are candidates for automation but not yet automated (legacy base)
2. Unknown technical debt: Once in a year, we have dedicated time in refactoring unused code or dead code or to simplify the code base.
3. 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:

1. Value delivered to customer,
2. Achievement of business goals &
3. 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
• Adaptability
• Value
• Reduced Total Cost of Ownership etc.

Conclusion:

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:

Solution 1:

• Highlight the letter ‘O’
• Count row wise
• Sum each row and get total

Solution 2:

• 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.

Example: https://www.pointillist.com/blog/how-to-calculate-customer-experience-roi/

• 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:

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.

Metrices:

• 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.

1. 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.
2. 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.

1. Higher NPS
2. Increase in availability of systems
3. 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.

1. Increase revenue – Adding new customers or offer new products/services to existing customers
2. 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”.

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 !

References :

https://www.infoq.com/news/2008/06/agile-practices-high-roi/

https://www.raconteur.net/business-strategy/how-to-measure-the-roi-of-agile-projects/

https://www.scrummasters.com/agile-white-papers/agile-enterprise-adoption-improves-roi/

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:

Analysis.

Initial system is evaluated or the business need identified.

Requirements elicitation.

Upfront elicitation of the system requirements from stakeholders that could take around 4 months.

Planning. 

The whole project planning, that could take up to several years, is done upfront:

1. how the system will behave: features, tasks, intended processes.
2. under what circumstances: non-functional requirements like “ilities” (reliability, etc.)
3. 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:

1. system is not ready upon a deadline: features not completely done, defects, bugs, etc.
2. system does not do what is needed by stakeholders Now: cause rework, refactoring, etc.
3. time to market increases dramatically as system is not ready and must be reworked

Deployment

Finally, after failed deadlines, rework, additional costs, and loss of trustworthy and reliability system is delivered to stakeholders.

Maintenance

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.

Summary

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.

Sources:

1. Agile Software Requirements by Dean Leffingwell.
2. 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:

1. 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.
2. 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.
3. 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.
4. Market Responsiveness: The ability of the organizations to ride quickly toward ever-changing market demands is possible only with agile transformation. 
5. 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

User Story:1

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%

For example:

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.

User Story:2

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.

User Story:3

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.

For example:

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 

1. 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 :- 

1. 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. 
2. 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. 
3. 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.
 

Introduction

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:

1. 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.
2. 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.  

1. Team’s mission remains top secret
2. Surviving with growth mindset becomes nightmare for SM,PO & team
3. Command & control-ism Vs Servant leadership style -> confrontations & conflicts
4. Ambiguity in career paths and multiple reporting structures
5. At the worst case, sponsor would cancel the contract and business may go to our competitors

Conclusion

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.

References:

1. Kurt Lewin (German-born psychologist, 1890-1947), 1946, 3-Phase Model of Change
2. McKinseyReport
3. Dilbert comic strip

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

1. The business does not understand the need to engage with the development team frequently.
2. The existing governance does not support quick decision-making processes.
3. The budgeting is not flexible enough to accommodate the planning and re-planning of agile projects.
4. Approvals and rigid processes are so time-consuming that they keep on adding to delays in overall work.
5. Differences in organizational cultures including communication, staffing methods, values, and language barriers 
6.  Managing the transition to agile and learning how to co-exist with the non-agile part of the organization 
7. 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)

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.

Agile: Advantages

• 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

Agile: Challenges

• 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?

1. Develop Cross-functional teams: Have people with right skills to deliver product E2E and for this if required mend your regular hiring model.
2. 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.
3. Shorter release cycles: Agile divides a project into multiple sub parts named iterations. Plan & deliver in short cycles.
4. Customer engagement – Engage your customer not just at the start or end but throughout during every iteration.
5. Build right product & build product right by having frequent inspection & adaption. Please find the doc attached (Product Agility).
6. Prioritization: Prioritize based on value with techniques like WSJF (weighted shortest job first), Kano model, MoSCoW & 100-point method etc.
7. 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

• People,
• Process,
• Policies,
• Practices,
• Principles &
• Product

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.

Final Thoughts:

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

[1]. 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. 

[2] 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. [3]

b. Working Software /Product increment [4]

c.Customer Collaboration[5]

d. Embrace change [6]

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.

Attachment: quadrant.png

Barriers / challenges came across working in non-agile ecosystem were as below:

• Planning
  • 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 :

1. Get a dedicated PO to mitigate the risk of command and control
2. Break things down (Decomposition) Divide the work requests instead of doing a big work request.Prioritize and focus on most important thing.
3. Combining work requests and doing quarterly releases. More control and more visibility. 
4. Get feedback and adjust your plans as needed.
5. To address technical agility created technical backlog think about tools and infrastructure, adopt good practices i.e. pair programming and test driven development.
6. Check over balance between strategic vs tactical.
7. 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.
8. Build feature teams instead of specialization teams to minimize dependencies.
9. Add feedback loops i.e. sprint review, retrospectives etc.
10. Agile training and coaching

Let us generalize the model of working with agile projects in non-agile environment should follow GQM goal template as :

1. 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. 
2. 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.

Communication problem

 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.

Economic problem

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 .

Transition of organizational roles in Agile transformation process - why ?

It is evident that organizations must go through transformation process to embrace agility to sustain in VUCA world. According to McKinsey report, a comprehensive transformation touches every facet of the organization, including people. process, structure, strategy, and technology.

Here, people play a very important role in any transformation initiative. If any change is brought into the organization or at home, they would go through certain emotional stages. Refer fiigure1.

In my experience, as part of Agile transformation process, once people is educated about Agile methodology, the very first question is about their roles -> whether it would exist or not; finding reasons that Agile won’t suit for their projects due to job insecurity including leadership team.

If we analyze further, basic root cause for all these emotions is lack of clarity-> what is in it for me? How I am going to be involved in this process, what are my roles and responsibilities, how my future would look like?..etc

One of the best ways to bring clarity is to define organization roles clearly in accordance with Agile methodology.  If people are clear and accept the roles, it is an indication of short-term win in the transformation journey.

Transition of organizational roles in Agile transformation process - What?

At the end of the transition, the outcome of this activity is:

1. Roles & responsibilities w.r.t Agile methodlogy, at product level & organization level
2. Career lattice
3. Customized upskilling program w.r.t Agile roles
4. Experience corner -> a place where such roles can be simulated before handling real product teams
5. Communication model
6. Revised organization structure

Transition of organizational roles in Agile transformation process: - How ?

One of the best change management models is John.P.Kotter’s 8 stage model. Let us see how this transition can be done through this 8 stage approach.

Stage 1- > Establishing a sense of urgency

This step acts as a foundation to the transition process. Business need for transforming organization roles to adapt Agile methodologies to be articulated clearly based on feasibility study. Get the buy-in from leadership team and create a curious atmosphere in the organization.

Stage 2 -> Creating the Guiding Coalition

For every product, there would be early adopters and in fact, we as end users would like to hear their review comments before buying the product. In the same way, coalition teams are to be formed to enable this transition across the organization. This team will help to identify hidden champions (driving forces), hidden obstacles (resisting forces) through a technique “Force-Field analysis”, which is defined by Kurt Lewin in 1940.

Stage 3 - Developing a vision and Strategy

Like how product vision is important to a product team, vision is also needed for any transformation process. Vision to be crafted in such a way that it inspires people to be part of the change, it must connect them emotionally. Example, Agile roles acts as lighthouse for the Agile organization.  

Also, strategy needs to be defined clearly, like what are the sectors would be chosen for the Agile transformation. Agile transformation blueprint needs to be shared with relevant stakeholders along with the expected results. Refer the case study section to understand tried and tested method in my organization (how part).

Step 4- > Communicating the Change Vision

Use all possible formal and informal channels to communicate about this transition, regularly and consistently. One of the best ways to communicate the vision through visuals -> future state -> how the final change would look? What problems are getting solved with this change -> place the standee/poster in most accessible places, desktop screensavers ….etc

Stage5 -> Empowering Employees for Broad-Based Action

Once strategy and vision are made public, identify few teams for piloting and empower the team members/leadership team to take certain decisions, to try out few alternatives apart from what is mentioned in the rule book. For an example, if contracted vendor is not planning for Agile trainings even after few reminders, then teams are to be empowered either to fix the problem or to change the vendor. If there exists resistance continuously from the team, then team should be able to bring experts from industry to share their experience without wasting much time for approvals. During this stage, create facts: use the coalition and determine new paths, adapting/changing processes, procedures, and rules to move forward in this transition process.

Stage 6 – Generating Short-Term Wins

Bring positive vibes inside the organization through short-term wins. If piloting teams got fruitful results in certain aspects, then showcase it in all internal and external forums. For an example, a team is established with 3 Scrum roles and delivered first increment product, then celebrate it. Encourage the team to share their experience, what was different from earlier working model. Share the tried and tested methods to different sectors to check the scalability and adaptability of the model.

Stage 7 – Consolidating Gains and Producing More Change

Based on piloting feedback from different sectors, refine the procedures, methods, roles and responsibilities, organization structures to make it more robustic. Few aspects to be focused:

1. Don’t declare victory soon
2. Use the gained trust over the period of time to define next steps with more courage
3. Appreciate high performance teams

Stage 8 – Anchoring New Approaches in the Culture

This is one of the important steps to incorporate the guidelines, procedures and strategy as part of the organization culture.  For an example, a person asked to play PO according to transition process but if designation is senior project manager, then that person sees a disconnect and this would harm Agile transformation process in the long run. So, ensure to revisit organization strutucre, roles, appreciation system, appraisal framework, working models, processes, KPIs for continuous development of management and managers.

Case Study: Transition through Role mapping

It is like story mapping technique. In one business unit, entire team came together including leadership team and derived roles & responsibilties that supports Agile transformation. Refer figure2.

During this role-mapping method, below decisions are derived for outliers:

1. Some of the responsibilities like billing, performance discussions, contracts with vendors..etc are not able to map with SAFe roles.  Hence team has identified few supporting roles like Project Coordinator, contract manager, resource manager to fulfill these organization operational activities
2. In the same way, for few roles from SAFe framework, we didn’t have the expertise and team is decided to hire people to speed up the transition process including an Agile coach

This model is well received within Bosch as the roles are redefined and co-created together. At regular intervals, this role mapping is revisited, and measures are taken to match the real world.

Points to be noted for successful transition

1. In an organization, need for Agile may not be there for all the projects. So, it may have Agile based projects, non-Agile projects and Hybrid projects. So, for every associate, career lattice must be clear -> how to grow vertically as well as horizontally.
2. Ensure to derive competency plan for every role in accordance with career lattice. For every role, identify required soft and hard skills. This would help every team member to self-assess their competency and they would own their learning journey to close the gaps.
3. Avoid some of the anti-patterns in the interest of associates or to speed up the transition process. Sometimes, project manager will be designated as SM directly. This would harm the transition process. For years, project manager lived by the concept of monitoring and controlling whereas SM is all about removing the impediments, showcasing servant-leadership. So before assigning PM to SM, ensure that person has undergone a learning journey -> Learn -> Unlearn -> Relearn.

Conclusion:

In construction, curing is one of the important process to be done after concreting is completed. If curing is skipped, it would lead to:

• Cracking of concrete
• It will affect the durability of the concrete
• Reduction of the strength of the concrete

Similarly, transition of organization roles during Agile transformation process is very crucial and if skipped, what would be the impact? I left that to the reader’s imagination. ????

References:

Link1

Link2

Link3

Agile is no more a buzz word and many organizations acknowledge its benefits; but how do they transform? I want to make it clear that our intention is not to change; it is to transform. Often, we transpose the words transformation and change, when in fact they are different. Change uses external influences to modify actions, but transformation modifies beliefs, so actions become natural and thereby achieve the desired result which is more likely permanent. When beliefs are modified, the mindset changes and impacts the way you work. This gives rise to new roles and responsibilities.

I tried my hand at many games such as cricket, tennis, volleyball, table tennis. The first thing we do is to learn the rules of new game and get needed skills to excel in it. Because you are a big six hitter in cricket, you won’t succeed in tennis, because here you must keep the ball within the court. Similarly, if we try mapping existing roles in a new process, most likely we will demonstrate old behavior in new ways of working. That’s when we find people doing waterfall in Agile process.

Some scenarios I noticed are:

1. Senior Directors limit the Scrum Master role to just facilitating the scrum ceremonies and the bursting of team impediments ought to be dealt by Managers.

2. Managers playing the scrum master role for one or two scrum teams.

These two were the easiest way to manage the things but they had their own shortcomings. In first case, ScrumMasters were hardly motivated to play their role which is much like administrative role, and it affected the way ceremonies are conducted. And in second case the manager lacks the servant leader mindset and skills that are important in a Scrum Master. He usually determines team member’s salary & bonus, which creates fear and prevents a healthy and open relationship between team members and the Manager/ScrumMaster. And most important one is the workload; it’s too much work for one person to play both roles. But, if a project manager can overcome the old habits of directing the team and making decisions for them, it is likely such a project manager can become a good ScrumMaster; even then we still need someone to play the role of a manager. I strongly feel there is a need for both the roles to exist to succeed in Agile.

Let us see transition in some of the organizational roles for a successful Agile transformation.

• Analysts – They have the best chance to become Product Owners if they make some adjustments.
  • On traditionally managed projects, the analyst’s mission seemed to be to get as far ahead of the team as possible. On a Agile project, just-in-time analysis becomes the goal and to stay slightly ahead of the team
  • Need to shift from writing to talking. They make sure conversations are as productive as possible given the time constraints the team or product owner may be under.
  • They assist in testing and time that is not needed to complete the work of the current sprint can be used to look ahead.

• Architects – They plan and develop architectural runway that consists of the existing code, components, and technical infrastructure necessary to support the implementation of prioritized, near-term features without excessive redesign and delay. Their main responsibility to consider change and complexity while the other developers focus on the next delivery. They also evaluate alternate solutions and validate technology assumptions. They need to work closely with the product owner to educate the product owner about the architectural implications of items on the product backlog.

• Programmers - They do anything necessary to help the team complete the work committed to for a Sprint. Although it is OK to have specialists on a Scrum team, specialists need to be willing to work outside their specialties whenever needed. They can no longer sit in their cubicles and wait to be told exactly what to program. Programmers will also be expected to talk to customers and users occasionally, even if it’s just over the phone. They are expected to spend more time interacting with their coworkers rather than coming in at 11am and clamp headphones on until quietly leaving at 7pm. They need to sit in a group space, engage in discussions, help others with problems, and participate in pair programming.

• Testers - However, as nice as conformance to requirements may be, conformance to users’ needs is even better.  Testers cannot say, “Hand me the perfect requirements document and I’ll make sure the system does everything in it.” They also should talk with users or customers. An increased emphasis on test automation becomes a hallmark of Agile teams. Time, practice, training, and pairing (including with a programmer) should be sufficient to overcome the fears of manual testers. Testing engineers in agile teams have more influence in the development process and, what’s even more important, on the end product.

• Project Managers/Functional Managers - Former project managers often assume one of the roles that have taken on some part of their past responsibilities—the project manager becomes either a ScrumMaster, product owner, or team member, depending on experience, skills, knowledge, and interests.

In such cases I see a need to change the title, because old words will slow or prevent the adoption of the new approach. Retaining an old title discourages thinking in the new way. Further, if people are unwilling to relinquish something as insignificant as a job title, they will probably also be unwilling to make the far harder changes necessary to adopt Agile.

As I said earlier, manager role can coexist in Agile environment. Too often, we put a wet blanket over the fire of innovation and motivation. Worried about the future, we become opaque rather than transparent with our teams. Managers will be one of the key resources in building a powerful culture by unleashing the talent of individuals and teams. They drive innovation and motivate individuals and teams who are passionate about delivering results and make sure the right things get done. If teams are made to understand what needs to be done and why it needs to be done and have the tools to succeed, miracles seem to happen. And, given the ambiguity that accompanies the decisions we make, we need such miracles. The diagram (Attachment 1) shows the shift the manager makes in teams. Also see (Attachment 2 -RACIF matrix) for clear roles and responsibilities defined.

• Database Administrators - Most resistant to adopting Agile. They will be faced with learning how to do incrementally against what has traditionally been viewed as a part of a project’s up-front work. Standard advice in database design has been to do a complete analysis of the system’s needs, create a logical or conceptual database design, and then map the concepts to the constraints of a real-world database during physical database design. Databases need to evolve to support the evolving applications built on them.

• User experience Designers – They are with the development team, to make sure to finish whatever work is committed for the sprint. But that doesn’t take up all time, so they spend a good amount of it looking ahead at what team going to build in the next sprint or two. They gather data, mockup designs, and do whatever so that team starts on a user story in a future sprint. In short, they satisfy the definition of ready for a user story. (See attachment 3 – courtesy Lynn Miller)

As an agile coach I help teams move from fixed mindset to agile mindset using Shu-Ha-Ri technique (It is a Japanese martial art concept that is used to describe the stages of learning to mastery.) to effectivity fulfil their responsibilities in their new roles.                                            

Shu

• Teams have fixed mindset about frameworks
• Might give up when changes come/Upset with failure
• Might get defensive or blame others in retros

Ha

• Teams moving towards growth mindset
• Will have mixed traits of fixed and growth mindset

Ri

• Focus on journey than result, keep learning
• Embrace challenges
• Never give up
• Take criticism positively
• Celebrate each other’s success

Help teams from Doing Agile to Being Agile

Shu

• Follow Agile blindly
• Reluctant to change
• Need facilitation and training

Ha

• Recognize Agile Values
• Do well with changes
• Need mentoring and coaching

Ri

• Embody Agile Values
• Embrace Change
• Self-Organized

Most teams fail because they do not go beyond Shu OR jump directly to Ri without adhering to values and principles (see attachment 4).

Finally, the 3 common themes across all roles are:

• Work incrementally: Always strive to produce a potentially shippable product increment within the sprint.
• Work iteratively: Functionality can be revisited in subsequent sprints.
• Work beyond your specialty: To create something potentially shippable by the end of the sprint, individuals need to be willing to work outside their specialties occasionally.

Agile mindset and ways of delivery are crucial for any organization in today’s world to remain competitive in the market which is characterized by fast pace. And there are organizations with some small percentage which are still in traditional ways and there are many which are Agile but not effective in their structure & culture. Despite of having its numerous benefits which are evident, the transition is complex, time consuming and there are challenges at organizational level. In this solution, I am proposing 6P + 6P model and the ‘what’, ‘why’ & ‘how’ to do.

Approach:

First 6P: Purpose, Problem, Picture, Pain, Progress & Path

Purpose: Why do we need Agile transformation and ways of working?

Agile gives importance to customer early feedback. Changes are honoured as per priority and risk is minimized. We will have happy teams as they are empowered in decision making. It works where upfront planning is not needed & emphasizes on delivering high value early & often which delights customer.

Problem: What is the problem that we are trying to solve?

• Heavy weight process.
• Customer is not involved till the end of the release.
• Delay in delivering value.

Picture: What is that we want to change and achieve?

Understand what your current picture is w.r.t. structure and culture and what is your desired picture.

Pain: What are the challenges that we are facing in this transition?

• Failing to communicate vision & strategy.
• Rushing the transformation process.
• Failing to provide support and/or get buy-in at all levels.

Progress: Inspect the progress to know how far we have reached and how much to be achieved.

Path: Adapt whatever is needed to achieve objective.

How to execute this?

Once the first 3 P’s (Purpose, Problem & Pain) are identified initially, focus on the next 3 P’s (Picture, Progress & Path) during the transformation.

Then execute the plan on other 6 P’s: People, Policies, Processes, Principles, Practices & Product.

People: Broadly in any organization, people with different responsibilities are at 3 levels.They are

• C-level – senior leadership who create the vision or taking decisions at highest level.
• Middle management who are a kind of bridge between senior leadership and teams.
• Teams who work at ground level.

C-level leadership:

• Sponsor the costs involved for training, coaching at all levels in the org including them.
• Leadership alignment & ownership.
• Establish & execute important metrics at enterprise (attached sample enterprise measure)
• Culture – Invest on people & change your ways of working w.r.t. customer collaboration.
• Structure – Execute changes in hierarchy in org which supports cross-functional & self-managing teams.
• Expenditure - Spend on right technology, tools, people with right skills etc.

Middle management:

• Support to inspect & adapt.
• Infrastructure – Invest on underlying foundation of an org that supports continuous delivery.
• Mixture – Plan & execute right mix of all skills that are required in a cross-functional team to deliver great products.
• Nurture – Help teams grow in delivering working software frequently, to work with business and have attention to excellence in quality.
• Work with teams in establishing KPI’s, milestones and metrics to measure and realize success.

Agile kills manager roles – No, it is a myth. In fact, they are better utilized.

The only change is that project managers are not going to be in command & control mode. They have different responsibilities with more visibility & recognition.

• Managers should actively coach individuals to advance their skills & can take care of knowledge management.
• Create an environment that supports open communication & innovation 
• Ensure team is aligning with company’s vision and values.

Value: Managers become servant leaders.  

Teams: Now with the trainings and with cross-functional teams which are self-managed, teams to focus on product mindset. All team members act collaboratively and share ownership.

Anyone who is willing to transition to Product Owner role (if following Scrum) to be given training. Those should be doing extensive market research, understand customer needs, wishes, wants, and understand your product and how it helps in solving customer problems.

• Architecture – good design and patterns
• Feature – characteristics and offerings in our products
• Manufacture – build great products that delight customer.

Policies:

• Develop org to be customer centric. Develop a life cycle to collaborate with customer. (attached customer life cycle)
• Maximize flexibility.
• Create outcome and value driven work environment rather than blindly chasing numbers.

Processes:

Based on your customer needs and nature of product select your ways of working. Be it Scrum, Kanban or anything.

Principles: Org transformations need not be fancy and all it needs is to focus on 12 Agile principles and have checkpoints every now and then to identify the deviation & required steps to get back the focus.

Practices: Establish and encourage right engineering practices for continuous delivery of working software. (Attached technical agility)

Product:

• Developing the mindset of being customer centric.
• Producing MLP (Minimum Lovable Product).
• Understanding the ‘why’, executing and delivering customer delight.

How to pilot with a small team? (Role transition to follow Scrum framework as an example)

Traditional BA’s act as a liaison between developers and stakeholders whereas PO does market research, works with customers, stakeholders, and gathers product development needs etc. So, either hire a PO from external source or nurture BA’s and train them who are enthusiastic to be PO’s and take additional responsibilities.

The 3 roles in Scrum share the responsibilities of a project manager. We still need PM’s to work as technical coach, knowledge management, hiring, growth, appraisal’s etc. If PM’s are enthusiastic and willing to transition to other roles, they can also take PO role if they love being accountable for ROI. PM’s can become PO’s if they limit their focus to ‘what’ customer wants, ‘why’ do they need it and ‘when’ they need it. A good PO leaves ‘how’ part to developers.

Anyone can be an SM’s if they leave the traits of command and control, be selfless and focus on causing impediments and help remove them, facilitate and coach as needed.

Key steps: How to start and where to start?

Big bang approach will be a recipe for disaster as it is disruptive to above 6 P’s. Top-down approach may not be sufficient as agility is required at all levels. So, it is not a mix, but we need to have top-down, bottom-up as well as middle levels aligned at once and for this we need to start small depending on the factors like structure, big picture, and urgency.

• Identify people at all levels with specific roles & responsibilities with Agile Principles & Mindset – Training & coaching.
• Define OKR’s, KPI’s and establish events & artifacts.
• Leadership alignment.
• Train leaders, stakeholders, management, and teams.
• Autonomy at team level rather than hierarchical decision making.
• Move away from siloed teams to form multi-disciplinary, cross-functional & self-managing teams.
• Model value driven rather than output driven.
• Encourage acts of leadership at all levels.
• Start pilot project.
• Adaptive Planning – Just enough planning for shorter cycles
• Learn from failures.
• Create information radiators to visualize progress and to catch risks early.
• Involve customer and execute customer delight as an additional parameter at all levels.
• Scale – Extend the training and model to other projects/departments/units.
• Continuous Improvement – Use the best practices, lessons learned and apply this to other projects and sustain the process.

Transition and transformation go beyond a new method in IT, and it is a comprehensive organizational change. The transition effects all facets of operations including culture, structure & behaviour. This transition may be equated as switching from one sport to another or transforming a toddler into an adult. This is a journey with challenges and can happen with relentless focus on continuous improvement but not by giving steroids which is unwanted and harmful to our child. Role transition or any transformation is never easy and focus on Agile principles and adapt your ways to transform iteratively and in incremental fashion to deliver great value not just to your customer but also to your organization.

The best analogy for Agile Transformation

The most common definition for agile goes like this: "Agile is a set of different methodologies for getting software built. " Even according to Scrum Alliance, “Agile is an umbrella term that refers to a family of approaches that share common values and principles.” Conventionally, going agile or agile transformation means :

1. Sticking the "Agile manifesto" in the board room
2. Implementing "Agile values" (as much as possible)
3. Opt for any of the frameworks (Scrum, Kanban, XP, etc)
4. Using any tool like JIRA, Rally

However, over time, the agile transformation has changed. One of the visual coaches I follow on LinkedIn has explained the Agile transformation using an analogy called "Agile Onion". (The visual is taken with all credit to the creator, just to support my solution)

Agile transformation of an organization is eating this Agile onion, starting right from the first layer of changing the mindset. Each layer is supposed to be covering the different levels of an organization, from CEO to the team who does the groundwork.

• The most powerful piece of agile is the mindset and it is also the most difficult to achieve. Hence everyone from top to bottom in the organization hierarchy should be educated on how agile transformation is going to change things. From inciting an RFP to execution of the project, till the delivery, how agile changes input and output parameters of each step. Once the mindset is changed the next layers of the agile onion are not much difficult to eat (adapt, accept and follow). 
• The next layer of ‘Values’ is even equally important and even more intangible. What values one (agile) learning organization will swear by.
• Then the layer of Principles actually set the rules of being agile. Like having a shared vision, focusing on delivering value for the customer (not only the software), and driving insights and success checks with data-driven matrices.
• The Practice layer is following one such framework like Scrum or Kanban, and obeying its agility recommendations (for example in the case of Scrum; having scrum roles, creating scrum artifacts, and doing scrum events).
• If you look at the visual above, tools and processes are the innermost layer of the Agile Onion. It is fairly easy to opt for any big boards with post-its or Jira instances to efficiently drive the execution. 

Eating the Agile onior is not easy and it takes time. It represents the change of an organization’s culture from one place to another. It changes the way we think and interact. This takes time as it’s incremental. It can’t be done all at once. 

Role change with Agile Transformation, do we really need?

People often mix and confuse agile transition to practicing Scrum as execution practice. They say being agile means you should have Product owners and Scrum Masters to be in the game. However, agile is an umbrella term. I feel we dont new roles (I might quote an exception later) when an orgnization level agile transformation is going to happen. The same people (Taking example of a software project) Top management, BA, Project Manager, Development team can make this shift happen with right mindset and eduction. They can still work under the same role with few pluses and minuses in their responsibilities. Regardless of whether a project manager is managing an agile or waterfall project, there are some standard tasks that a project manager is supposed to do :

• Facilitating project planning
• Planning project resources (people/ tools/ Infra)
• Supervising the project timelines and budget
• Communicating with the project stakeholders (which could include the project team, clients, and senior management)

The difference comes in the mindset. An agile project manager places a high value on continuous improvement and incorporation of early feedback along with doing above tasks. Likewise in agile, we talk about having a self-sufficient, cross-functional team. So, post the agile transformation Dev and QA teams will not work in silos. They will work together being part of the same agile team and will hit the target collectively. The success will be a shared reward, unlike waterfall where bugs are devs dirty games and successful delivery is a feather in project manager's hat (not intend to hurt anyone). Of course the team needs a mindset change and training of delivering in agile way. 

Example of how a team gets changed to an "Agile team", what changes 

This new role can be a game changer 

However, one role that can help in the overwhelming process of transition, value shift and mindset change. "Agile Coach" works as a trainer, mentor and continuous improvement agent who can sermonize agile at all levels.

• He is someone who encourages teams to adopt, mature and scale.
• An agile coach helps in crafting unique solutions for organization-level distinctive transformation problems. 
• An agile coach can work as a keen observer of projects and can regularly monitor the adoption level.
• He can also help in setting meaningful matrices for the progress check. He can thus point out areas of improvement and refer to supportive pieces of training.

Conclusion

Except for onboarding an Agile coach, I don't see the need for new roles. With agile transformation, the role transformation also happens at each level in an organization. And it is mostly in the heads of people, the mutation of their thought process and mindset. The same project manager can work as a Scrum master, the same BA can play the role of Product owner and the same top management can take the seats of leadership. Everyone above the team level should be a leader and mentor, than being high handed report seekers. 

"Look around you. Everything changes. everything on this earth is in a continuous state of evolving, refining, improving, adapting, enhancing, and changing. You were not put on this earth to remain stagnant." Dr. Steve Mataboli

The above quote is true for the roles in an organization that is going through Agile Transformation. I think that people's roles and responsibilities should change and evolve, it's the only way to evolve the organization toward business agility. We're not the same people we were when we were born, we change and evolve over time. I think it's healthy for people to change and evolve, it keeps things fresh and exciting. We all change and evolve over time, it's just a part of life. Same way roles and responsibilities should evolve in an Agile transformation process. The current mindset, roles, and responsibilities are may not enough to achieve business agility. The meta change we should be looking for in all the roles is of moving from Directive to supportive roles.

Inspired by Flow academy, I believe a mature Agile organization has four meta roles categories. The person who discovers what is valuable, the person who manages the flow of the value, the person who delivers the value, and finally, the person who makes sure all the roles have the capabilities to do their job in the best way(Visual Attached Value Model for Agile Roles.png). Everyone does focus on their specific role, but it doesn't mean he or she can't do others' work. If we take the sports team's analogy, each person has their own role, like an offensive player, defensive player, and goalkeeper. If another team tries to shoot a goal, the offensive player will also try to save the goal while his expertise is to do offense. The technical term for this kind of team creation is called T-shaped people. T-shaped people are those who have a deep understanding of one area but can also work broadly across all aspects of a project (Check Visual for TShapeTeam.png)

Why do we need to address the role clarity?

When we are in a startup single person can do Value discovery, value management, and value delivery but as we scale each person should focus on their areas and collaborate with others to achieve business agility. While the organizations are going through an agile transformation, we may need to shift roles and responsibilities that are more suited for new ways of working. We need to clarify the role changes for the following reasons:

• To Reduce confusion, increase empowerment, and help teams work more effectively.
• Teams with Role Clarity are substantially more successful than teams without.
• We can hold each other accountable if we know what we are responsible for.
• Have empathy for each other's work. 

What is transforming and clarifying the roles and responsibilities? 

In my experience, while doing the agile transformation the main confusion is about the leadership roles. A traditional 'waterfall' style process has very little collaboration between differing roles and phases, for example. It does require a great deal of coordination of the different outputs of various roles. Because there are so many hand-offs between roles, communication is also essential. Often the coordination is made a visible part of the process – in stage gates, for example – while the communication may also be formalized as schedules, documentation, and project plans. Lyssa Adkins, in her book Coaching Agile Teams, distinguishes neatly between the two: "Collaboration yields that old adage: The whole is greater than the sum of the individual parts. Cooperation yields the sum of the parts." In Agile teams, in general, we have these roles

• Scrum Master
• Product Owner
• Team Member
• Team Manager

So Who is the Leader in Agile?

Most people answers: Product Owner!

The clever second answer: Any Team Member!

What about the Scrum Master: are they just Management?

The correct answer is they are all leaders in their own area and need to collaborate with others to get the whole thing done. Even David Marquet talks about the leadership-leadership model in his book "Turn the Ship Around!: A True Story of Turning Followers into Leaders" 

So we have four kinds of leaders to focus on in four different areas to enable the scaling capability to achieve business Agility(Visual attached AgileLeaders.png):

Value Leaders -> Value Discovery

Flow Leader -> Value Management

Quality Leader -> Value Delivery

Coach Leader -> Capability Building

To give you an example, A software development team knew that it needed to gain client feedback on each new piece of code it was turning out. The team's manager insisted that nothing could be shown to the client until he had passed it personally. Since he was swiftly overloaded with work, very little was flowing out to the customer, which meant the team continued working in the dark, knowing full well that much of what they did would need extensive revision. 

And all the roles have to move from Directive to supportive roles as we want the teams to move towards Autonomy and self-organization. J. Richard Hackman mentions in his quote, "Over the last several decades, the dysfunctions caused by managers over-specifying and controlling aspects of a team's work in real-time have been amply demonstrated to hurt both people and organizations." Far more effort, time, and thought are required to define goals and bound teams than most managers give properly. The good news is that far less time, work, and thought needs to be spent overseeing the team than is currently devoted to it. Unfortunately, this is a switch that many managers find hard to make. So holding hands and helping them understand is the key here. (Visual attached to move from Directive to supportive.png )

How can we create role clarity?

I think, Agile Does Not Assign Leaders; they Emerge. Like a flock of birds, a swarm of bees, or the legs of a robot in an MIT lab. Emergent behavior is simpler, stronger, and adaptive to the situation. Therefore, the team works with little to no assigned roles or leadership. Empowering teams with autonomous people means little positional power. The Agile Leader must emerge based on communication & decision-making. But it doesn't mean that we will not assign roles at the start. The practice we adopted to clarify roles and responsibilities is inspired by the RIOT Games' work. (https://www.riotgames.com/en/work-with-us/disciplines/dev-management/riots-agile-team-leadership-model-a-story-of-challenging-convention)

For every team I build to achieve an outcome, we use similar techniques to the RIOT Games model. With stakeholders, we define the roles like PO, SM, Architect, Manager, Coach, etc. We create the list of responsibilities needed to achieve the outcomes and let each team member pick their responsibilities from the list. 

The difference we added is to have an accountability check every quarter to assess if the person can deliver the responsibilities s/he has committed. It can be a conversation starter to address the capability issue and move the responsibility to a different person; as I mentioned at the start, leaders emerge. That results in creating a true leadership-leadership environment. 

Conclusion:

The organizational roles in an Agile transformation process play a vital role in the success of the transition. The roles are responsible for delivering value to the customers and stakeholders and ensuring the software products' quality. The roles are also responsible for the communication and coordination among the different teams involved in the transformation process. The roles help in ensuring that the transformation process is smooth and successful. The new way of working needs new responsibilities, and leaders need to bring clarity about their specific roles to scale and achieve business agility. Organizing roles around value streams like value discovery, value management, value delivery, and capability building can create the focus the teams need. 

For any organization , delivery to the customer is the top most priority. Agile transformation helps them to tailor their services and products to adapt the the current trending market needs. 

This transition to Agile transformation is influenced by many parameters like  

Leadership management and commitment

Project nature and delivery

Team size and skills

Knowledge on Agile practices

Process of transformation happens in 

Form,Norm , Perform and Scale

Form : Identifying different groups of project teams for adoption of the Scrum method. Mentors are selected to train the team with agile practices

Norm  : Team along with all stakeholders discuss and finalize on a norm to be implemented for all the teams

Perform : Teams learn and implement them in their daily activities to measure the changes and metrics.Data to be gathered to witness and back up the change. 

Scale : With data and graphs , Continous improvement to get better and deliver incrementally with good quality.

One of the theories to implement this is grounded theory - It is a set of carefully grounded concepts organized around a core category and integrated into a hypothesis to be applied on a set of teams.

(1) description of the organizational roles transition during the Agile transformation process

 (2) the application of the grounded theory method in software engineering

 (3) implications of the results on theory and practice.

A few instances to establish the same are 6Cs

Context, Conditions, Causes, Consequences, Contingencies and Covariance

Context is called out with the team and adhered to .

Conditions - The current project and market conditions are deeply studied and road map is prepared

Causes - Any slowness/ impediments are called out and the root cause is identified. 

Consequences - For any implementation of practices , its consequences are agreed to by all stakeholders

Contingencies - All the risks are foreseen and listed out and buffer is reserved for the unseen and unpredicted

Covariance - the essence of the project and team is protected. 

Reorganization — Transition to agile requires a redefinition of roles and the way the project is executed. The traditional roles need to evolve/transform. Roles should be made multi-functional than specialized.

There are some roles that Scrum adheres to 

Product owner

Developers 

Scrum Master

Any project that is following non Agile model wil have various roles that gets shrinked to the above umbrella to adhere Agile's portfolio and its values. 

Eg : I had a chance to be a part of a team to witness agile transformation which was following OPL Operational life cycle. 

Many roles like DM - Delivery manage / RM - Release manager / PjM - Project manager are all transitioned to Product owner with the responsibilities

Many roles such as ValidationEngineers/ DBA / Support Enginers / Technical leads / Architects are categorised under developers

Scrum master facilitates and supports the team to adhere to the Agile practices and deal with the impediments causing slowness for the team and to tackle dependencies . 

All the above motivates the team to feel equal and do their bit for the progress of the team and hence project collectively. Being transparent with small to medium sized team excercised trust and ease to handle things . 

As we think of transistion we remember the transistion of caterpillar to butterfly which may take few weeks to observer this change .However transistion of roles from waterfall to agile transistion is not so visiable and cant happen in few weeks.

This transistion needs a lot of coaching and mentoring to the existing roles to transistion to agile roles like PM -->Scrum Master and Business Analyst -->PO's and Developers and testers to work as one team .

In my experience onec Oraginzations calls themselves as Agile then immediately we see roles tagged to agile and the expectation would be to switch in to the new role from day1 and this leads to unintenionally make it a hybrid framework mix of waterfall and sort of agile .

Which not at all helps to become a true agile organization.

To over come this hybrid ,we can start with training on new roles and responsibilities and make them go through mentoring and on job training and coaching and allowing them to do Gemba's with other teams where Agile is followed .

I believe in the above way helps to transistion roles from waterfall to Agile .

In today’s highly challenging world due to globalization, most of the organizations are having workforce with a mix of employees coming from different countries which means people are from different cultural backgrounds. This doesn’t mean cultural differences are only because of people from different countries and we may have it with people from different religion, location, community etc. Cultural diversity can be a valuable source of creative solutions only when different perspectives are encouraged, explored & executed. Due to this globalization, we have distributed teams and also due to recent and ongoing Covid-19 pandemic, teams shifted to remote working. So, with cultural diversity & especially with distributed teams, organizations are facing many complex challenges like misunderstanding & misconceptions resulting in strained relationships among teams and partners which are leading to poor results.

For us to deal with cultural differences let us first understand what is ‘culture’ and what are the types of differences? To put it simple, culture is nothing, but knowledge and values of human regarded collectively.

Broadly, there are 4 types of differences. They are

1. Differences due to behavior issues
2. Differences due to skill gap issues
3. Difference of opinion &
4. Cultural differences.

I am not diving deep on the first three as this solution is focused more about bridging cultural differences.

Why do we get cultural differences?

• Lack of common understanding among people from different countries, backgrounds, religion, race, gender etc.
• Lack of clear communication or different styles of communication.
• Lack of respect.
• No idea about the usage of region or their location specific jargon, idioms & phrases.
• Time zone issues etc.

Who can fix this?

Most of the organizations have Top-Down approach with senior leadership identifying and fixing. But this should be both Top-Down & also Bottom-Up where anyone in the org can realize, discuss & fix.

How to bridge cultural differences in distributed teams?

My approach to bridge cultural differences is to do it in 3 phases i.e.

Inspecting -> Adapting -> Bridging

which is aided by my own framework named ‘CULTURE’.  

Phase 1: Inspecting (Attached cultural values difference)

Identifying the cultural differences in an organization.

• Signs of ‘we’ vs ‘them’ in discussions.
• People getting offended with others manner of speech.
• Strained relationships with people from other country/background/religion
• Poor business results due to lack of harmony and teamwork etc.

Examples of cultural differences:

• People from Bulgaria typically shake their head to mean “yes” whereas people from US nod their head. This may be assumed as disagreement, but it is not.
• People from few cultures may tend to say ‘Yes’ to majority works even when they full on their plate whereas others may candidly say I am busy right now and can get back.

Phase 2: Adapting

Adapting means we should adjust ourselves to fit in. But who should adapt to whom is the key. And it creates tensions like why I should compromise. No one should compromise on their cultures or religious beliefs for others sake but each one should try to hit the ground by adapting themselves and align as per the org policies and converge towards common goal without hurting each other.

Phase 3: Bridging cultural differences

‘CULTURE’ framework

C – Code of Conduct

U – Understand

L – Language and Listen Actively

T – Transparency & Trainings

U – Unite

R – Respect & Recognize

E – Encourage team bonding, establish working agreement

Code of Conduct – Establish Code of Conduct as a framework to follow which are culturally neutral and should have guidelines on expected behaviors. Also conduct alignment meetings as per the agreed upon cadence to establish & reflect on the rules, policies & guidelines for entire organization. Everyone has their own approach to tasks or problems. So, the code of conduct helps us in bringing in the culture of inclusivity. (Attached sample code of conduct)

Collaboration – Encourage collaboration by connecting employees through various platforms. Make use of innovative tools and methods and ensure marked focus on information exchange which help us achieve better outcomes.

Understand – Understand the non-verbal communication, language, values & etiquettes. Help everyone in the org understand this by repeated explanation with examples and ask for clarifications. For this, leverage some visual techniques as visuals will have more impact when words fail to convince.

Understand what good behavior looks like and give some time to understand others not just from professional standpoint but also personally by spending time with them.

Develop a common understanding w.r.t. time zone, planning, acknowledgement, disagreements etc.

Language – Everyone in the org might be speaking same language but certain forms of slang or diction can often be misinterpreted. So, develop a neutral language with zero usage of region or culture specific idioms, quotes, or phrases.

Use language effectively does not mean using words which are not frequently used. It means to use simple concrete words, not abstract words. Use a calm and soft intonation as people tend to absorb information better when listening to a calming tone.

Listen actively – When we focus on listening rather than pushing our comment, we do not really worry about our next comment. So, listen with an open mind and then ask right questions.

Do not let assumptions and biases to generalize one person’s or one team’s behavior in entirety. For ex: US team never incorporates our review comments, Poland team never gives us opportunity to lead.

Trainings – Plan and execute org wide trainings atleast once in a quarter on what is culture, cultural differences, effects of it and how to deal with it etc.

Transparency – Everyone in the org should be transparent in raising issues that arise due to cultural differences. And for this, leadership should ensure psychological safety for teams to open up. A transparent leader is sincere and objective. Facial expressions and body language are very crucial when we are having conversations with international teams. Ex: In some cultures, looking into others eye is a sign of transparency or honesty but in other cultures it is considered impolite.

Unite – Employees may be from different countries or cultures, but we should unite them by teams and bring in ‘teamwork’ rather than team work. We should unite them by giving aspirational goals to achieve. Nurture employees and give them the right environment for teams to be undaunted and united.  

Respect & Recognize – Respect each role regardless of grade, region, religion, gender etc. Recognize other’s efforts and bring in the culture of appreciation.

Scenario: In our org, we have dedicated time to recognize others’ efforts. We are also encouraging cross culture by rewarding based on points and this has wiped out few differences.

Establish & Encourage – Establish working agreements & values. Encourage employees to open up with their concerns. Encourage team building activities to bridge the gap.

Scenario: In our org, we have dedicated time once in a Sprint for casual chat. We conduct different games like member from other culture has to explain about different cultures festivals and rituals etc.

Practical scenario of how I dealt this in my org: One of the employees coming from a cross culture use to be sarcastic in his approach during topics about holidays & Indian festivals which has hurt me. To overcome this, I have first gone through our working agreement & raised this concern. And I informed that it is not an escalation and I wanted to deal with it first. Then I tried to understand his approach and concerns. I figured out that he feels there is an impact with too many holidays or leaves. For this, I ensured smooth hand-off and updates and then I collaborated with him and recognized his efforts on other works and established trust. And finally, I asked him if I can be transparent and shared my feelings & told him that I will appreciate if he respects our working agreement & he felt bad and stopped.

Attached ‘Culture Chart’ which I developed as an artifact which can be used for bridging gaps.

Conclusion: Diversity is increasing more than ever, and cultural diversity is a source of creativity to achieve project goals and cultural difference is the source of misunderstanding. We can definitely flourish in a cross-cultural environment through effective leadership, communication, respect, and reconciliation.  

How about starting with a story?

Back in 2012, I was working as a developer for a big-name US-based client. We had a distributed setup (Billy, the client IT manager from the US, Sam the client sales head from Scotland, and developers from India) and weekly update calls used to happen late in the evening for the India dev team. Billy always talked in a global accent, which means, with steady speed and pitch without using any slang. Sam, on the other hand, had a very strange accent. It was so difficult for me to decode his words despite he used to speak in English only. Hence I used to rely on my senior's explanation of Sam's feedback.

To my worst nightmare, one evening when the call started I realized only Sam and I were there for the weekly connect. I got a call from my senior to give updates and the demo to Sam. I got so worried as understanding Sam was close to impossible for me. Anyhow, I started giving the demo, and unfortunately, the dev website crashed while giving the demo. I started shivering as Sam started putting questions after questions. I was not able to understand anything but a few broken words. Somehow I understood that he asked me to check my local website setup and fix the error if possible. I checked my local code, it was running fine. Doing deployment on the dev server was out of my work area. By then I was in tears already, as the demo was a failure and on top of it, I was not able to understand much of Sam's comments. Then I heard Sam asking "No luck yet?" and with a lump in my throat I replied, " I am very unlucky today as the dev site is not working as expected."  He laughed and sensed the situation (I was stammering and trembling).  We closed the call postponing the demo for the next week. 

Back to the agenda

Most distributed teams consist of people from different cultures, working from their home country with their unique ways of communication. As human beings, we think we can work from anywhere, with anyone from any culture. But after some time, we realize we are not understanding each other properly. Culture impacts our communication as it brings differences in behavior, thought processes, work ethics, and the ability to be open. Other cultural differences can be whether people are relationship-oriented or extremely professional, whether they tend to say "yes" all the time, or they question even the simplest thing. 

My current team is both India and Germany-based. I work with people from Germany who prefer speaking in German, work differently than we do in the India team, have people with big age differences, and hold many holidays on their calendar. Going a little deeper in terms of giving examples of differences, my Indian team works minimum 160 hours per month, whereas they work only 120 hours. German counterparts don't like pinging them over the company's communication tool. They prefer having calls within their office hours, especially in the first half of the day. (Connecting dots with the incident that I shared in the beginning) It is difficult to understand a few of these German colleagues (they like using the word "colleagues" for teammates) as they speak in their unique way. So when we started the project, there were many challenges. However as always happens, we learned to manage these differences. During the adjustment phase, I read somewhere that cultural differences are meant to be handled and not overcome. Hence we as a team have accepted these differences and believe in finding a mid-way to run our show. 

Fair need of distributed teams

Distributed teams are the benchmark for many organizations today. Being global means working with distributed teams, showing presence across the globe, and flashing the badge of being a scaled organization. Diversity of thoughts, innovation, and going "extra mile" are the things that set a perfect base for having distributed teams coming from different cultures. As per Harvard Business School professor Roy Y.J. Chua, the presence of team members from different backgrounds and experiences can stimulate new thoughts and approaches to problem-solving. It can further make a way for innovative products and services, solution acceleration and financial returns for organizations.

However, it is tough to manage cultural differences. Cultivating cultural intelligence and meta-cognition across the workforce is even tougher. It is easier to welcome a misunderstanding that originates from cultural gaps within distributed teams than to create harmony. Hence, it becomes necessary that management work hard to build trust and respect between people of diverse backgrounds in a distributed workforce to boost cross-cultural communication and collaboration. For example, GitLab Inc created a comprehensive Cross-Culture Collaboration Guide for its employees who are based in 45 countries.

What a project owner should do?

This visualization can put a strategy in place:

Examples:

Supportive case study (not so popular though)

How my current project survived and going well in a culture-distributed environment is one of the best examples that I can share as a case study. With my team of both Indian and German people, communication was the most complicated thing when we started. I discussed this with my leadership and proposed to have someone good at understanding the psyche of both the country people. Thanks to my management, soon we were given a new team member "consultant" who acted as a “cultural broker”.

Our consultant was a shared person and his job was to become a bridge between the German and Indian teams. It was an excellent step as our new team member was very helpful in addressing cross-cultural conflict. The consultant used to join our calls (scrum events and a few ad-hoc as well) and our communication improved big time. For teammates who have a preference for communication in German, he used to translate our talks. He helped in selecting meeting timings, drafting emails, and understanding how to become familiar with the German team. I learned a few sentences from the German language like; how to say Good morning/afternoon/evening, how to ask about weekend plans, and how to wish them on different occasions. In two months, we were far better than how we started. I still have the same team and our collaboration has improved a lot. 

Other rituals we opted for are:

1. Showing more empathy for each other
2. Creating and maintaining documents in both English and German
3. Staying aware of cultural norms and work ethics/practices (Eg:160 hours vs 12 hours of work)
4. Respecting meeting time preferences and communication medium
5. Fun Fridays, virtual birthday celebrations, and team lunches (they are equally important)

What management should do?

Find good team leads and project managers/owners. If leaders put the effort to create an environment that consistently encourages and supports cross-cultural respect, it will pay off in the long run.

Conclusion 

It’s one thing to have a cross-cultural team, but it is quite another to lay the groundwork to enable trust and respect between people of diverse backgrounds in a distributed workforce. Above are some recommendions I made for leading multicultural distributed teams. There can be even better ways, we just need to explore and practice with patience. 

July 2006, I was undergoing business etiquette and communication training in my first organization. Soon after coming home, I was trying to break chapati with knife and fork and this pissed off my grandfather. When I tried to explain that it is not right in western culture to eat with hand, he roared back at me, “WHEN IN ROME, DO AS ROMANS DO!”. (See Attachment 1 for some fun; source: https://www.pinterest.com/pin/532550724686499024). Hence, its not just about knowing ones culture, but we should be aware of WHEN and HOW to adapt it.

So, what is Culture? Culture is an umbrella term which encompasses the social behavior, institutions, and norms found in human societies, as well as the knowledge, beliefs, arts, laws, customs, capabilities, and habits of the individuals in these groups. Culture is often originated from or attributed to a specific region or location. (source: Wikipedia)

Why is it important to understand one’s culture?

Developing an understanding of other cultures, lets you have more meaningful interactions with those around you. You’re building respect and empathy for other people and celebrating your differences as well as your similarities. This makes you less likely to treat someone differently. This doesn’t mean that you must be an expert in other cultures. It just means being willing to be open-minded and to ask questions to get more information, rather than having a knee-jerk reaction to anything you don’t agree with.

Last week, I was analysing last 6 sprints retrospection data across 20 teams in which 15 of them are distributed across India and USA. 80% of opportunities of improvement(problems) were around 3C’s i.e., communication, collaboration, and coordination. While time zone difference is one of the primary reasons for these problems; not putting an effort to bridge the cultural gap between these locations is another major reason. This reason is always brushed under the carpet. It becomes even more important in Agile environment where most of its values and principles are around communication such as:

• Individuals and Interactions OVER Processes and Tools
• Business people and developers must work together daily throughout the project.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Let’s see some ways to bridge the cultural gap to improve communication and collaboration.

• Don’t make assumptions: Stereotypes are mostly negative images or preconceived notions about a specific community, group, or culture. The basis of stereotyping can be many things, though the most common are nationality, gender, race, religion, or age. This creates prejudice among people of different cultures and causes judgmental attitudes towards one another. People look at other cultures with certain stereotypes as “bad” or “difficult to work with”, or “incomprehensible” and treat them with contempt and disrespect. If you are working with someone from a different culture don’t assume anything about that person based on how they are communicating with you.
• Ask Questions: This is linked to the first one. The biggest way to get around those assumptions is to clarify them by asking open-ended questions. The more you can understand about somebody else’s cultural expectations, the more you’re going to be able to work collaboratively with them.
• Don’t expect another person to adapt your style: This often happens in an environment where there is a majority culture and a minority culture. The problem here is extremely stifling. What’s important here is that we all learn to take a step towards the other person. So, instead of there being an expectation on the other person to adapt, what if we both looked at trying to understand one another’s communication nuances and taking a step towards each other and kind of meeting in the middle. Organizations who embody this philosophy, have most collaborative communication which leads to far fewer communication breakdowns that cost tons of time and money.
• Reconcile differences: Here you apply knowledge and cultural empathy to bring differences into agreement or harmony and pursue your common goal or objective. How?

Solicit uncommon information. Rarely does one person have all the pieces of the puzzle and when people from multiple cultures work together, gathering all the needed information can be a challenge. People from one culture might be reluctant to implement practices from another culture. To overcome this, we need to help the group develop a shared understanding of what needs to happen, so everyone can focus on the results and not get bogged down on the way things are usually done. This is where vision, mission, goals, processes, and procedures help.

• Understanding High Vs Low-Context Culture: The concept of High and Low context culture relates to how an employee’s thoughts, opinions, feelings, and upbringing effect on how they act within a given culture. Low context culture has individualistic people who tend to base decisions on facts. This type of business person wants specifics noted in contracts and may have issues with trust. On the other hand, with high context cultures; trust is the most important part of business dealing. Individuals in high context culture, will be interested in knowing the person with whom they are doing business with, to get a gut feeling on decision making. They will be interested in business teams’ success, rather than individual achievement.
• Know the Non-Verbal differences: Gestures and eye contact are two areas of non-verbal communication that are utilized differently across cultures. Extreme gesturing is considered rude in some cultures while it is normal in other. Same thing goes with pointing fingers; Chinese doesn’t prefer it. In USA, eye contact is a good thing and is seen as a reflection of honesty and straight forwardness. However, in some Asian and Middle east countries, prolonged eye contact can be seen as rude or aggressive in many situations.
• Don’t be afraid to make mistakes: Adapting to a new culture or language is not easy. Be proud of your efforts and learn from your mistakes. Pause, stop and think before acting or talking, even if only for two seconds, this will give you the time to better understand what the other person is telling you, to observe your own emotions and to choose your words. Say what you mean with kindness and calm. Take your time to explain what you are doing and thinking.

As an Enterprise Agile Coach, below are few things which I tried to improve collaboration across distributed teams:

• I gave some tips to scrum masters on how to deal with the team members who are resisting to keep the video on during the virtual meetings. Most of them deny because they will be multitasking, and they do not want others to know about that.  One needs to understand – “The quality of your attention, effects the quality of other people thinking.”
  • Do not force everyone; but always communicate the purpose behind having video ON.
  • Start with asking to keep the video ON for first and last 5 min. Say it is an experiment.
  • Make it part of your team agreements.
  • You can only turn ON video while speaking.
• Do not Forget Fun:  Laughing together and having fun together has a big impact on our overall positivity and sense of connectedness.  Leave some time in the beginning or end of your meetings to connect on a personal level and do fun things like wearing your favourite t-shirts, sharing your pictures of your favourite memories, etc.  I have shown few ways to celebrate wins, since success is nothing until we celebrate it. Like:
  • Digital drinks
  • Having dinner together at same time
  • Cutting a cake and celebrating birthday was fun
• Super Squad: Taking a que out of Agile-A-Thon, I introduced super squad which is an award given to squad who do exceptionally well in both qualitative and quantitative metrics that are identified. Top 5 teams will be selected based on quantitative scores and sent to panel (senior leadership) for their qualitative assessment. Super squad is selected based on overall scores (See attachment 2). This helped teams to work together on common goals in while they are distributed.
• Question in Daily Scrum: I have made teams to add a point in Daily Scrum where each member will tell if there is anything they will do to help another person. This made each member think and act like ONE TEAM. I have got huge praise for starting something like this.

In our organization, the management sends people across locations to collaborate and understand cultures. Finally, everyone must take ownership to bridge the cultural differences and become better individuals.

As a Scrum Master , I never thought in my career that Cultural Differences can give a BIG BLOW and persuade me to deeply think over it.  Yes the word - Big Blow is correct which you are reading here. 

[Let me tell you the situation which I went through to understand the impact of Cultural barriers]

*****************

One fine evening 3 years ago, I was literally sitting on my desk with a Face Palm moment.

We completed 3 sprints of the release and one of the Team named ALPHA told me that none of the story is getting completed because of the complexity of the feature.

I reminded myself that

• We had Sprint Reviews Completed with Product Owner
• We had Stories Completed in JIRA

[When I asked from Team ]

• We assumed that we can figure out the complexity and dependencies while working in the sprints but SORRY we are not …we tried
• Product Owner said that I thought we can do it so I didn’t highlighted much at Sprint Reviews
• There is so much pressure on us to complete so we could not say that there are so much dependencies from upstream and downstream 
• You are the Scrum Master and you were not present in the Sprint Reviews ..you just start the demo and then leave …( Oh my god after hearing this … I actually thought that it was very wrong from my side too)
• Most important thing there are few members from other country whom we can not understand much - what they mean and what they think ?

[ I just asked my Team - ALPHA ]

Why you said YES in every meetings

• Yes requirement is clear
• Yes we are on Track
• Yes we can figure it out

[ From ALPHA Team ]

We were afraid to tell the TRUTH as no one speaks here much.

I immediately said To Team - Let's talk tomorrow . I need some TIMEOUT  to think now. 

*************

At that time I was handling one more Team named BETA  too.  Honestly I was very displeased with that Team.

Reason - They were very Outspoken. They never told me YES in each of my expectations.

That night somehow it clicked me when I was winding up my daily chores

• How are both Teams different from each other ?
• What is that different attitude in both the Teams?
• What is the similarity in both the Teams ?
• Why is that the BETA Teams commitments always are 80-90% close to delivery ?

I started writing whatever was coming in my mind

• ALPHA Teams are having fear in their mind - No Psychological safety 
• ALPHA Teams have certain cultural barriers which needs to be resolved - Like saying YES in everything and not getting along with other region people
• BETA Teams are having no fear in their mind - There is Psychological safety and they were collaborating well with each other.

Is this because they belong to different cultures and are driven by different values and thought processes? Some are taught - You should always compromise and bend as per the situation. Some are taught - Speak for your rights with authenticity. With these thought processes a PERSONALITY is created from childhood. I also correlated that as a developer how I use to Say YES in every expectation of my Team Lead.

Next Morning was my Action day. This can not continue as it will not be beneficial for my Team and will not make a good Scrum Master. I shared this all details with other Scrum Masters and Coaches who were also very keen to bring a change.

Round the table we sat for 3 days and found few practices which we decided to implement in Team level but again we can not do ourselves as we can not impose on Teams so the idea was to show mirror to them that - Why we need to work on breaking Cultural Barriers? And the Team should Yes for going with the new practices.

We created a strategy

FIRST - Lets explain everyone in the TEAMS -  What are Cultural barriers and why we need to minimise the gap between different cultures ?

 [Arranged A Session with the TEAMS]

[ Opening Dialog for the Session] When team members from different cultures they come with their own beliefs , gestures , communication styles, different woking styles which MAY sometime become barrier for others. This happens if their lack of COMMUNICATION and KNOWEDGE SHARE between each other. We have to accept that culturally diverse teams produce more creative and innovation results than culturally homogenous groups. 

[ We asked few Voluteers from the Audience in the Session from different cultures to play the ball point game. Some members knew the game they started teaching others , some members were fast enough amd quickly understood the game , some gave some tactical approach to pass more balls. After few rounds the whole group mingled with each other and proved that - Though there are differences but our Similarity is that the GOAL that we have to play the game beautifully. They believed that for that event they are the role models to bring a change in the mindset of the audience.]

SECOND : Few steps to reduce Team Culture Differences

• Shuffle the Teams with different cultures and timezones
• Let each and every member of Team get a chance to work with each other in different tasks so that there is an ice breaker among the team
• Weekly kept some time to learn about different cultures by attending trainings in the Organization
• Talk slowly and breath properly while talking in meetings so that everyone can understand each other
• Learn some cultural gestures like when we are working with Spanish team member , greet them HOLA. Como estas hoy ?(Hello , How are you today ?)
• In all the meetings we use to ask frequently  - Do you want to ask questions any concerns ?
• Please dont be shy . Sometimes if questions asked by someone which is actually meaningful we use to give chocolates and appreciate them for asking and widening our thoughts. There should be no preconception that if we ask questions we will be judged. On contrary you will be appreciated.
• Avoid talking in regional languages in meetings as that makes others uncomfortable as they can not participate in the discussions
• Started taking feedbacks among the team members - where they will checkin each other. There is nothing to feel bad or good as noone will be insulted
• Use Collaborative tools like Yammer, Teams where anyone can help in any stream. People will talk each other and get more involved in activities

SECOND: Teams and Client Cultural Differences Its not that with team we need to gap the cultural difference but we need to gap with client too. After a set of time teams gets comfortable but what about Client comfort with Teams so we started upskilling us with Client Culture too with few set of programs.

At last  we all will agree that people are key to succes and we need to give opportunity to everyone to grow and develop and contribute to new challenges to stay relevant in industry. We can do best when each team member will do phenomental work in the team. This can only happen when there will be DIVERSITY in the Teams where each person will bring VALUE to the Teams which needs MENTORING and COACHING of the Teams more often. So I believe STRENGTH lies in DIVERSITY.

Introduction

Incident 1:

In 2007, I got an opportunity to visit Germany. I got few gifts/sweets to my counterparts. That was the time, where English is not much used and not all counterparts speak/understand English fully. With so much happiness, I gave the gift “Here’s small token of friendly gift from India”. My counterpart told on a lighter note “You came all the way to handover poison to us”. Later I realized that gift means poison in Deutsch…

Incident 2:

We had rewards and recognition practice in our department. For applying best project award, one of the supporting documents is “customer appreciation mails”. Hardly we used to get appreciation mail from my counterpart (Germany) whereas other project teams used to get appreciation mails often. Our team used to get demotivated and later I learnt that if my counterpart says “Ok/Fine”, it means we did good job ..:-)

At that moment, something struck me (refer figure1)

May be Agile consortium knows the importance of culture differences and ended up in 2 key elements: “Co-located teams “ and “face-face conversation”. (LOL)

In today’s world, it is quite challenging to have co-located teams. During pandemic & post-pandemic, face-face conversation at one location itself becomes very challenging. So it is important for everyone in the team including leadership team to accept and leverage cultural differences for team’s sustainability.

My team sits in India, Austria, Germany and Vietnam. I have shared few tried and tested methods to bridge cultural differences in distributed teams.

Method 1 -> Awareness

It is very much important to be aware of cultural differneces depends on the team composition. It’s not about getting to know about the culture in India, Germany, Vienna, China.. like how to greet, how to say thank you..etc  it’s beyond that. One has to understand hidden aspects of culture like:

1. Emotions
2. Fame
3. Pride

This can be achived through inter-cultural trainings. This is one of the mandatory trainings to be attended by every employee in my organization before he/she visits to Germany/any location and its validity is three years. This is followed across Bosch worldwide. I would suggest/recommend such trainings are to be conducted more often in a gamification manner for every employee in the organzation depends on the association of his/her projects in Germany, China, Japan..etc.

The other way is to bring the awareness is through team member onsite program. Atleast one month team members can be boarded at counterpart location to experience the cultural aspects.

To bridge the differences in the distributed teams, organization culture needs to be strengthened through associate exhange program. In our company, associates are exhanged at various positions to various locations and this has led to good understanding to run the business seamlessly.

Method 2 -> Create a shared mental model

Teams quickly develop habits for communicating and coordinating, without reflecting or thinking critically without kowing those habits help or hinder the team process. Hence for a SM/PO/team member, coordination and communication can be challenging across distributed teams.

For an example, Indians always come late for meetings, they won’t say no. Similarly Germans always come on time to meetings, they care about only quality, very direct in giving feedback..etc. With such bias, if team member approach each other, collaboration is not possible.

Our shared experiences allow us to develop a shared mental model -- defined as: “the knowledge structures held by members of a team that enable them to form accurate explanations and expectations for the task, and, in turn, coordinate their actions and adapt their behavior to the demands of the task and other team members.”

So, a mental model forms the lens through which we interpret our situation -- shaping our understanding of the task and how to accomplish it. Common team experiences and common knowledge give rise to SHARED mental models.

Teams that spend more time together to develop a shared mental model would be able to handle coordination and communication easier amidst of cultural differences.

One of the ways to create this shared mental model is through “Team Working Agreement”. SM facilitates the team to capture important information like team’s collaboration model, vision, mission, meeting details, SLA to resolve open points, DOR, DOD..etc. SM must ensure to keep the document alive, and points are to be updated/enhanced based on feedback from retros.

Method 3 -> Culture Map

This is one of the effective tools defined by Erin Meyer. Culture Map’ scales representing behaviors where cultural gaps are most common​. By comparing the position of one nationality relative to another one can decode how culture influences day-to-day collaboration.  This needs to be done during every team setup. (Refer figure 2 & figure3)

The other intresting tool developed by her is “Know your cultural profile” and this could be the best starting point for all the leaders to work on their own cultural challenges before taking to the team.To take the assessment, click here

Method 4 -> Beyond boundaries

Apart from shaking hands with team members for professional work, it is important to shake hands to know them privately. This helps the team members to create a bond between them and will help them to overcome cultural differences in the long run. We created this bond with in our team and now we are reaping the benefits:

1. Reserve 2 hrs to get know each other. We have shared few interesting introduction templates and gathered to understand each team member in various aspects like: hobbies, native place, favourite foods & beverages, movies..etc. In every meeting, default rule is to find commonalities between team members
2. During meetings, always start with general conversations. For an example, while calculating availability days for a sprint, if there is any mandatory holiday in any location, we spend few minutes to talk about those mandatory holidays. This helps other members to get an idea about the culture or happenings in respective country. Once I showed pictures of our golu duinrg Navarathi festival and other team members found it interesting and they understood “why” behind this festival. Such cultutal related small talks enabled the PO & the team to  respect every team member’s vacation or holiday plan. As a result, we as a team used to plan the commitments in advance, proactively handle the risks w.r.t on time delivery and stakeholder expectations.
3. 6 word story -> Asking team members to describe themselves in 6 words and that 6 word story forms the basis for everything they do both in personally and professionally

Outliers -> How to handle it

All the suggested methods would help to bridge the cultural differences to a greater extent. There are few areas where detailed focus is needed to bridge the gaps. I have highlighted couple of elements based on my observation:

• Appreciation -> This is one of the topics where we initially started thinking “one size fits everybody” but later relaized it is not picking up well across all product international teams.

For an example: Good work, keep it up -> expected by Asian team members and the same is not expected by German/Austria team members (they think it’s part of their job).  So peer appreciation culture is not picking up in international teams. Hence in our sprint retrospectives, once in a quarter, we trigger appreication. We request each one to provide 3 positive feedback along with one improvement feedback.

• Dealing with feedback -> People are hesistant to accept direct feedback and whereas few team members don’t hesistate either to give or receive direct feedback. So arranged a session on Feedback, emotions in our mind during feedback dialogues and figured the way to give constructive feedback using few formats.

Conclusion:

It is not our differences that divide us. It is our inability to recognize, accept, and celebrate those differences. -> Audre Lorde

According to me, leadership team, PO and SM plays a vital role in bridging the cutural differences and it is possible only with the mindset -> amidst of all such differences, there exists few common elements and that has to be brought in limelight for team success as well as these common factors are to be leveraged to balance the differences. They must invest quality time in addressing the gaps else cultural differneces would be the permanent impediement.

References:

1. The Culture Map book by Erin Meyer
2. Leading HIgh Performance Teams -> Course in Edx. Module4 -> Managing Team Communication & Coordination

In the last couple of years, we have seen working remotely across teams has become the norm as a part of the digital revolution. Management has gained the confidence that people across teams who cannot see, walk up to, and check up on them can get things done. Rather than policing workers, we are (mostly) trusting them to get the task being done. Companies are even taking measures to distribute working in the future, implying no regular office visits, shedding central office space, and promising permanently distributed workforces from home. 

However, working on distributed remote teams concept is challenging, especially when the team members have the impact of cultural inequality amongst themselves. Though the technology is improving, getting sufficient bandwidth and decent video conferencing tools is not nearly enough. There's much more scope to working effectively in a distributed setting than just having access to good technology and being able to see one another. This is where before we factor in the many sub-conscious queues we pick up when working face to face or the difficulty of the accidental discussions and shared knowledge that fuel innovation. Hence the need to understand what exactly bridges the cultural differences and makes great distributed teams comes into the picture. After all, Collaborating together is the beginning, staying together is progress, and working together is a success.

I believe there are four EPIC keys required to bridge the cultural differences and make great distributed, high-performing EPIC virtual teams (Visual Shown in the Image epicteam.png),

First, make sure the team members understand each other and have Empathy. Second, create a connection between them with a purpose to create belonging. Third, nurture innovation on your team. And finally, create an environment of collaboration with meaningful ways of working. Let us go deep and explore each key in detail with examples.

Empathy:

I believed that facilitating in-person events was my strength, and when the pandemic hit, I had to learn new things and do most of the training remotely. When I did a workshop, half of the attendees would not turn on their cameras, which frustrated me even more. I contacted HR and IT to get this sorted and help team members get the right equipment and right internet bandwidth so they can switch on their cameras, but there was no improvement. In one of the conversations with my sister, an engineer, we talked about this challenge. She suggested, why don't you mention in the invite that we have to turn our camera on. We generally start our work in bed; if we knew we have to turn on our camera, we would plan accordingly. And it worked, of course, not 100% but was a good improvement. While thinking more deeply about the reason why people prefer to hide their faces behind the camera, sudden self-realization came into the picture that I am mainly focused on end results, but why not understand the attendees more and listen to their side and get to know them better. In this way, maybe I can fill the gap between myself and my attendees. If we want to be effective in remote work, we have to be kind, and intelligent, and in short, just be a HUMAN (Visual shown how to practice empathy empathy.png). You can use many tools and practices to create an environment for collaboration but, the key to leading teams towards hyper-productive in remote setup is Empathy.

Purpose:

The challenge of understanding purpose is not easy, as the group's founder and initiator, Stefan Beiten notes: "Finding one's personal Why means peeling back layers of your personality. It's a process of uncovering something that has been suppressed rather than discovering something new." The basic requirement of a team is a common goal. This goal can be something as simple as winning a game or as complex as developing a new product. In order for a team to be effective, all members must be committed to the same goal. The team members must feel that they are a part of something larger than themselves and that their work is contributing to a larger goal. If they feel this way, they will be more likely to work together despite cultural differences. Connecting them with purpose is giving them a long-term goal that they all believe in. 

The Energy Project, surveying 20,000 American workers across 25 industries in partnership with the Harvard Business Review, found that deriving a sense of meaning and significance from their work had the highest single impact of any variable in the survey. Employees who did find meaning in their work also reported being 2.2 times more satisfied with their jobs and 93% more engaged. And, once they are engaged they will create connections with each other and that will reduce the differences. 

In one of my consulting assignments, I was coaching a team and team members were from across the globe. When I started they were individuals working on different stories in a sprint, all finishing their own stories at the end of the sprint. From the outside, they were completing their sprint goals and were high performing but from the inside, they were not at all engaged. Connecting them with a purpose and doing team liftoff activities (Diana Larsen's Liftoff Book https://www.oreilly.com/library/view/liftoff-2nd-edition/9781680501971/) brought them together. A sample team canvas is shown to connect a team to their purpose (TeamCanvas.png). 

Innovation:

Innovation only happens when someone stops playing by the rules, builds a different perspective to connect the dots, and achieves something beyond everyone's imagination. Innovation is fast becoming part of the business. Could you do with some inspiration? Then you might like these four awesome ideas taken from the success stories of companies whose innovative cultures are thriving.

1. Give team members unstructured thinking time.
2. Let innovation get messy.
3. Forget corporate communication – think person-to-person conversation.
4. Be hungry for feedback – every bit of it.

In distributed teams, we can't interact the way we used to do in person. So we need to know, How to reproduce the whiteboarding sessions and passionate arguments about the solutions you build?

Collaboration:

Despite the positive stance on collaboration, there are corporate barriers affecting not just employees' work experience but also the required output. According to the study, these are:

• Access to People
• Access to Information
• Outdated Technology
• Distractions

Organizations can help make collaboration more successful by trying to lay the foundations for the easier transfer of knowledge – a shared sense of company culture, a shared vocabulary and terminology when talking about processes and technology, and opportunities for people to get to know one another. This last suggestion often causes debate – do remote drinks and dinners really promote collaboration? My belief is, it may not miraculously break down barriers, but it does help break down the search barrier, as individuals build their networks by a combination of work and social contacts. For eg: You may not know who in finance will help you resolve a problem, but n at least a conversation with the t nice bloke you had over lunch can put you in touch with the right person. These informal networks can be powerful, however, it is also important to focus on the quality and diversity of the network. Rather like having lots of 'friends' on Facebook may not actually equate to true friendship, amassing the most business cards or contacts may not mean having the best network. 

Final thoughts, Since we are forced to adjust to a new virtual reality and pivot swiftly toward market demands, the in-house capability and flexibility become vital. As people continue to work from home, it's only natural for business leaders and HR specialists to worry about motivation and productivity drops. It's hard for people to stay engaged and connected with each other, and the work they do, while being dispersed for a common goal. We make it more difficult to communicate, collaborate and coordinate naturally and informally. One of the first things that we should consider is, the team members being motivated enough in order to ensure the appropriate productivity level and their satisfaction with work. A motivated organization will help drive you towards success, not only in these tough times but along the way forever. And, to build a high-performing team we need to bridge the cultural differences in distributed teams which means that each member understands each other as one group and not as individuals. Then, create opportunities for them to connect with a purpose. Next, foster innovation and collaboration through meaningful work. Finally, establish an environment where members can learn from each other and grow professionally.

Culture - The word by itself is very ambiguous , to set the context we are referring to a company / work culture. 

Certain peoples' behaviour, acts , norms , reactions forms a culture within the team and hence the company. 

Distributed teams are common these days and especially after pandemic , its the need. With remote teams working globally, high perfoming to deliver best is the normal ask. Its not easy to overcome the inherent challenges at work.

Distributed teams consists of people from different countries (language/timezone) , mindsets,perceptions, opinion, educational background, skill sets. When theire is a mixed version of people around , the expectation and interpretation naturally varies. People with different experience have their own beliefs . Remote working is an added challenge. 

What kind of issues or impact will the diffences cause

Global Vs Local , Assertive Vs Passive speakers, Accomodative Vs Rigid decisions, Work judged with time Vs Quality , Tema mebers being Collaborative Vs Competitive, Task oriented Vs Result Oriented. All these impacts the day in day out and the final product to a great extent

With the above , overcoming these differences to deliver faster calls for different ways to deal with these. 

1. It gets important to be aware of the differences the team has and to get educated with it. Being with the team , interacting with them , organizing work within increases the chances of same

2. Creating a fear less environment for employees to talk what they think plays a vital role. Engaging with them , acknoledging their views and appreciating it boosts their confidence and they feel valued

3. Being empathetic of the situation and people is important. Brainstorming and jamming up with the team members facilitates to understand them better and hence the bonding grows.

4. Trusting the team members with sharing work , facilitating such processes and policies gives way to mutual help and belief

5. Being transparent - Practising this across team and leadership mirrors day to day work and motivates people to do their best

Leadership can arrange several programs to resolve the above . They often act as Influencers.

1. Trainings

2. Office trips, lunch outs

3. Budget for engaging and extra curricular activities

4. Context for all team members with orientation on projects and programs

5. Company setting up offices in different locations. Head quarters in one place, development centres, remote places and so on

There are various tools to map these and to make these transparent too. 

1. Culture Canvas

2. Culture map

3. Culture graph

Hugo gives a very easy example of filling in the culture canvas as an Indian team meber Vs a Russian Vs American Vs Dutch to get the perceptions. Different parameters like openness, perceptions , creativity , responsibility etc can be gauged . Every geography might have a different answer for same parameter.

Alexander Osterwalder created a culture map to know a. Outcomes , b. Behaviours, c. Blockers  d. Enablers to understand the same cultural gap as different team members

Collating these across different dependent and non dependent teams gives us a good data to work with . Culture has a great influence on the team deliverability. Looking at these, investing on these at the right time will yield better.