alikhalid

About Ali Khalid

This author has not yet filled in any details.
So far Ali Khalid has created 262 blog entries.

Developing software an art

By | May 9th, 2019|daily post|

While redefining the QA function at work, I keep coming back to this question:

What is Software Quality?

If we deliver exactly what the requirements / user story says, is that quality?

We’d say that’s validation, so we must also do verification which is ‘are we building the right thing’,

The problem there is, in a large organization a bunch of ‘groups’ have to sign off.

Now the ‘end users’ (if you will) don’t align to a single version of what’s expected.

That’s why I sometimes feel developing software is not a science, it’s an art.

It’s an art to bring a vision of a select group of people to life.

The details of the vision for all might be different, but they all might be connected with a common emotion.

Therefore, in the end, it’s about answering to that shared ‘emotion’ of the stakeholders.

SAFe DevOps Health Radar

By | May 6th, 2019|daily post|

Going through the SAFe DevOps course I realized there were a few good points.Going through the SAFe DevOps course I realized there were a few good points.

Again I don’t believe in following any Agile framework to the book and take them as just guidelines, but the SAFe DevOps section does help to put things in perspective.

The image [1] attached is called the ‘DevOps Health Radar’ depicting the different stages of how an enterprise can deliver value to customers from:

1. ‘exploring’ an idea, to

2. Development, testing at speed through continuous integration, to

3. Deploying to a subset of users through ‘dark launches’ and ‘canary releases’, with sanity tests in prod,

4. To finally ‘releasing’ to all the customers on demand and validating the assumptions business had in the exploration phase

Reference:https://lnkd.in/fcZB5sB

[1] : Rights SAFe (Scaled Agile), Illustration graphics by Quality Spectrum

Dark Launches / Canary Releases

By | May 2nd, 2019|daily post|

The new UAT: Dark Launches and Canary releases

Here’s what they mean and the difference:

Before that, UAT (User Acceptance Testing) is where once the software is shipped from IT, business / end users have a look and run their own tests to see if the product is as per expectations.

Now that was inefficient and UAT sometimes takes a lot of time, which can skyrocket time to market.

How the industry is solving it?

productionize the software, but to a user’s subset

Launch to a certain few clients / users of a certain market segment. The Idea is to get ‘real’ users actually use the product.

This way feedback from customers is quicker and as real as it can be.

The catch:

To do dark launches or canary releases, besides the obvious of having scalable infrastructure,

You need to be able to roll back and fix forward real quick, for which you need CI/CD in place.

Because there is always a higher chance of something being missed, so we must be able to fix it real quick.

QA Role at Enterprise level

By | April 22nd, 2019|daily post|

If you were to describe what QA’s role would be at an Enterprise level, what would you say?

Here’s my thought so far:

Fundamental goal: Validate goals set by business for the end product are achieved and highlight any risks to decision makers. This can be done by:

– Help POs, PMs and business in making sure the articulated user stories fit the purpose (question requirements)

– Ensure testability within the system architecture

– Foster a ‘quality first’ culture / build ‘testing acumen’ by promoting and teaching the test mindset within the whole IT organization

– Test the holistic system from end to end’s functionality, usability and non-functional requirements (performance / security)

– Ensure tests among different integrated systems and low level components are done

– Enable CI/CD pipelines to significantly reduce time to market

What else would you add?

#QsDaily #Enterprise #Testing #TestingAcumen

Mindset change to go Agile

By | April 19th, 2019|daily post|

Universal truths to ‘internalize’ to really go agile:
1 – We cannot estimate effort
Without accepting this, we try to ‘accurately estimate’ the amount of work and run into the same trap

2 – We don’t clearly know the requirements
Again, instead of focusing on getting the product out in the hands of the customer ASAP, we sometimes try to ‘refine’ the product

Off course this is easier said than done. To significantly reduce time to market a lot of enablers would be needed.

However, without the mind set change, all the tools in the world wouldn’t bring about the desired results.

#QsDaily #Agile #estimation #requirements

Testable architecture

By | April 18th, 2019|daily post|

When to ensure testability for your product?

While designing the architecture..

While mkst of us know this, very few actually see it through.

We build a piece of software and then decide how to test it,

