Which agile model is right for you? What are the solution considerations?

Choosing the right type of agile model is of paramount importance. Enterprises are experimenting with Scrum Kanban, XP, Spotify etc. Looking at the user interaction and rate of change as two parameters, we can make use a specific approach. The following diagram gives one such idea.

In the table below, the considerations of application type, type of work, type of team, volatility etc. determine the applicability of different methodology.

Parameter	Description
Application Type	Strategic Maintain Run to Retire PoC
Volatility Type	High, Medium, Low
Work Type	Large/Medium enhancement Maintenance/Small enhancement Migration Large platform based Innovation
Variability Type	Small, Medium, Large
Team Type	Independent Frequent collaboration High collaboration
System Type	Stand-alone/Small Medium complex/Medium dependencies Highly complex/Multi-dependencies

Based on the above, we can construct a table that shows the usage and applicability of various models.

Parameter	Scrum + XP	Scrum	Kanban	Waterfall
Application Type	PoC	Strategic	Maintain Run to Retire	Maintain Run to Retire
Work Type	Innovation Platform	Large/Medium enhancements	Small changes	Maintenance Migration
Team Type	High collaboration Frequent feedback	High collaboration Frequent feedback	Independent	Independent
Volatility Type	High	Medium	Low	Medium/Low
Variability Type	Large	Medium	Small	Medium/Small
System Type	Large/Complex	Medium complex	Small / Stand-alone	Medium complex/Medium dependencies

What are the factors to be considered in designing the solution and commercials?

When working with a customer's IT organization that is in some form of agile, the solutions team need to consider the following factors and ensure their impact on delivery as well as commercials is understood.

Area	Considerations	Impacting
Transition	·           Current level of agile maturity across business units (Each unit can operate in a different level) ·           Current offshoring maturity ·           Usage of distributed agile ·           Consider various scenarios like: o   Waterfall to Agile o   Agile to Agile.	·           Knowledge absorption: Include pair programming and architectural runway (Existing code, hardware components and software functionality that technically enable near term business features) ·           Replication: Sprint based execution ·           Boot camp duration and costs (focus on Agile foundation, Agile Associate, Scaled Agile. behaviour aspect - People mind set, culture ·           open-up and express their view) ·           Include time and effort for doing agile assessment of the in-scope portfolio ·           Onshore ratio ·           Timeline
Steady State	·           Agile maturity of different business units ·           Level of life cycle management and DevOps tools usage ·           Type of full stack engineers required ·           Availability of roles like PO, Agile coach, Scrum master with the customer ·           Time proposed for transformation ·           Quantum of work ·           Current effective tools usage ·           Usage of DevOps ·           Current mapping of resource levels	·           Operating Model ·           Evolution of ToM across time line ·           Squad size ·           Release cycle ·           Onshore ratio across months/years as the customer moves up on the maturity curve ·           Type of resources and their distribution ·           Productivity % resulting from people, process and tools
Commercials	·           Physical Infrastructure ·           Connectivity requirement considering more online interactions / meetings ·           Typical squad size per ODC (there could be many special requirements per squad)	·           # Travels could be more as compared to a traditional model ·           Special infrastructure (meeting rooms, furniture, boards, interactive rooms etc.)  costs ·           Special equipment like monitor (big size, two monitors per person) ·           Additional tools/license ILF (initial License Fee) and RLF (Recurring License Fee) ·           Cost of baselining the resources of the customer and plotting them against standard models like SFIA or Dreyfus model ·           Recruiting costs (cost of running hackathon) ·           Cost of hosting customer periodically ·           Cost of building Academy ·           Cost of configuration/customization of existing tools, frameworks and accelerators ·           Training / Upskilling costs covering the initial training required to make the resources more engagement ready as well as upskilling as they move the Dreyfus cycle. The traditional training materials will not do.

Changes happening in Insurance industry impacting IT service providers

Usually people associate technology changes more with banking sector.  about insurance? Global insurance market is valued at $5 Trillion. How the people use insurance and even think of it have undergone a tremendous change. The expectations are different and so is the service catalogue from the providers. How is the technology shaping up the industry?

Here are 3 important changes driving this sector.

All encompassing digital transformation – New models / Personalization

Like any other industry, this has shaken the leaders as well as laggards. No one could afford to be complacent. The overall impact is very positive for both the organizations as well as the customers. Customers’ expectations are changing: They expect very specific bouquet of services, expect services anytime anywhere and through any channel. EY estimates that 80% of customers want better communication with the insurance organizations. And this communication has to work seamlessly across channels!

Big Data And Analytics will play a huge role. Are today’s insurance organizations equipped for collecting all data online and real time? Have they made changes to their organizations as well as the processes in order to make use of the data? Can they offer a single user based insurance and personalized premium based on the data available online? What are the ways to collect data in order to get a competitive advantage?

