daily post

Tech debt is a killer, if you keep accumulating and don’t have a plan to manage it – you’ll end up having a product refactor few years later.

And this doesn’t happen in few days, it’s usually a culmination of bad practices over a period of time.

First mistake –

The problem starts with incurring tech debt in the first place. Anything that is supposed to be done as part of that story, should be in your Definition of Done (DoD)

If that discipline is not there, teams end up incurring a lot of tech debt without even realizing.

Second mistake –

Let’s assume the DoD is good and something is dropped (e.g. writing automated tests), often it’s just left saying we’ll come back to it when we have time.

Instead, a tech debt story should be created to track this and must be prioritized instead of adding to a long list of tech debt. (I’ve seen 1000+ tech debt stories..)

Finally –

Have some capacity reserved to take up tech debt every sprint.

Mostly its a struggle to prioritize tech debt. Sometimes it helps to just say 20% capacity (for example) has to be allocated to tech debt every sprint.

What else do you try to mitigate tech debt?

#RedefiningSoftwareQuality ✔ #Prioritization #SprintPlanning #TechDebt #Agile #WaysOfWorking

An alternative way to look at Automation ROI:

1. How many people are using the automation results
2. Ownership of automated tests running in the pipeline

This was shared by Melissa Tondi today at a Tech talk session organized at Emirates, I was so happy she accepted the invitation.

She shared her experience around Quality engineering in the DevOps world, and what an amazing session it was, I’ve been getting messages the whole day about the session!

Back to ROI, we usually calculate it by saying how many hours saved, which I’ve always had an issue with

I liked the idea to step away from ‘hours saved’ and focus on utility & adoption of automation.

It’s about time we stop having to prove automation is needed, and instead focus on measuring: ‘is it helping us’.

If automation is an integral part of our decision making process, and a failure there is treated like the ‘Andon cord’, then it’s working or us!

#RedefiningSoftwareQuality #TestAutomation #QualityEngineering

Are we ready to test products of the future?

With advancements in very diverse and new industries, the problem of maintaining their quality identifying risks is challenging.

Industries like Virtual Reality, AI / ML, Human enhancements, block chain are different than products we are accustomed to test.

IMHO being good in developing new heuristics to test these products and identification of risks would be very much needed.

A great link shared by Anna Royzman at the #tmatlc2020 #keynote showing how different industries are progressing (link in first comment).

Do you think we are ready to test product of the future?

#RedefiningSoftwareQuality #SoftwareQuality #testing

• Keep the camera on where possible
• Go the extra mile to give background on your message – use more words
• Communicate more often and frequent
• Try harder in building a relationship – lots of things just go away by building trust

As a leader, one of the most important things to do is help eliminate waste

That means a lot of things:
– Prioritizing what’s important to focus on first
– Building infrastructure to do mundane tasks in a more automated fashion
– Removing impediments blocking the teams

We all have fixed capacity – 24 hrs in a day, and specific hours at work

So we move faster not by adding more hours, but importantly by working on what’s important and not have to waste time

#AgileTransformation #ServantLeadership #Productivity

While designing our automation training program, initially I was focused more on getting the learning path & content perfect..

I was forgetting the operational effort to run it all, few good suggestions I got were:
– Try to avoid workshops and try to use / create online courses as much as possible
– Try to automate the quizzes checking & delivering results

Took some time to develop all of it, but now we’re able to do a good potion of things automatically and saves a lot of time.

The point I’m trying to make: Automating tasks is not a new concept and is not limited to just test automation, it applies to almost other every thing we do in our lives

As engineers, we need to always try and leverage automation for even smaller activities

Freeing up your time even a few minutes here and there frees up your time to do ‘thinking’ work and less ‘remedial chores’

#Automation #Leverage

I feel transforming team’s behavior is both an art and science.

A science since it helps to learn processes to facilitate test & learn new practices and build technical enablers

An art because transformation has a lot to do with changing human behavior

Improving quality engineering & testing practices is the same, it’s a science and an art.

You only get better with using some systematic structure & practice, also you’ll always face new challenges which you might not have come across before.

Attached slide shows a few points you might want to consider on your transformation journey. (from my talk at the #tmatlc2020 conference)

Event link in first comment

#RedefiningSoftwareQuality #QualityTransformation #AgileTransformation

Data engineering & data science have unique problems,

A big one is validating data ingested into the pipeline.

It so often happens that data being ingested is not as per expectation

There are generally 6 broad categories classifying the different problems you may have, called data quality dimensions.

To ensure he quality of your data models and analytics, its vital to validate quality of the data BEFORE any processing happens.

Reference video linked below

#RedefiningSoftwareQualiy #BigData #DataScience #DataAnalytics