alikhalid

Another year of great learnings has passed. I am thankful for having the opportunity to gain lots of new insights and experiences. Most of the year was spent on designing and supporting an IT transformation focusing to deliver at speed with quality. This initiative allowed me to be exposed to a lot of different challenges and meet wonderful people.

Stepping into 2020 I thought of writing top 3 learnings which I want to take into the next year and work more on.

Eliminate Waste

Everyone has the same amount of time in a day, then how some people / teams accomplish much more than others? There has been considerable research on the subject, I feel the common theme in most results is successful people / teams don’t waste effort.

From reading and working in scrum teams, a very core focus in agile ways of working is to focus only on ‘what’s important’. Further to decide what’s important, ask the customer who’s paying for the effort. This singular focus on what’s important, what’s needed to meet the objective is a key factor in success.

Over the holidays some family time was spent talking about achieving goals. I shared an observation that every person has the same 24 hours in a day. Also, every person while they are awake are doing something, working on something, watching something, talking or whatever, just doing ‘something’. To achieve your goals, don’t do ‘something’, do ‘THE thing’ instead of low priority items.

I often give the example of a magnet. All solids have atoms exerting force in some direction, but the net result of all force is neutral. In magnets, like other solids atoms are exerting force too, only difference is they align in one direction. Collective focus in a singular direction makes the difference.

The problem with people / teams, we don’t always have a prioritized list of activities to do to reach our objective. Without this ‘prioritized backlog’, we react instead of being proactive and end up working on what’s not important and waste time for which the users / business is not ready to pay for.

For additional reading on alignment of purpose, especially for scum teams, I’d recommend “Scrum: The Art of Doing Twice the Work in Half the Time” by Jeff Sutherland.

Leadership is being Selfless

My philosophy for leadership has always been ‘leading by example’. In my quest to learn more about transformation, leadership kept coming up. Therefore, I turned to my favorite speaker on the subject: Simon Sinek.

From primitive times, leaders of the tribe were always given first choice of food and preferential treatment, and members of the tribe didn’t have a problem with that. That’s because they were getting something in return, the leader giving sacrifices which others were not ready to do. To protect from any external dangers and look after the tribe members.

The same unwritten rules still govern the modern world, but when leaders don’t give any protection in return, or don’t look after our interests, this unwritten contract is breached, that’s we have a problem. Leadership, by definition, is an act of being selfless and keeping the interests of the tribe / community / team ahead of your own personal interests.

In the capitalist world we live in, with extreme deprivation of moral code and ethics, it’s challenging to be truly selfless in a corporate environment. I feel we should at least try to be closest to this golden standard. One cannot be a true leader unless they have interests of others ahead of their own.

Additional reading: Leaders eat last by Simon Sinek.

DevOps – A mindset & a TON of enablers

I’ve always said the Agile manifesto had the core of DevOps in there, in theory DevOps does not suggest a new paradigm shift, it provides pointers around technology and tools to really become agile. Therefore, a big part of DevOps is the cultural mindset change.

A big part of that mindset change for me were the two points mentioned earlier, eliminate waste and leadership. To produce quickly, the whole team has to be single mindedly focused on one objective only and not waste time second or third priority items. Only then we can quickly move things from ‘work in progress’ to ‘done’.

Part of waste is teams waiting around for someone to take a decision and tell them what to do. Teams need to feel empowered, so they think for themselves, take decisions and make things happen. As they progress, they’ll learn and improve as they move along. This is where leadership comes in, if leaders selflessly try to make things easier for team members to do their job, they feel more empowered and motivated to go ahead.

With DevOps, things don’t just end with transformational talk, a lot of enablers need to be put in place to achieve this. Therefore,

DevOps is sexy – but not a piece of cake

Bare minimum to do it well, you need CI pipeline(s) with all hooks in place, code repos with proper branching / merging, spinning up of on-demand environments which are fit for purpose, a TON of automation running at different stages across the pipeline, mocks / stubs, test data creation / deletion, connectivity with other products where needed. So you see, doing all this is not sexy at all.

Oh, and lastly, if you expect DevOps is going to reduce your cost, in the long run it should yes, but for a year or two you’ll be spending 2X or 3X the amount to get all these enablers in place. It reduces cost by eliminating waste, reducing manual churn, people not working on low priority items (back to cultural change)

To sum this up, I wrote a short Poem a few weeks back:

Software over the wall ; results in a great fall.

Testers, developers and all ; will then not like management’s call.

Ship in collaboration, be quick and release small ; that’s a lesson for us all.

There were a lot of other things I experienced, these were the top 3. Looking forward to continue working on these in 2020 as well.

What was your top learning from 2019?

Since the start of my career as a tester, I’ve always been obsessed with testers delivering tangible value to the business. I realized ‘redefining software quality’ was my calling. There were quite a few powerful stories that lead to this realization, and one of the most important ones I presented at the QA&TEST 2019 conference.

This was a story about testers taking responsibility and recognizing how important it is to understand the underlying technology of the product. From this event emerged the three core values I feel which can reshape how we think about software quality.

Award ceremony video here.

I thoroughly enjoyed the conference, the city and the hospitality. I talked about it in this article and a short shout out for the organizers on a job well done.

Presentation key points

Out of scope

The products being very complex, it was impossible to test everything through black box testing. Areas which the testers were unable to understand how they work, or there was no way to test them, were not considered as the tester’s responsibility.

While quality is everyone’s responsibility, but testers do need to make sure all bases are covered. It isn’t necessary that everything must be tested by a tester, but a tester should make sure that ‘someone’ is testing all the areas that should be covered.

Code coverage

Code coverage is not the only measure to check, but certainly is one of the important ones. Unless we are sure all statements and branches of the code have been executed and tested, we cannot be sure of all the hidden risks. With just black box exploratory testing, it’s almost impossible to figure out the code coverage % even is, let alone having a decent code coverage.

In our story here that was the case, almost zero visibility into the code, some functionality had been going untested. Neither was there any effort in figuring out how to improve that coverage.

Fault injection

In pursuit to improve coverage we came with a method to do fault injection / mutation testing. Instead of controlling the input parameters from outside, alter the control flow within the program to reach the desired state.

Technological excellence

Without knowing the technical details of how the product works, it’s very difficult to figure out the risk areas and to learn how to test them efficiently. A good understanding of product architecture and what areas are high risk is key.

Testers MUST put in effort to learn the technology. Without it, IMHO one cannot be a good tester.

Testing Acumen

Testing is more about thinking and collaborating than doing and checking. Learn to think how to test and learn / develop models on how to test. Unfortunately most testers intuitively learn to test well and don’t follow a systematic way to enhance that skill.

Redefining Software Quality

The most valuable learnings for me were the importance of testers to learn technology, enhanced methods to identify risk and ability to provide value in the context business.