Saturday, July 29, 2017

Traits required for a successful Scrum Master

I am sure many of us would agree that getting certified as "Scrum Master" is not that difficult task. 
However, looking at the roles and responsibilities that Scrum Master needs to carry in a typical Agile setup, I must say  wearing Scrum Master's "hat" is something that requires some unique skills and traits.

Following are some personal traits that I think every Scrum Master should possess...

  • Collaborative
    • Must posses excellent collaboration skills to work with all the stakeholders to work towards the objective.
    • Brings together the team and helps in streamlining the process

  • Transparent
    • Always showcase transparency in all form of communications
    • No hidden agenda – what you see is what you get

  • Protective
    • Must guard team from outside influence that would divert team from the objective
    • Scrum Master should posses acute sensitivity towards both team protection and business needs and should maintain healthy balance

  • Knowledgeable
    • Scrum Master must be very knowledgeable about Agile processes
    • Must understand the technical and business issue team needs to address. 
    • ScrumMaster need not be tech-savvy or business domain expert, however working knowledge in these areas would be very helpful

  • Questioning
    • Scrum Master uses his technical, business and process skills to ask logical questions.
    • Asking questions in a way that would help team find their own answers.

  • A good listener / Patient
    • ScrumMaster is a good listener and welcome thoughts and suggestions from all.
    • ScrumMaster doesn’t gives out solutions to a problem, rather patiently hears and help team to arrive at solutions by their own.

Saturday, July 1, 2017

SAFe 4.5: Continuous Delivery Pipeline

Exploring SAFe 4.5 further....

While this is not a new topic to discuss, I feel Dean and his team placed the "Continuous Delivery Pipeline" in the SAFe Big picture with some purpose.

I see that governance of  "Continuous Delivery Pipeline" is 
still behind the scene in form of "Release Management & deployment strategy" (which is hidden in SAFe 4.5), details and philosophy behind maintaining a Continues Delivery Pipeline is explained quite well in SAFe 4.5.

Many organizations have been doing CICD (Continuous Integration, Continuous Deployment) for quite sometime now, this seems to be an attempt to illustrate it better and press upon the importance of adapting this as integral part of SAFe delivery.

If you see, "Continuous Delivery Pipleline" picture has been placed very cleverly. So if you are just looking at the Big picture, you might think that this is just another representation of CICD, but it goes way beyond that..

As ScaledAgileFramework defines it -  Continuous Delivery Pipeline represents the ability to deliver new functionality to end user far more frequently than current processes are able to.

Take a look at the elements of Continuous Delivery Pipeline below -
  • Continuous Exploration
  • Continuous Integration
  • Continuous Deployment and
  • Release on Demand
Giving it a Lean startup cycle start, Portfolio feeds the Pipeline with Epics those undergoes Hypothesis-Build-Measure-Learn cycle before they can make it at Program level in sort of "Pre-evaluated" Epics or Features. In this Lean Startup cycle, an approved Lean Business case and hypothesis is taken further to build a MVP which is evaluated and preserved as a part of inputs to the Epics or in form of additional features.
This cycle helps business in deciding where to invest and which Epic to invest, which circle backs to Lean Budgets.
  • Continuous Exploration helps further in taking up these approved Epics/Features and explore it further at Program and Team level in collaboration with System Architects/Eng, Customer, Business Owners, Stakeholders and Agile teams keeping Product Vision and Roadmap in mind. This stage collaborates, performs research and synthesis the backlog, roadmap and even vision (if required) based on their findings. 
  • Continuous Integration is about developing, testing, integrating and validating the features and keeping it "Production ready". In large solutions, integration happens at 3 levels, namely at Story level, at System level and then at Solution level. It is important for team to integrate their work frequently using automation (frequent check-in, automated build and deploy and running validation using automated tests). Once validated at Story level, these user stories should be further integrated at "system-level" by System team to ensure that nothing breaks and system is evolving as anticipated. This system level integration can be show-cased in System Demos to indicate how ART is progressing. If teams are working on very large solution that involves multiple vendors and suppliers, another level of integration - Solution integration would be required that would bring together the tasks performed by several teams and integrated as a Solution that can be show-cased during overall Solution Demo. 
  • Continuous Deployment talks about delivering the solution to end users as frequently as possible. Having an ability to have features ready in preferably small batches ready to deployment and release is the key here that would help the customer in leading in their domain with the shortest sustainable lead time. Continuous deployment ability doesn't come easy and requires team to follow the practices religiously - Maintaining dev and test environment matching production, staging matching production, deploying to staging every iteration, automated testing & deployment and decoupling deployment from release.
  • Release on demand is the last stage in the cycle that actually "releases" the feature/ solution to customer/end user based on right time and/or market demand. The once visible "Release Management" icon (in SAFe 4.0) appears here (still invisibly) in form of Release governance. SAFe 4.5 articulates various release strategies based on various situations, namely - Release on PI Cadence: that is, releasing towards the end of each PI; Releasing less frequently: releasing when it is feasible, i.e. based on availability of solution and required hardware/software resources etc.; Releasing more frequently: Releasing as frequently as possible leveraging on DevOps capability; and Release on demand: based on market demand, compliance requirement, complex solutions etc. 
