Do we need QAs/testers?

 

“Do we (still) need QAs?”

… and flavours thereof, is a question I have been hearing for years now.

The same has been asked of Tech Leads, Operations Engineers, “Front End” devs, “Back End” devs, Security, Iteration Managers/Scrum Masters, Business Analysts, etc. Anything that is not a full-stack dev. The #NoOps conversation is interesting research material.

It seems to me that this question stems from a misinterpretation of agile and lean startup materials.

Idealistic hopes of cutting costs, removing waste (and blindly classifying some roles as such), delivering faster, etc., have caused some to think that role specialisations can all be generalised into being “Engineers” and that we can all self-organise and just do it all.

Continue reading

Remote pairing, how do I even?

I’m fortunate to be one of this year’s REA Grads (http://careers.realestate.com.au/graduate-programme/). A great part of the REA Graduate Programme is the opportunity we get to rotate through six different teams within the business over an eighteen month period. My first grad rotation was in a distributed team, which posed a challenge as half the team and the majority of developers were in China. I often needed to connect and share my screen to collaborate with the developers in China when working on a task (remote pairing). During the rotation, I picked up a few tips that helped reduce some of the challenges that surround remote pairing, which improved the overall experience.

Continue reading

Securing third party applications

Our IT Security and Risk (ITSR) team is almost invisible to the outside world, yet is quite influential amongst our technical teams. The ITSR team is constantly searching for patterns to improve our security posture, and proposes—and sometimes implements—approaches to ensure that REA Group’s infrastructure stays as secure as possible.

In this article we will uncover some “behind-the-scene” approaches implemented by the ITSR team as a proof-of-concept solution to showcase the technology.

In the modern world it is almost impossible to create an infrastructure purely based on the “in-house” solutions and products where every single line of source code was audited. Therefore, companies are relying on a myriad of third party components which source code is either inaccessible (e.g. proprietary software) or was not audited.

To make the matter worse the majority of vendors do not follow IT Security best practices and their products are usually using excessive sets of privileges. For example, instead of providing an SELinux policy module tailored for their application they simply state that the first installation step is to “disable SELinux”. This approach is clearly understandable from the business point of view (e.g. the support cost is lower), but is not acceptable from the security point of view.
Continue reading

How to use solutions-focused scaling for Agile Retrospectives

Most Agile retrospectives are about how the team is feeling e.g. happy, sad, confused etc. We then try and understand the cause of the problem so that we can fix it, in the same way that we try to debug an issue with a software program. This approach makes sense when dealing with complicated problems, such as software, which have direct cause effect relationships. However, when working with team dynamics, people interactions and feelings, we are working with, and within, a complex system that doesn’t have a direct cause and effect relationships.

Trying to understand the root cause of something in a complex system can take a lot of time, and isn’t necessarily helpful in finding the desired solution. In complex systems, there is no direct relationship between a problem and the desired solution – this is one of the things that defines a complex system

Solutions-focused approaches to change[1] have shown that a more direct approach for complex systems is to investigate for clues of where evidence of the solution you want is happening already and do more of it. In addition you can also identify small actions to take, like mini-experiments, to see if these actions nudge the complex system in the direction of the desired solution.
Continue reading

How and Why We Run the REA Graduate Programme

O(n) Week Day 1, 2015 – Somewhere in the Yarra Valley, Victoria: A group of fresh young faces gather in small groups around a house-cum-conference-centre nestled amongst the trees. A communal dinner has been shared and there are beers and soft drinks in-hand: some play pool, some cluster around a newly learnt eurogame, some just chat. Our 2015 graduates are starting to relax and unwind at the end of their first day of (O)n Week.

Continue reading