If 80% of the premium is lost due to distribution costs, imagine the power of digital models. Perhaps they will make the intermediaries redundant in the entire value chain. APIs will redefine insurer-insured-InsurTech relationships. Insight-driven offerings will be the buzzword! An insurance company, in Europe, partnered with Panasonic. The latter’s sensors provide alerts to both the insurer and its customers using which issues are resolved quickly. Drones are here to stay and will become increasingly used for many purposes. Some of them are assessment of property damages, accurate estimation of property, analysis etc. In order to assess Hurricane Harvey’s damages and settle the claims faster, leading auto insurers used drones. In Australia, many big loss claims were settled within 90 days using drones.

Insurtech modernization

The system of records, especially the legacy systems, need to be transformed and operating costs minimized. RPA (Robotics Process Automation) and SaaS are being extensively used. Many companies buy products and customize them so much so that it loses the product flavour. This can only increase the costs of maintaining such systems. Companies are looking at  standardization as a means to cut costs.

Some of these are likely to encompass the following:

• AI and automation to cut down costs
• Focused application for digitalized customer experience and focused approach to problem-solving.
• Implementing a global Blockchain for a more secure and safe information sharing channel.

Partnerships

The collaboration between insurance and InsurTech firms will happen faster. The result will be new revenue models, higher profitability and reduced costs. If we look at the InsurTech firms’ growth, it happens in almost all the areas such as auto, cyber security, home etc. These call for increased technology capabilities which may be difficult to develop by the traditional insurers or would take a longer lead time. The latter is not acceptable in the competitive world. This could even be a win-win for both. Reaching out to large customers could become easier using InsurTech companies.

References

https://www.businessinsider.in/the-insurtech-report-how-financial-technology-firms-are-helping-and-disrupting-the-nearly-5-trillion-insuranceindustry/articleshow/60258913.cms

https://www.itnews.com.au/news/qbe-deploys-drones-to-assess-insurance-claims-452739

https://www.nationwide.com/smartride.jsp

https://www.cbinsights.com/research-insurance-tech-trends

https://riskandinsurance.com/5-tech-trends-for-insurers-to-watch-in-2019/

Dear customers, Rationalize your SLAs…

You go and ask an ISP (IT Service Provider) of any customer especially in the field of FS (Financial Services).

You: Hi, tell me about your delivery quality.

ISP: Welcome. We are at the top of the delivery excellence curve in the eco-system of my customer. All SLAs are green for the last … years. We are very proud.

You: Good. How many SLAs (Service Level Agreements) do you measure and report?

ISP: We pride ourselves in reporting more than 100 SLAs covering all aspects.

You: Wow! 100+ All your SLAs are green. Can you vouch for no degradation in the performance of your customer’s service to their end-consumers?

ISP: We can’t say that. Whatever we do, we are GREEN.

The above is not an uncommon conversation that can be experienced today. SLAs are good and needed. But what started off as a measurement mechanism is not what you see. It has become muddled, saddled with increasing number of measures and is being religiously reported. The only problem is that who consumes and what useful information is derived from it? What has happened in the last few years?

• The eco-system has more than one vendors.
• Very rarely does a complete business process start and stop with one vendor. Different vendors act on different parts of the value chain to complete a service.
• More vendors result in more hops of process flow. Each hop adds complexity to measurement, governance overhead and lead time.
• SLAs have become more operational and reflect the process capability of the ISP and have nothing to do with the business outcome of the customer. A system has an availability of 99.99%. It is possible to have one minute outage and meet the SLA. If that one minute happens to be during a critical window, business suffers. On the other hand, an outage at some other time may not impact business.
• The amount of time spent in recording data, reporting and managing can fund a fully-fledged vendor department!

What should the customer do?

1. Have a focused 1-2 week exercise. Look at your vendors and different services.
2. Understand your business capability and map the IT processes/vendors against each. Identify the critical points in the value chain.
3. Start developing SLAs to match with the “success criteria” of IT as a whole. For this, assume you are the only party in control of all IT resources/services.
4. Do not waste time in operational SLAs vouching for the process capability of the vendors. If you have selected a vendor compliant with certain process standards, it is the responsibility of the ISP to comply with it. So long as the MSA (Contract – Master Services Agreement) covers it, that should be fine. However, retain the option to ask for artefacts that couch for compliance.
5. Call for a workshop with the ISPs and set about how each one can take the SLA you have devised. It comes in many different flavours:

• Flavour #1: Every ISP can take the SLA and apply it with respect to its domain/services. For example, consider a resource ramp up time of n weeks. It applies to every ISP and can work with their portfolio.
• Flavour #2: The SLAs have to be taken by each ISP; however, the target value should change as the quantum and type of work done by each ISP vary. Consider the fact that 20% of the IT staff are considered “KEY” and there is a whole host of definition behind what is “KEY” including longevity in the account, skills, capability, offboarding procedure etc. Customer’s IT has a target of 25%. But the same % may not be relevant for an infra service provider vs high end application service provider. The values should reflect their role and volume of work.
• Flavour #3: This is the most complex. The completion of a business capability requires services from different ISPs. Here, the respective ISPs should take the entire SLA as it is and have a responsibility to work together and ensure all of them complete the task within the overall time. This will call for a high maturity discussion, understanding and a passion to work with multiple vendors in order to deliver a business outcome. Once agreed, the ISPs will ensure they work seamlessly, find ways to inform one another well in advance, have planning sessions, find ways to reduce the hop etc. If any ISP is not willing to take, you really need to re-examine the fundamental reason behind. Or it is perhaps time to re-examine the relationship with the ISP.
• Flavour #4: This is similar to the variant #3 but with a difference. The single business capability can be broken into distinct steps with each step owned by an ISP. Here,  the ISP take that part of the SLA (After breaking it down) that applies to them with a specific target value.