So what are the key takeaways or bare minimum things (sort of "essentials") so that we can leverage on Continuous Delivery Pipeline? 
I would say -
  • Collaboration for exploration
  • Automated testing and automated frequent and Continuous integration at Story, System and Solution level
  • Dev, test, integration and staging environment closest to production for better integration
  • Release governance to support various release strategies with a strong DevOps

Benefits of having a Continuous Delivery Pipeline is enormous but not many organizations have realized this. They are still debating on the basic stuff like - 
Is automation really necessary? Why do I invest in infrastructure... can’t you work on existing one? Infrastructure is costly and takes ages to procure and configure? Why do I need DevOps?

Answer is simple – automation is not separate, it is integral part of agile delivery; procuring infrastructure now a days is fast, easy and comparatively less expensive – try cloud; having environments in sync is necessary to minimize the integration issues and DevOps… don’t you love to have the control and increased capability of release on demand to stay ahead as market leader?! Choice is yours.

Wednesday, June 21, 2017

SAFe 4.5

SAFe 4.5 is out! Checkout the new look at:
Quick visible differences -
  • Program Portfolio Mgmt is now Lean Portfolio Mgmt
  • Lean budget makes an interesting read!
  • Could not find VSE, found STE instead, stands for Solution Train Engineer
  • Solution Train.. earlier we use to just call it as ART at Value stream
  • Continuous delivery Pipeline at Program level with Continuous Exploration, Integration and Deployment
  • Special place for SPC... makes "base" for the framework along with implementation roadmap
  • Palette is vertical... yes this makes sense
  • System Team is on palette but DevOps at Program level

Do you see any other differences?
Now that SAFe is configurable, enterprises will have less "guilt" in answering the question if they are following SAFe "fully" or "partially" as they have more options now (Full, Large solution, Portfolio and Essential)

Tuesday, June 20, 2017

Fixed Price Agile projects

Now a days, I hear that more and more Agile projects are being offered at fixed price, which client is considering a sort of "Stop-loss" option for them. 
Reason could be anywhere from - technology partners are not able to deliver value on time .... to "stringent" budget constraints.

Here are my thoughts on Fixed Price Agile projects – 

• As a technology partner might not directly go for fixed price, instead observe the rate at which you are delivering value and velocity for 2-3 PIs and consider the “normalized” velocity at which you are delivering value for the fixed pricing. So it is T&M to start with and later switching to FP.

• Another option is fixed price per PI. Technology partner would provide the team(s) say 3-5 teams, with optimal pyramid and that team (fixed team) will continue working in PI over PI to deliver the value. From customer point of view, the price will be fixed (for a team), however customer can reap the benefit over time as the team become more mature and starts increasing their velocity and deliver value. Here time is fixed (per PI), Price is fixed (onsite/offshore blended rate) however scope is what customer defines. This option would work great for customers who is looking for long term tie-ups with a technology partner. (it won’t work in short terms for obvious reasons)

