This blog post is all about the difference between operational & aspirational work, how does the waste disguise itself, why QA is so prone to over-doing, that QA is much more similar to other disciplines of engineering than one may think, how making things visual helped us a lot with stopping starting :)
Part II of the series can be found here.
So, how far did we go in the last part? Not that far to be honest, we've identified some ways to "free the mandays" & started implementing them - but this was just the beginning of our journey ...
Increasing the capacity is awesome, but if not governed properly, the only thing it brings by default is ... chaos.
Why so? Let me clarify.
In many jobs (and QA in particular) the everyday activities can be split into 3 categories:
- operational - your hard commitments, something that just has to happen (within a given period of time) to keep status quo or just minimal expected QoS (Quality of Service)
- aspirational - anything that introduces the improvements (process, technical, whatever) so operational work is faster, better, brings more value, etc.
- waste - stuff that doesn't belong to any of the two categories above
In other words ...
- ... operational work is trivially measured, the most easily defined, always a first priority; if it doesn't happen, shit hits the fan & some important people get unpleasant - in case of QAs operational work is usually about pushing next release through - executives rarely care whether it's done manually or automatically, they just want new functionality delivered to the end users.
- ... aspirational work is much harder - it's about experimentation, introducing change (with a clear, beneficial purpose in mind!), "selling out" the effects of your work, assessing the outcomes, staying focused, taking ownership for proposed solutions; and all of that will make any sense ONLY if operational work is done properly (so you wonder: "maybe I'll do another round of regression tests just to be sure ...")
- ... waste is less obvious than you think, because ... usually no-one calls it a "waste" - people just look for non-committing activities they find a justification for, that either help in low (or near-to-zero) priority annoyances or even worse: just keep them busy but objectively speaking ... don't bring any value
Over-doing the QA
Understanding this split is EXTREMELY important in case of QA. Why so? Because in the Quality Assurance is the land of no clear border-lines. It's very easy to "over-do" things. Sensing the proper threshold when something is tested well enough is not easy for beginners or people who don't feel confident enough.
And what happens? Waste happens:
- QA engineers overlap (to increase the chance of finding incidents ...)
- instead of organising tests into as few cycles as possible, we re-repeat full suites twice a day (essentially doing exactly the same work ...)
- we mindlessly execute full test suites on the platforms practically not used by our customers (<1% of population)
- we shut ourselves within never-ending emergency mode acting like mechanic Turks that do not plan/optimise their work & have no time for aspirational work, because we're always in re-active standby mode (as there may be something to test popping up in next 5 minutes ...)
This sucks big-time & ... it's no-one else but ourselves (QA engineers) who are to be blamed!
It's convenient to be stuck in operational work, because it's always the highest priority & a baseline, ain't it? Perfect justification, but time passes by & we never have time to do any automation (or any other improvement at all). But we've worked hard, so we've managed to convince ourselves that we did our best, right?
Stop starting
Solution (to get out of this madness ...) is freaking simple:
- empirically set the criteria for "good enough" (even if you have to guess - as the last resort)
- based on these criteria, split work in a way that will leave people X time for aspirational work (& set the cut-off dates, so it doesn't last forever)
- sanctify the prioritization - there's no bug-less software, so stick to the highest priority stuff first, many things can be dealt with non-immediately - keeping the healthy, fluent release cycle is more important than some minor annoyances
- distribute the goals for aspirational work among your crew, but everyone should explicitly commit to a particular goal (this works far better than having them imposed)
- start short-term planning of work - both operational & aspirational (and make sure it's measurable to track progress!) - continuous progression (even if not exceptional on daily basis) will sum up & make the difference in time
- sync, sync, sync! - make everyone's work fully transparent so any trace of waste can be insta-spotted!
In our cases it meant:
- ditching testing of niche end-user platforms (browsers/devices) - or rather "outsourcing" it to our end-users, once the software is already on production
- determining the number of QA engineers needed to cover regression test cycle, everyone else were working on aspirational work (they did rotate of course)
- making a visual roster of who will do what in the forthcoming Sprint (who's on regression duty, etc.)
- annotating all of our test cases with "business criticality" of the functionality being tested
- determining personal goals & making the degree they are met visual in an objective way (e.g. splitting test case automation by functional area, assigning a particular person to the area, creating a dashboard with automatically refreshed progress of automation - split by area - current state + trend)
There were stills some questions unanswered, people unhappy with some conventions, missing specifications, a chance that some low quality features may slip, ... BUT perfectionism is a disease, that has to be ruled out if you want ANY progress at all. It may be against your habits, but QA is also an engineering discipline & things can always get some improvement here - so it's better to apply it continuously, instead of fulling yourself that you can make it perfect if you get just one more week.
In our case it was a perfect moment to STOP STARTING & actually TAKE OFF finally.
The next part of the series can be found here.