After agreeing on this, focus on:

• Propagation of the same across all users/stakeholders
• Laying down of the measurement and reporting system to be used and
• Developing an automated system for tracking and reporting eliminating the need for a voluminous governance around this.
• As a guideline, any set of SLAs more than 20 measures may not augur well.

Finally, a word of caution: If, as a customer, you find too often lifting the phone or dropping an email to ask for an SLA report or spend days validating the data in the SLA report or get happiness in organizing SLA meetings, you have slipped into a danger zone. 

Trends in Banking and their impact to IT service providers

As part of an IT service provider in financial services especially to banks, we are constantly reminded of  and surrounded by what’s happening in the midst of our customers. The changes are hard to miss. We ignore these trends at our own peril!

I see the following 3 key changes happening in banking that have huge impact to IT service providers.

#1. Banks are placing more importance on open banking standards and providing APIs (Application Programming Interfaces) either due to regulatory pressure or from a desire to stay relevant

#2. Banks are using data and AI in almost all services where possible to provide differentiation.

#3. Banks invest a lot in understanding and enhancing their end-customers' engagement with them. They want to make their customers' journey – as much STP (Straight Thru Processing) as possible whilstnot comrpromising on customer experience.

Where do the new customers, especially the millennials, shop for financial products? Where do they perform the analysis and comparison? The answer is in their own mobiles or hand-held devices.  In other words, a strong integrated data management that helps in analysing real-time structured or unstructured data to understand customer better and create a personalized experience is required. IT service providers who understand this and build solutions that can adapt will survive. Such an IT system should allow customers to engage in the channels of their choice at any time. The switching from one channel to another should provide a seamless experience.

Second, long winded vendor selection process (perhaps robbing of certain revenue for “Sourcing advisors”) with a view to reducing cost of the landscape is gone. This is because banks have started focusing more on enhancing experience than cost reduction. This, of course, doesn’t mean the latter is not important. It is just that it has taken a back seat to the former and has huge implications in terms of the type of skills a service provider needs to engage with the banks to develop suitable solutions. And the banks are not prepared to wait for 3 months or more in order to select a partner! Failing fast is the new norm.

The banks are willing to pick up customers at any point in their journey but want to provide a wholesome experience that lasts long and enhances the relationship. A customer may have come to avail a particular banking service, say housing loan, after using online comparison or aggregator tools. But it is in the bank’s interest to hold on to the customers by understanding their preferences and evolving a bouquet of services that are way better than what they are currently having. IT systems can no longer be built to do only one thing. Instead, they should be nimble, lean, have the ability to learn and grow very quickly and provide a means of differentiation to the organization.

Impact to IT service providers

All the above changes affect the Indian IT service providers (ISP) in many ways and in different dimensions.

• Capability: The skills, required for building or changing IT systems, are continuously changing. As a result, people who can adapt quickly are the need of the hour. How fast can a service provider deliver such skills? This has huge impact on reskilling, cross-skilling, recruitment etc. As service providers grow hugely, such changes take long time implement. They have to start exhibiting in pockets and spread them across the rest of the units. They can’t afford to wait for global roll-outs! 
• Skill mix: Major impact in the percentage of thinkers vs builders. As the IT systems of the bank move to providing more and more business value, the fundamental nature of the skills change. ISPs used to break down every piece of IT work and execute 80% or more of them at offshore. This ratio is becoming more skewed. Some of the new type of IT work demands more than 40% work be done close to the customer and falls into the "Thinking" category. As the release cycle reduces, very quick execution is required. This would place huge emphasis on collaboration tools to enhance the quality of work and provide a seamless experience to the banks.
• Location is the third aspect. As the banks expand into new markets and offer new services, there would be demands from ISPs to service them locally. For example, there is a growing market in Baltic region. Many banks are targeting customers in the region who are considered very tech-savvy. Such demands have to be met locally very close to customer. Traditional models of building capability in a monolithic way and transporting the people to the desired locations may not work. The lead time may not be advantageous to the ISPs. Many ISPs make use of centres in off-beat fancy locations. How many of them are known for certain capability other than being a low-cost location? The customers are paying increasing attention to the capability and people being developed in various delivery centres.

All the above will call for various measures, in a co-ordinated way, to be implemented by the ISPs. Guess what, implementing these will not only be simple but add to their growing costs. But the banks may not be willing to give you a long lead time nor absorb a temporary surge in their IT costs! Only those ISPs who are not afraid to experiment and who invest in understanding their customers' journey are more likely to succeed.