Thursday, September 21, 2017

From Bulky, Fat …… Lean & Healthy!!!

Read the heading again, nope not an easy task… you might say - I tried so many times but doesn’t look like I am losing any fats or I will start doing something about it from tomorrow (and tomorrow never comes) or I am too busy at the moment, let this phase go and I shall start my work-out. Few of my friends even argue, you need to have fats/bit of tummy that’s when the tuxedo or blazer suites you well

I bet many of us who are reading this and are on “heavier” side of BMI (Body Mass Index) knows what I am taking about. Basically what is happening – we have started “enjoying” the “fatness”, even though we know that extra fat is not healthy as soon it will start impacting our performance and comes with a hefty cost we still carry it and come up with “innovative” excuses for not taking any action to reduce it.
Yes, there are people who does take action for few days (jogging around the blocks or joining gym) but not able to continue it consistently.

Do you see some pattern here? If we/our processes are fat, somehow we start love it having around (fat), we just convince ourselves that .. that’s okay, it is not much, or I shall work on removing/reducing the fat (wastage) tomorrow coz I am too busy now.. and over time we start even acknowledging it as great “possession”… 

Hard truth - the fact remains – Fat(wastage) invites issues, slows our speed/progress, hits us both mentally and physically and starts spoiling our environment slowly...almost unnoticeable.

So how do you start towards the “Lean” and “Healthy” journey?
To start with, you need to ignite (and keep up the flame) the thought of becoming “Lean”.


First, You need to visualize clearly in your mind – what is your goal (end value – in terms of specific weight, size etc).. what value/benefit you would bring to yourself or people around you when you are a lean-mean machine (Identify Value)

Second, identify and organize your steps, actions and things to achieve the end goal. Steps could include identifying a gym, searching a joggers track/park, buying jogging apparels/shoes, selecting energizing music track during the course (I personally prefer audio books), eating habits - what to eat what to avoid or may be a companion who always motivates you… that is list of everything that serves you as Value stream to achieve your end goal.

Third, create a habit, rhythm a flow … best way to do it to internalize the process. Coz when it comes from within, you will start enjoying it, you will not take it as burden. It should happen in a way such that you should be drawn/pull towards your “end goal”, as you are with your “Value stream” and “flow”, you will start observing that waste is slowly getting removed/ disappeared as you would start taking initiatives to eliminate the obstacles in your flow. So, who is removing those hurdles and impediments? It is you, as you've started enjoying the journey, you've started feeling light and healthy. Remember -You don’t just create the flow – maximize the flow / the grind.

Fourth, as things are in flow, you ought to motivate/empower people around you. After all whats the fun in keeping the joy and benefits to yourself when you see that people around you are still carrying the burden of bulkiness? Tell your success stories and benefit of staying lean, light, healthy and energetic. Guide/help/train people around you to take lean journey with you. Create and standardize the process, a kind of ready-reckoner for people to refer and inspire and empower people to follow the path for great results.

This last one, Fifth, circle backs to the entire process. In simple terms, how do you optimize it? Make it work better? It is Continuous improvement.
PDCA – Plan, Do, Check, Act/Adapt offers us a methodical way to solve problem and improve. It is about observing each of our steps to see what works, what doesn’t and what can be done to improve/optimize the entire life-cycle of becoming lean and taking those actions. It is about always trying to seek optimal and innovative ways stay lean all the time.

Follow this and I bet you will be a lean-mean machine soon...and if you pay attention to the "Fifth" step, you would stay lean.

What more, apply the above five steps/principles at your work and soon you will establish a “Toyota” like culture at your workplace.

Wondering can we use the metaphor above and map it to the five principle of “Lean Thinking”? (check the text in bold)

What do you think?!

PS: About me, nope I am not Lean yet, but nevertheless I am already on my way and started enjoying the journey itself :-)

Saturday, September 16, 2017

Reducing Technical Debt - My code, my responsibility

  • Let's get the core functionality implemented and tested first and in later release we can retrofit and concentrate it on quality...
  • Coding standards?! But, I always used to write in this way..
  • I have already developed 90% of the feature during the spike itself, it is just matter of promoting it to integration...
  • We discussed this during code review, but since functionality was working we just avoided to touch the code..
  • I was in hurry...
  • What difference does it make anyways?
  • This piece of code doesn't need to follow the framework, it is a "different" functionality...
Sounds familiar...? Yes, I too have come across this and may other so called "genuine" reasons when I see some features getting dragged for iterations or even PIs (Program Increments) together. Unfortunate, but true.
Now how do we address this? Simple, by educating them on basics, be it "software engineering" practice or basics of agile principles.

Here are some questions to ask ourselves or teams on how do we avoid or reduce technical debt -
  • Prevention is better than cure... yes, first step is to prevent it from happening or reduce the possibility of it happening it to maximum extent. Gather the team, architect, SMEs etc. and ask them - How to avoid creating technical debt in first place rather than dealing with it at later stage?
  • Does the team understand (and have access to - this is funny but I have to mention it explicity) application framework and coding standards?
  • Does my team understands the overall architecture of the system as well have fair idea about enterprise architecture? Is team align and following the same architecture?
  • Is there anything already developed that can be reused?
  • Is my System Architect collaborating with the team?
  • Is System Architect aligned with Enterprise architect?
  • Was the estimation done by an individual "bright" member or by the team?
  • Do I have good DOD (Definition of Done) in place?
  • Is team aware of NFRs (Non Functional Requirements)?
  • Is team working on too many user stories in parallel?
  • What are the software engineering practice that team follows?
  • Was the design reviewed by someone else as well?
  • Is my code structured and looks simple or complex to understand?
  • Am I applying any design pattern thinking?
  • Am I learning from past.. say retros, defects etc?
... and list can go on and on and on... Sometime team or the member involved can be bit in hurry or unaware or even lazy and would cut corners; but reducing technical debt is not a matter of choice, it is "responsibility" and we have to inculcate this habit in the team.

Here are some prevention-cum-cure tips:
  • Get the entire team involved - Ensure that team has awareness of system and enterprise level architect - and proposed solution is aligned to the same
  • Publish coding standards, guidelines to follow
  • Ensure that team is collaborating with architect
  • Help team identify the strategy - MBSE(Model Based System Engineering) or Set Based?
  • If it is getting overwhelming, dedicate iteration(s) to address technical debt
  • Encourage collaborative design
  • Identify and suggest best software engineering practice
  • Help team to develop a strong a clear and DOD for each delivery unit - be it user  Story, Feature or even Epic 
  • Look back, refer to retros, defects past discussion and improve. Identify the defect patterns.
  • Keep the WIP (Work In Progress) limits low.
  • Plan the code/test coverage (TDD-Test Driven Development, BDD-Behavior Driven Development) better
  • Level of automation planned and keeping the automation in sync with development
  • Effective and frequent code reviews, preferably reviews of small chunks of code rather than taking it up as a last activity once the feature is developed
  • Encouraging design pattern thinking
  • Clear understanding of NFRs (load, response time, concurrency, security etc.)
  • Simplifying the code rather than making it complex and unstructured
  • Promote pair programming and share your insights about good and bad code and promote the learning about preventing the technical debt rather than fixing it later. 
There could be many more... and I welcome readers to add them in comments.

As uncle Bob says -
“Go well, not fast. Care about your code. Take the time to do things right. In software, slow and steady wins the race; and speed kills” –Robert C. Martin , president of Object Mentor and agile methods author.

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?