Instead while designing it make sure you have ‘test probes’ in there.

When I worked for safety critical applications, we left test points on the PCB to check the circuit

Those points were not used for any feature of the product, but were there just to help test it.

So, testers get involved when the architecture is being designed,

Or the architects trained to ensure the system is testable themselves.

Testing monolith vs micro-service?

By | April 2nd, 2019|daily post|

What is the difference between testing micro service and monolithic applications?

First off, the definitions:

Micro-services: Software is developed as several small ‘services’ which can operate autonomously

Monolith application: One giant software with all services within the same software package

The fundamental difference for testing these is scalability and integration.

Micro-services are designed to scale up and down as users of the service increase, so testing this scaling up and down is important.

Secondly the integration tests become more important. Communication between these services is different from a monolith and should be accounted for.

While there will be many more subtle differences in testing these depending on your context, these two areas would always be of importance.Anything else you would add to the list?

DevOps and Culture

By | February 10th, 2019|daily post|

While DevOps is thought to be synonymous with tools and automation,

Actually, IMO, it has to do more with cultural transformation..

The ultimate goal of DevOps is to bring what we develop faster and more useful to our customers

While automation is certainly a big part, even more important is the culture.

The tools just fast track the thought process we have,

It’s the experimentation with different ‘thought processes’ which is the secret

I always quote “Companies to take ideas to in the hands of consumers the quickest will win”,

Because they can experiment easily, and don’t have to fear a failed experimentation.

Now if the culture is not there, experimentation will not happen.

Then all DevOps will do is to facilitate in getting more “crap” out of the production line, but just “quicker”…

 

#DevOps with #CulturalTransformation = Measurable business value

#DevOps WITHOUT #DevOpsCulture = Same old crap, just delivered quickly

The art of Resigning

By | January 25th, 2019|Management|

When I switched jobs recently, it was a very surreal experience. The stakes were high and there was a lot of ‘be careful’ advise. Luckily I trusted my gut and my values, which made it such a great experience.

Here’s how the story unfolds and some important lessons I would like to pass on to you.

Contact

It was another day at the office, I was working late trying to get some kinks out of a new test harness we were creating. I get a call from a company asking if I would be interested to explore a new position. I almost refused since I was not interested in a new job, but loved the caller’s demeanor and reluctantly agreed to ‘scope out’ the offer. Things started to work out and during the process, I felt this might work.

The tough decision

I worked in a matrix reporting hierarchy with multiple stakeholders. Over the years we managed to build great trust among ourselves. I knew if I’d leave abruptly that could harm the future goals for my team and lose momentum in the progress we were having. Plus I would have less time to ‘pass on’ the wisdom acquired. Also the timing of all this was very unfortunate. It coincided with some changes in the organization and how we operated and I could sense expectations from me and our team.

Against the advice I was getting from some, I decided to inform my current employer about the new position under discussion. At the time, no offer had been placed it was very uncertain what the offer would be. I ended up telling my manager, and some senior managers about the position. I made it very clear that no formal offer had yet been placed, but this is the blueprint of what’s going on.

I have to be honest, after the fact I felt this might have been a big mistake. But then I was able to reconcile what I did thinking I did what I thought was right, to preserve the relationship we had. And no matter what happens next, I’m glad I took a leap of faith for the good.

Empathy

The biggest weapon you can have is empathy. It’s easier to feel empathy towards an individual near to us, but to a ‘company’, no way. Most people hate corporations and I would not blame them. But think about a company like this: a bunch of people like you and me who have to operate under certain restrictions. When I say be empathetic towards the company, does not mean the ‘LLC’ entity incorporated with the SEC, it’s the ‘people’ you have worked with.

I always say: The most important thing you will take away from your job is what you learned and the relationships you built

It’s hard to be ‘nice’ to a capitalistic face, who we feel will strike us down in the first opportunity they get. I don’t want to justify how most corporations run these days, but I do want to distinguish between ‘the company’ and the folks like us who work there. If you can’t come to terms with ‘the company’, think of the people you have spent so much time with. Make it easy and a pleasant experience for them. If you are moving on, it does not mean your relationship has to end with them too.

Hand over