Have a combination of both fixed and variable price. Clearly define what all services will be offered as FP. E.g. Quality, governance etc. and things that would be offered as T&M.

Assume a minimum velocity based on your historical data – have a cap on fixed price and then if the technology partner achieve more PI over PI, the technology partner gets incentives or if performance is lower than the minimum it is penalty for the technology partner. For this to happen both the side needs to be mature enough to understand the factors that affects the high/low performance. 

Have a higher level price limit as well as lower limit – E.g tell the clients the clients that you (as a technology partner) cannot come down lower than this price per team pyramid and at times the cost might serge up to specific high limit because of certain situations/reasons (say more resources, adding few architect/ SME/ specialist to the team to resolve certain issues etc)

You can also offer fixed price and fixed scope bid, but then it just takes away the gist of being Agile. Agility can be restored by allowing them to come-up with the change request that are based on T&M. So, upto certain level say 10-20% scope variation is allowed (this needs to be really worked out carefully) and beyond that say any scope change over 20% it should be T&M. Many things to consider here.. e.g. how to manage change request, can I spin—off a new work order by bundling n number of change requests. How am I delivering, How my delivery is being measured and I do I report my progress. Ownership of risks/impediments etc.

Fixed price based on the features category – Critical Value features / Arch features / High Value feature / Moderate features / trivial changes / GUI changes.
For this to work well, technology partner must have very good understanding of the systems they are about to work and there should be clear roadmap (2-3 PIs ahead) of what a portfolio/ART is trying to achieve over time. However as all of us knows that requirements changes quite often, so we should have outline of the requirement and assume the variability(may be limit it to +-15% to 20%) and inherent risks. I would says this would be little uncomfortable contract to have.

Your thoughts and comments are welcome!

Thursday, March 19, 2015

Insurance Law: Reinsurance companies can now open branches in India

Reinsurance companies such as Munich Re and Swiss Re can open branches in India after the Rajya Sabha on Thursday passed the Insurance Laws (Amendment) Bill, 2015.

Entry of reinsurance companies into the Indian market will bring in knowledge and expertise together with underwriting capacities. Large reinsurance companies are present in India, but most of them, including Munich Re, Swiss Re and Hannover Re, operate as service companies in India. Some like Scor Re operate through representative offices.

The Insurance Regulatory and Development Authority currently does not regulate these reinsurers. The new policy does not specify capital requirement for these companies to open branches in the country; the only prescription is that parent reinsurance companies should have net worth of Rs 5,000 crore.

After the amendment, the Irda will formulate norms to regulate companies that open branches in the country. India already allows up to 26% foreign investment in reinsurance companies, but none of the global majors set up a joint venture in the country. 

Read on: Insurance Law: Reinsurance companies can now open branches in India

CEB TowerGroup Analyst recognizes Accenture's Life Insurance Platform

CEB TowerGroup has named ALIP (Accenture Life Insurance Product) as leader based on 22 attributes that defines best in class system. ALIP was named as leader in CEB TowerGroup's Analyst report titled - "Life and Annuity Policy Administration System: Technology Analysis1" in three out of four categories - Policy Lifecycle, Operational Support and User Experience.

Read on: Accenture Recognized by Independent Research Group for its Leading Life Insurance Software Solution 

Citizens Property Insurance chooses Guidewire Products

With Citizen Property Insurance opts for Guidewire Products, Guidewire continues to expand its footprints in Insurance market. Citizen has deployed Guidewire InsuranceSuite™ as its underwriting, policy administration, billing, and claims management platform. 

Read on: Citizens Property Insurance Deploys Guidewire Products to Help Transform its Business

Google entering(ed) Insurance market

