Developers are from Mars, QA are from Venus

Designed, developed, handed over to QA for testing. Then all hell breaks loose. “How do I test it?” “Where’s the documentation?” “This is broken; not it’s not, it’s not our component.” “I’m not signing this off!” Or my personal favorite: “I’ve other priorities to test now. I’ll get to your stuff tomorrow.” for three days in a row. Keeping QA separate from development teams is a recipe for trouble, friction and lots of missed opportunities. It has to stop.

Once you put a QA Engineer in the same team with developers, sharing the same manager, several things happen:

  • QA shares the same goal with developers – to deliver an excellent product on schedule & budget. No more bouncing tickets back and forth “this isn’t working!“, “it’s not a bug, it’s a feature!” “this isn’t a blocker!” Shared goal, shared ownership, shared responsibility.
  • QA knows product first-hand by spending time with developers as they work, talking over each feature and scenario. Ever tried asking a developer to write a test script for QA? Good luck with that. Sit the QA next to a developer and they can write the scripts perfectly themselves.
  • Testing gets done early and often because QA doesn’t have any other priorities or anyone else shouting louder at them to get their work done faster. User story finished? Alright, let’s see how it works. Right now. And iron out all the bugs right there, on the spot.
  • Testing gets automated when QA sets up Selenium (or any other) scripts together with developers, that they can later re-run as frequently as needed to check whether they’ve not broken something.
  • Developers spend more time coding because they don’t need to setup their own testing data and other environment pieces. QA can do it in parallel and whenever needed.

Sounds obvious if you’re an Agile zealot, right? Notice how I never used the “A” word? I didn’t have to, because the above ideas have nothing to do with the movement. Even Microsoft knew the value [PDF] of pairing developers and testers way before Agile was even manifested.

Testing is not separate from developing. It never has been, but today, when software requirements and markets change all the time, and so does source code, it’s more expensive than ever to keep a QA team separated from development. For the sake of your company’s success, stop doing that now.

Evolving towards Kanban

Kanban is the last stage of software delivery evolution. Right now, at least, as evolution never really stops. The path is usually the same, starting with a disorderly “let’s just code”, moving gradually towards a waterfall system, then painfully stumbling towards a formal Agile framework, say Scrum, and once a Scrum team truly matures, they realize they’re really doing Kanban with a bit of unnecessary paperwork.

The jump from chaos to waterfall is rather obvious. So is usually the next step to go Scrum (or any other framework you like). We love all the Agile principles, user stories help focus on business outcomes, expecting changes makes Product Owners happy and programmers less stressed. Estimates made in story points help the management see when things will be done and ready, and make decisions based on that.

In Scrum for a new project you define a whole bag of user stories, estimate them, order by business value and call it a “Release”. That Release gets split into Iterations, each of 1 or 2 weeks in length. When you’re done with all the Iterations, you’re done with the Release and ready to unleash your product onto the general audience.

We’re often working, however, with software that’s relatively inexpensive to release. Like web applications, where you upload code to a server and all your users instantly get the latest version. There’s obviously the question of stability, quality and testing, but Scrum says strictly that the definition of “done” is “designed, developed and tested.” So, by that definition, you should have a release-quality product after every Iteration.

Add the two things together and you soon have a Product Owner asking you whether it’s possible to do an interim-release, before the whole scope is done. Sure, it is. It takes a while to work out discipline and processes right, so that the quality really is good, but once you’re there, you can release right after the Iteration summary meeting. And the Product Owner has a point: why do we wait another X weeks for the whole Release to be ready, when we can have something live now? Competition never sleeps and some of these things could make users seriously happy.

Here’s where Kanban comes in: once you’re ready to release after every Iteration, then the answer to “when will this be ready?” becomes “right after the Iteration you put it in.” Long-term estimations become irrelevant, as they always were anyway. Just because you have a user story planned for 3 Iterations from now doesn’t mean it’ll really be done there and then. Things shift all the time.

Why bother with the “Release” planning then anyway? Switch to a higher-level roadmap of changes, so that the team continues to follow a vision for the product, but plan actual work only for the next Iteration. Then release it immediately. Now you’re doing Kanban.

Refactoring is also development

Try cooking in your kitchen for a week without cleaning. Just leave all the used packaging around and all the dirty cutlery in the sink. I bet you’ll not only be unable to walk safely from door to window, you may also feel like throwing up due to the spreading reek. Do that for a few months and it’ll be easier for you to move than clean up.

Something similar is happening daily all over the world at software vendors. Because there’s always a business reason to write new code and never to clean up the existing one, everyone ends up managing thousands and millions of lines of code, often written three generations of employees ago. “Where is this method used? Uhm… I don’t know. Carl wrote it and he left the company during last year’s layoffs.” At some point writing any new change requires more impact analysis than designing and coding. Then someone comes up with the bright idea of scrapping it all and writing from scratch.

Refactoring must be treated like any other part of the development process:

  1. Designing
  2. Testing
  3. Coding
  4. Refactoring
  5. Go to 1

It must be expected, planned and estimated for. Not “when we have time” or “when we’re done with all the coding” but right after we’re done with the current chunk of code. It may be more expensive upfront, but then so much cheaper in the long run.