After informing management about the potential offer, I also started to delegate and train my team on the few missing pieces that I had been handling. Again at this time no formal offer was given, or any formal transition had started. The training was not just for my employer, it was for my team. We had shared tough times together, I wanted to leave them knowing they would be alright and would be well equipped before I leave.

After some time finally the offer was signed off on. By that time it had been almost 2 months since I had mentioned the position to management, which gave them enough time to plan. Also gave me enough time to cover bulk of what I wanted to train my team on. With the news the formal hand over process started in which we did a lot of documentation, created videos and even some last minute features that had to be done in the test harness.

The goodbye email

Most people send a generic goodbye email on the last day with some general lines saying I had a good time. For me this was different. It wasn’t an abstract set of names I had known without any human emotion. These were people I had cared about, and would continue to care about since I knew these were good people and who cared about me in return.

The most precious commodity we all have is time, and our subconscious knows that. Whenever we see a genuine effort by someone in sharing their time with us, we recognize that and respond differently.

So instead of a generic email, I met each person separately and went through what I had learned and admired about them. For those I could not meet but we’re close to me, I created individual videos for them and sent those in emails. For some I wrote individual emails thanking them and extending them my support. What followed was something I was not expecting..

What goes around comes around

I was not expecting much of a reaction, but to my surprise I got many times more love from everyone. I might have never felt such an emotional experience before as I did in those few weeks. The belief I had to spread knowledge, love and good revealed itself so beautifully. There were so many farewells, emails, calls, follow ups, kind words and just unreal responses from my co-workers, managers and senior managers which I will always cherish.

After all was said and done, the tough decision I took did not look like much of a tough decision at all. It felt like it was ‘exactly’ the right thing to do.

What if it all went south?

What if it didn’t work out. My employer would have felt I am actively looking for new positions while I had no real desire or intention of switching? That’s where trust comes in. They way they trusted me, and I trusted them back, I’m sure things would have worked out just fine. They understood I did this because I care. Unless someone is a really twisted freak, they would want to reciprocate with the same care.

We constantly undermine the good in others. Our first impulse to every new thought is mostly of fear, scarcity and negativity. Learning to trust people can be the greatest asset you can have.

All boils down to trust

We humans take this trust thing very seriously, It’s in our genetics. I have to admit you don’t succeed at building it every time, but most of the time it works out just fine.

But how to build trust? There are no shortcuts, you cannot fool people all the time. Building trust needs hard work and genuinely being ‘empathetic’. You care for others, they care back for you. It’s just that simple. You just have to take the leap of faith. Trust in each other, trust the good in others and around you. There is a lot more good than bad. We all are just more interested in the bad than the good, hence we create and attract the bad.

Did I just get lucky?

It can be argued I just got lucky. I happened to ‘charm’ my way into a few good books, not everyone is that lucky, and this might not go so well again.

I knew this would work because this was not my first rodeo. I had done this experiment many times before, sometimes intentionally and many times unintentionally. I cannot say it has always worked, but it has always been worth it. Even when it failed, there were a lot of things I salvaged and helped me become who I am.

If you did something good and it fires back, remember, you did what you did because of what you believe in. What the other person does is with them. If you spread good, you WILL eventually attract good in return. Just have faith, miracles happen all the time.

Intro to Pace Layered Application Strategy

By | January 19th, 2019|Product Management|

Just like products across different industries are not the same, similarly software products are not the same either. While I used to understand that difference, but perhaps did not appreciate how different they can be and how they should be classified and treated differently.

Recently I came across Gartner’s PACE layered application strategy giving a new perspective which can be very helpful for managing multiple products or programs.

Premise of the strategy

It was realised that certain applications don’t change a lot and need to be more cost effective and stable than efficient, while others had to be delivered very quickly and change frequently. Both require different processes and should focus on different goals. A mobile app compared to a mainframe application are not the same. Clearly both serve very different markets and have unique requirements, hence no single strategy can be used for both.

In 2010 Gartner introduced a concept where different applications in an organization can be delivered at a different ‘pace’, meaning some would have shorter release cycles and are more flexible, while other applications would be slower and more robust in delivery.

Understanding which applications need rapid delivery and change and where this is not a requirement is important. Also applications under these categories should not be organized around each other since the required results are different.

Pace Layers

