daily post

Did you know ‘phased program’ – (waterfall SDLC) was developed by NASA

And inspecting the failed programs, this process was found to be extremely inefficient

The phased program / gated development process / waterfall model was said to be very good at trying to show an over-glorified picture of the software

The focus was on documenting rigorously and proof.

I guess that’s where the Agile manifesto said – we value working product over comprehensive documentation

Many of our teams might have moved into an ‘agile’ model, but this idea of valuing working software over documentation still has not gone away

We insist on over documenting nonsense stuff, and under-documenting where needed.

Classic example – still maintaining those long test cases, and having very less context around stories or importantly writing feature files to agree on the product’s ‘behavior’ with the team

#QsDaily #agile #testing

A guru of mine once said – You are paid exactly what you are worth – I thought he was joking

Looking back, I can say he was right, at least in the long run, here’s one reason why..

I was having a chat with fellow testers the other day talking about tester’s career progression.

The biggest mistake IMHO people make is to not learn how to solve problems..

In today’s world, all businesses are focused on solving their customer’s problems, especially in tech.

Folks hired in these tech firms primary role is to develop solutions to solve these problems.

A few people find this very taxing and unexciting, because they never trained themselves in problem solving.

If you are working in tech, regardless of your position in the org, your primary role is to develop solutions for the target market’s problems.

If you can’t handle that job, you have no place in tech, and let’s then stop talking about career progression (or griping about it).

If you are solving problems, and your organization is not treating you well, you can get a better opportunity and leave.

So, in the end, you are paid what you are worth..

I figured it out.. the first and most important KPI for software quality..

Can you guess?.
.
Time from ‘prioritizing a feature’ to the time it is ‘ready for deployment’ in production.

Now some might say testers don’t have control over the whole process, that is true but we should be working to develop that maturity

Or we might say time to market is not as important as quality of the product,

My answer would be – Quality is subjective, best to get feedback from people spending money determine quality

That does not mean we ship crappy stuff, some things are no brainier, seeing exceptions, basic functionality not working are obvious

The part which is subjective is, certain features we might feel are very helpful, or as the user expected and therefore give the product a higher quality,

In the end customer’s experience, they might see that as a hindrance in using the product and would have a different perspective of the level of quality here

So, anyone working towards developing software (including testers), the foremost measure should be: How quickly we can go from ideation to deployment.

Thoughts?

#QsDaily #testingmetrics #transformation

After years of going around in circles, I’m going to get it done.

A set of quality metrics that help improve productivity, and I need our community to pitch in..

I’ve gone through relevant content I could find, and to be honest there is just so much on this topic, both good and bad content.

The mistake I have done and see other do is, we measure things we ‘think’ will generate value, like automation coverage, but never the actual outcome we want – time to market and product quality.

Also there are some process factors which usually get skipped, which are also responsible for hitting these goals

In lieu of these, want to classify the metrics in three categories with some “SAMPLE” metrics, not an exhaustive list, just to explain the heading better.:

• Practices maturity
  • g. Scrum ceremonies and best practices in them
  • Three amigo sessions
  • Defining the complete user journey for each epic & feature
• Continuous testing
  • Automation pyramid
• Business value
  • Time taken from pull request to ready for demo
  • Trend of issues coming from support which have to be fixed

Under these three headings will be a list for each.

Thoughts?

Tech stack, money, growth or company culture, what is most important when accepting a new position?

From this list I’d say tech stack and company culture.

Technology stack is an important factor. Working on a platform which has demand in the industry certainly is more lucrative.

Company culture – Learning better ways of working is often not given due importance.

Being exposed to better ways of working where taking an idea from concept to implementation in the shortest possible time is vital. This is the core of a DevOps culture.

Money and growth are by products IMHO,

As one matures technically and learns efficient ways of working, money and growth should follow.

To transform your organization you need leaders.

And leaders are those who expect higher standards, from themselves (and others)!

The key in any transformation is to change behavior.

That requires leaders leading by example and demonstrating change.,

Then can the rest of the organization be expected to change.

Therefore leaders should put themselves to a much higher standard than others.

#QsDaily #transformation #agiletransformation #leadership101

What are daily stand ups for? giving status..

Actually, that’s not the main purpose.

The main purpose is to actively remove any impediments the team is facing.

Secondly, for the team to actively work towards a single goal, the sprint’s goal.

A stand up ran done correctly, helps in aligning purpose and gives a boost of optimism.

In Jeff Sutherland’s point of view, it’s a ceremony to create harmony between the team, what he calls ‘transcendence’

The three activities to discuss therefore are:

1. What did you yesterday “to help the team finish the sprint”
2. What will you do today “to help the team finish the sprint”
3. Any obstacles in the “teams” way

Keep stand ups inspiring, people walking out should feel ‘hell yeah, let’s do this’..

Reference “Scrum” by Jeff Sutherland

#QsDaily #scrum #motivation #agiletransformation

Do super star individuals deliver greater results or super teams?

While we all might instinctively feel the team would do better but…

Super start individuals can sometimes deliver up to 10x results

That’s why companies tend recognize individual performers more.

However, super teams outperform other teams by 100x!

The ‘economies of scale’ come from alignment of purpose and empowerment

Now how do these 100x results come about? When scrum teams have:

1. Autonomy. All the skills and needed resources reside within the team and they have no dependencies outside
2. Transcendence. Alignment of purpose, everyone thinks and dreams of the exact same goals.

Reference: Scrum (By Jeff Sutherland)

The 900 miles journey in one night – just to meet and learn in person, that’s passion.

This was when Vignesh came over to meet in in NYC few weeks ago (details in post linked in comments)

Hard work and passion are a must if you want to advance your career

When I see people who don’t want to put the hours and want success, that’s like trying to learn swimming without getting into the water

I’ve also learned that’s not the only success criteria, you also have to be smart about what you are working towards and keep evolving your direction.

But by no measure does smart work mean you don’t put in the hours. There is no success without the grind.

If you are a tester and you haven’t been upgrading yourself, I wouldn’t lie your up for a tough time.

And it’s not just testers, the entire global economy is changing, t’s going to affect everyone, some a bit harder.

So instead of blaming developers and rest of the world, lets buckle up and get to learning.

More on that in the post below:

I’m uncertain as to why sometimes it’s so hard to explain the importance of ‘test leadership’.

People can have a lead architect, a lead product owner, a lead developer and even a ‘lead of leads’, but having a test lead would somehow kill autonomy…

The argument is in agile world the team does the job, so they should be self-reliant, and no one needed to ‘manage’ them.

What they fail to understand is testing with technical competence is not something abundantly available in the industry.

Most companies have to manage with the few senior resources they’ve got and use them to train rest of the teams.

IMHO the root cause is this deep-rooted ignorance that testing is just a matter of doing some ‘monkey testing’ and that’s about it.

I’d argue testing and specifically automation take as much resources as developing the service, whoever plays that role requires critical thinking, strong technical skill and exposure.

One would assume after decades of blunders and evolution we would have realized why strong testing is important, no wonder restating your PC when software is not working seems to be ‘perfectly normal’.