Agile Methodology Industry Wisdom Test Planning & Management

Pseudo-Agile is a slow poison to Software Quality

Today most of the organizations are moving or have already moved to agile development and testing. Or at least they think so. Sprints and daily stand-ups are common. Everybody is talking about Scrum & minimum viable product. We are tracking the team velocity & burndown. We have cut down on the documentation & invested in working software. Everyone is focused on customer satisfaction by accepting change. But wait a minute! This is too-happy a picture to be true. Everything is not so agile in the real world 😉 I like to call it a Pseudo-Agile world, where everything is not so perfect. Where we ‘adjust’ the process so that it just works, often called the ‘Jugaad’. In the name of Customer agility, we adjusted the actual agile to suit our needs thus giving birth to mock-agile process which I call Pseudo-agile!

The Pseudo-Agile world

“It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.”

‘Agile’ was a revolution in Software development. Who knew Agile will eventually wipe-out the traditional waterfall model? Though some projects still follow it. Anyways it all started with a breeze and soon Agile turned into a storm such that organizations not adapting to it were looked down inferior. In order to catch-up with the trends, organizations & projects quickly transitioned to agile processes, scrum being the most common. The miss? Yeah! It needs some ‘training’ to overhaul the entire process, it’s no small talk. We missed the ‘training’ part and each organization implemented its own version of agile processes – the Pseudo-agile!

Pseudo-Agile Software Quality

By referring the manifesto and principles laid down by the Agile creators, the industry went from being old-age waterfall to trending agile. On the way we fixed the hiccups by some workarounds (or jugaad), everyone wanted to be agile after all, quickly. The result? Instead of being Agile, the organizations implemented Pseudo-agile where,

  • There is a rush to develop & test quickly, i.e. hurry to release the minimum viable product.
  • Requirements doesn’t elucidate discussions
  • Self-driving team is just a name, i.e. meetings still follow Waterfall, driven by some individuals.
  • Some projects still practice micro-management.
  • Instead of striking a balance between time-cost-quality, it got prioritized to time >> cost >> quality.
  • Not everyone follow the ‘Definition of Done’.
  • Focus shifted to quick-delivery instead of design & quality.
  • Product Owner is yet another ‘Business Analyst’
  • Development & Testing are still two opposite (& conflicting) activities.
  • Feedback loop is often just on the papers.
  • Neglecting the ROI and the right mix, Automation overtook Manual (rather exploratory) testing to reduce time-to-market.
  • The list is not complete yet. I know you will agree with the pseudo-agile world. If yes, do mention in the comments your pointers to pseudo-agile.

We did achieve requirements agility and quick delivery but at what cost? Why do think we have so many ‘Agile enthusiasts’ out there preaching the ‘correct’ agility to software organizations? We visit a doctor only when symptoms show up, but nobody likes to talk about it openly 🙂

Pseudo-agile and Software Quality

Nobody likes a buggy software. With multiple options to choose from, users today are intolerable to screwed applications. It’s not simple & easy-to-use? Scrap it. Giving errors? Uninstall it. Not enough features to be useful? Don’t buy it. Slow navigation? De-rate it over the frustration.

“We only wanted to do one thing, and do that really well.” – Jan Koum, CEO WhatsApp

When do you think testing goes really well? When the requirements are clear & time is enough. Say if I give you 10 User stories to be tested in 2-weeks’ time, with zero-defect expectation. Is it possible? Client doesn’t want to shift the timelines and Manager doesn’t want a buggy product. The result is a hurried testing to cover as much as possible. But you cannot move away even a little from the core user stories. And as the user stories advance, inter-dependency increases. With user stories the testing scope too increases. Software Testing is not a haphazard activity, it’s a systematic process to uncover the defects & deliver quality. Don’t try & rush it for the sake of Test completion. Don’t forget the real purpose – quality!

Yes we want to release the increment or the minimum viable product (MVP) but ensuring quality at the same time. Exploratory testing is still one of the effective techniques to uncover defects. But it needs time (some time at least). You can explore a software best when you are free-mind, when you are not testing the software but actually using it. In its rush & screwed processes, Pseudo-agile has time to check but no time to test. It’s just like 2-week waterfall 😛

Pseudo-Agile is a slow poison to Software Quality

Pseudo-Agile poison to Software Quality

Pseudo-agile is a dangerous practice for the Software industry. It impacts both the Software design & testing effectiveness. It’s a slow poison whose effects are not immediate. If it continues, it might be too late to rectify the repercussions.

We need to change this. We need to act. We need to set it right. In your pseudo-agile project, if you encounter inefficiencies – take a stand. Implement a feedback loop with continuous improvement. Testing needs its due share of credibility, it’s important after all. Don’t rush the releases, instead plan properly. Focus on core agile principles – ‘valuable’ software, business users’ alignment, constant pace, simplicity, discussions, self-reliant team and continuous feedback loop.

How do you manage ‘effective’ testing in your Agile project? Do let me know in the comments section below…

Note: These are my personal views and doesn’t represent any enterprise, company or an organization!

Looking for a Job Change in QA/Testing technology? Get Regular Job notifications @ WhatsApp!

Leave a Reply

Your email address will not be published. Required fields are marked *