From rapid deployment and flexibility to slow releases and stabile products, there are three layers defined with unique characteristics providing the needed support to one another.

Systems of Records

Established applications which might be legacy or core systems supporting or managing critical master data would come under this heading. Changes are less frequent and slow, can be due to well-established processes or regulatory requirements. These applications would have the longest time span, around 10 years.

For these large and very formally designed applications the processes might tend to be more water-fall or incremental development like. Funding would come from capital investments with annual budgeting, since the changes are important, few and less frequent.

System of Differentiation

Applications that support the organization’s unique processes or capabilities which differentiate it from rest of the market. While these applications have a medium life cycle, the change required is frequent to calibrate according to changing business environment.

These applications might embody more modern design practices like SOA or cloud based, perhaps composite with old custom applications. Processes here might again fall more under Incremental development and somewhat waterfall with some agile and lean principles incorporated. Budgets might be a mix of capital and operational expenses since iterations are relatively faster and more frequent.

System of Innovation

Developing new ideas and quickly validating those proof of concepts requires very different processes. These applications, revolving around ‘new innovations’ come under system of innovations, characterized by very short life spans and flexible / ad hoc processes.

Agile and lean practices would be more applicable here with latest technology stacks and architecture trends for these lightweight applications mostly serving end consumers. Budgets would come from innovation funds or departmental budgets, since these are supposed to be very frequent releases and in some cases throw away features.

After we have established the products falling under all three categories are different in the required culture, development methods and skills between them; the question is how do we organize these systems and build some coherence and synergies to manage them in a holistic fashion?

Pace layers are focused on business processes, not any particular business organizational model. So there can be many ways in which the organization can be setup, Gartner suggests to use the Hub and Spoke’ model

Hub and Spoke model

Hub-and-spoke model is common in a lot of other industries like transportation. Essentially the ‘hub’ holds a central position serving ‘spokes’ originating from a hub.

Let’s take an airline’s example wanting to support 10 destinations, with a hub and spoke model you need only n-1 = 9 routes to serve all 10 destinations. In contrast, a point-to-point system would need 10 * 9 = 90 routes!

What would this mean for managing software teams? The central team (hub) would focus on common applications that might be shared among different business groups. Applications having common governance, planning and management functions would be ideal. From the pace layered architecture, the ‘system of records’ would comprise of the hub.

The idea is to preserve coherence between layers, at the same time provide enough distance for the different record structures to work in their own cultures and operate independently.

The Hub

Applications typically having a predictable pace of change, where cost optimization or efficiency is more focused on instead of quicker and costlier solutions. Therefore the changes are predictable and long-term.

The hub does not govern any of the spokes in any way, rather it acts as a supporting function, a common platform which the spokes can use. The layers since should operate with very different goals, cannot report into one another rather would have separate reporting lines.

Systems of Innovation and Differentiation

The applications would be fundamentally different focusing more on flexibility and speed instead of predictability and control.

Differentiation layer applications, in many cases, might be a part of a larger system of records and therefore would require integrity between these two layers to work correctly as a whole.

Innovations are more around future concepts and developing POCs, therefore they can be an entirely separate group within the organization or even with a team outside the IT setup. The key here would be to deliver at pace and closeness to business for catching on changing / new ideas.

 

Conclusion

A common mistake large organizations have is to use a single silver bullet process institutionalized across all products. Understanding not all software applications have the same business objectives, in turn meaning one process cannot be the best fit for all. Speed and predictability are two main differentials which fundamentally change how processes should be designed for these products and achieve the varying goals for these products.

Products across the Pace layered applications architecture will have very different cultures and operating models and should therefore have independent reporting lines to the business. However, some synergies will exist, by the hub exposing some common platforms which can be consumed by differentiation and innovation products.

While Pace does not deal with what ‘kind’ of development process to follow, it provides a very good framework for program management looking after multiple product groups. This in turn allows development process diversity across products to use what is the best fit process for achieving the product’s business goals instead of imposing a single ‘best practice’ on all.

References

https://www.gartner.com/doc/3872164/governance-change-management-pacelayered-application

https://www.gartner.com/doc/1635516/gartners-pacelayered-application-strategy-governance

https://cio-wiki.org/?page=gartners-pace-layered-application-strategy