Well this is approx 10 days old news, but I thought it is still worth sharing...
Google is fronting sales of Auto insurance policies in as many as 26 states in United States. As many as 14 insurance companies have collaborated with Google to boost their sales.

Read on: Google Enters the Insurance Market: Friend or Foe?

Tuesday, February 10, 2015

Choosing a Health insurance plan ? Consider these 10 points.

Choosing right Health Insurance plan that is catering to your needs is very important rather than going with the Health Insurance that your neighbor or friend suggest.

Consider these 10 points before you zero down to a Health Insurance Plan: 

10 Tips for Getting the Most Out of Your Plan

1. Be ready to put in the time. According to Joe Keenan, a cancer survivor, looking for the right insurance plan on the exchanges can be a “six-to-nine job.” He says, “You have to actually block off the time and plan for multiple sessions of really digging in to what the offerings are.”

2. Have a pen and paper ready. Comparing health insurance policies can be a non-linear process. It is often helpful to spread all of the information out in front of you so you can see everything and make notes.

3. Attend informational sessions both in-person and online. Briefings and webinars are often offered through resources like support groups, non-profit organizations, and your chamber of commerce. There are also a number of local organizations that can answer your questions and help you pick a plan and enroll.

4. Do your homework and ask the right questions. There are a number of financial resources that can help you get started, including the Cancer Insurance Checklist and other national organizations.

5. Make sure your current providers are “in network.” This means that your doctor, oncologist, and other specialists, as well as your hospital, are on the insurance plan’s approved list. If they aren’t, you will need to find new providers who are or be willing to pay costs associated with going “out-of-network.” provides a list of tools that can help you search and compare providers, hospitals, and other health care facilities to help you make these decisions.

6. Compare all aspects of the plan, not just the premium. Premiums are the amount you pay each month for your insurance coverage, whether you use any medical services or not. However, there are a number of other costs that are important to look at before enrolling. 

    Deductible—the amount of money you must pay each year before the health care plan begins paying any costs
    Coinsurance—the percentage of health care costs you have to pay after you have reached your deductible
    Copays—set fees you are required to pay each time care is received, such as a doctor’s visit or trip to the emergency room
    Out-of-pocket maximums—the maximum amount you would ever have to pay from your personal financial resources during the year

In general, the lower your monthly premium, the higher your out-of-pocket costs will be when you need care.

It’s also important for people with cancer to consider things like:

    What medicines are covered? For example, are both IV and oral chemotherapy covered? At what cost?
    Are home care and therapy services included?
    Are follow-up procedures included, such as colonoscopies?
    What treatments related to your cancer care are covered, such as integrative medicine or fertility preservation?

7. Ask a trusted friend or family member for help. This could mean having someone else make phone calls or just having someone there to help you talk through and make sense of your options.

8. Establish a relationship with an insurance broker or a navigator. These professionals have the knowledge to tell you which plans will offer you the best return on your investment and help you narrow down your options.

9. Talk with a customer service representative from The Marketplace Call Center is available 24/7 to answer your questions and help you start or finish an application, compare plans, or enroll.

10. Review your plan every year to make sure it is still working for you. As your health changes, your insurance plan may need to as well. Also, costs change and new plans are added to the exchanges each year. 

Read on: 10 Helpful Hints for Choosing a Health Insurance Plan

Anthem Health Insurance Hacked!!

When I read this article, first thing that came to my mind was Cyber Insurance and I was wondering if any of the Anthem Insurance affiliates is providing Cyber Insurance to other business ?! Or did Anthem take Cyber Insurance from any other player ? 
Being very niche area it requires lot of expertise and experience to provide Cyber Insurance. IT companies those are pioneer in Security area and showcase their expertise on how they could have prevented this from happening (big opportunity for them)!
Security breach at Anthem is a massive one and involves hacking of Social Security numbers, names, birthdays, medical IDs, and some of the sensitive personal information.

Here is an article on what Customers need to know and what they can do to minimize the damage.

Read on: Anthem Health Insurance Was Hacked. Here’s What Customers Need to Know