Agile testing

Bob Galen on the Role of People, Technical Expertise, and Test Automation in Agile and DevOps

Bob Galen understands people as much as he understands processes and technology. While he would be the first to affirm that yes, processes and tools are important in software testing, his natural inclination is to first ask the people involved: how can the tester be empowered?

During our conversation it struck me that Bob, now the Program Chair behind Techwell’s STAR conferences, embodies the sort of philosophy that inspired Agile methodologies in the first place. People over processes. As an Agile coach, that’s exactly what you’re looking for. Connect with Bob and check out his upcoming speaking engagements here – including STAREAST, coming up on April 29.

Chelsea: Can you give a brief overview of your specialty and interests?

Bob: I am an Agile coach and trainer. StarEast is focused on testing, so my topics here are agile testing, some automation, and Agile leadership. What is interesting about Agile to me is that the hard stuff is the soft stuff. A lot of programmers and technology folks don’t understand that very well. They are often intrigued by the technology, but not so interested in the people, and that can get in their way. So for me, I try to flip that and put the people first. I have a technology background, but my focus is on the people. Agile is a people-first methodology. It’s not process first, tool first, or organization first. A lot of people forget that.

Chelsea: That is actually one of the main tenets of Agile, isn’t it? People over process is one of the foundational ideas.

Bob: A lot of people just pass over that. It’s kind of like the “fine print”, a lot of people don’t read it or just conveniently forget the details. I’ll give you an example – most software expos are all technology focused. There are no soft skills, no training. It’s not the Expo’s or the vendor’s fault, but it does expose the overall focus. What aren’t those tools going to do? They aren’t going to save your project, save your testing, save your life. I am not anti-tool, it just goes back to the Agile Manifesto: the tool needs to be the servant of the people. And everyone seems to be looking for tools to be silver bullets.

Chelsea: It’s true, everyone wants a formula. Formulas make people feel safe. People aren’t required to think if you can hand them a formula.

Bob: If I had a dime for every time, as an Agile coach, someone said to me, “just tell me what to do. Just give us the formula.” I would be a retired coach. Now I can give ideas and lead them in the right direction. But it is their choice to think through it, apply it, and take accountability. The accountability is key. Unless they take accountability for their Agile process, any failure will just be MY fault, whether that is true or not.

Agile champions the idea that true wisdom can be found within the teams – it’s the crowd sourcing mentality. You just have to be able to tap into that collective wisdom. That may sound like psychobabble, but it is true that the best design for software, the best testing strategy, etc. is going to be mined from the collective experiences and skills of the team.

Chelsea: When I first entered the software world and started learning about Agile and DevOps, it seemed self-evident that ultimately it is all about psychology and philosophy. Yes, there is an important technical aspect, but ultimately all testing is psychologically driven.

Bob: You have the advantage of approaching it from the outside – in. People who can approach Agile or testing with an outside-in perspective naturally bring a whole other understanding to Agile. Because of my development background, I cannot help but approach it from a technical perspective, even if I am focusing on the “soft stuff”, or the people. I cannot help but see the technology, and that skews my lens to some degree. It really helps when people from other disciplines work with us.

Chelsea: Do you think that is the goal of DevOps – to blend the technical and the soft skills together?

Bob: I don’t know if you could say that is the goal of DevOps, but it is certainly a goal of Agile. I would say that DevOps is a subset of the Agile mindset. It is a goal of Agile to blend the soft skills into the technology. Start with the manifesto – it becomes clear that hard and technical stuff matters, but soft stuff matters more. And we struggle with that. But you could say it’s in our DNA. Your DNA, your background, is soft. My DNA is hard. If we surveyed everyone in the tech sphere, we would find that many are “hard” by nature. It is how they are wired to think. And it is those people who have the hardest time adapting to Agile. For example, seeing greater value in pairing and delivering code as a team versus simply writing it themselves.

It’s a balancing act in the end, and that is the challenge.

On the other hand, we all have our comforts zones. What is home for you – soft or hard? Being at “home” in the soft skills doesn’t mean that you are technologically illiterate by any means – more so, it is a question of, when the pressure is on, where do you go? When you are in “crunch mode” we all gravitate to our comfort zones. A lot of companies put pressure on their employees to get things done, which can throw off that balance.

Chelsea: So, since we are talking about this within the testing space, where do you think that testing actually fits into the DevOps cycle? Between this blend of development and operations and hard and soft, where do you fit testing in?

Bob: This is going to sound weird but I want us to stop talking about DevOps, stop talking about Agile, or testing, or development, or any processes, and start talking about getting stuff done. Part of getting stuff done is all of those things, and we need to continuously do them. If you have the Agile mindset, not considering DevOps doesn’t make sense.

I once worked for a company that worked with Scrum teams and Agile methodology, but we had this tendency of just throwing things into production. Well guess what would happen? It didn’t work. We didn’t consider the DevOps environment. We tested it, but we didn’t test it with the customer or the real world environment in mind. So we had to start including DevOps into our process, and ultimately we shifted left and began testing incrementally along the Agile development. Soon we were thinking about testing concerns alongside development concerns, and DevOps alongside our testing, our UX and design, and so forth.

So when it comes to testing and DevOps, I think the more that we focus on the horizontal concerns – to get things done- the better we focus on the customer and do a more complete job.

Chelsea: So, it sounds like what you are saying is that “getting stuff done” essentially requires considering everything at the same time. It’s essentially Continuous Testing – it’s continuous development, continuous integration –

Bob: It’s continuous everything. Continuous testing is continuous customer awareness. The sooner we can get feedback, the better it is. And the longer we wait, the more risks we are taking. That’s sort of the holy grail of Agile.

Chelsea: That’s a funny thing because the three Cs are the holy grail of Agile for so many people, but are they actually benefiting from that strategy? Do they ever stop to ask themselves, “Is this good for our customer? Is this good for us?”

Bob: That’s the value question – have we verified that this is actually beneficial? That’s the hypothesis, but do we have the proof? Are we letting these ideal processes overtake the things that are really of value within Agile?

That brings us back to tools – tools are important but people are more important. And I have been in companies where the tool that was supposed to make everything easier was actually proving to be a hindrance to communication. So I unplugged the tool. It wasn’t the tool’s fault – but it was replacing human interaction. The tool was becoming a crutch to the team. Sometimes tools can get in the way.

Three to four months later, we turned the tool back on because the culture had shifted, and the tool could then be an asset instead of a crutch.

Chelsea: Do you think that is where Agile software testing and development is going in the next few years – that people will begin to see tools as a crutch and that software needs to be more human-driven?

Bob: I do hope we make that shift. I do think that culturally, because of our geekiness – because of who we are, that we will always love tools. We are relentlessly hunting for silver bullets. But it takes people who are looking at the software space from another angle who can help that.

I think we are on that trend, but I don’t see the end of the tunnel. True DevOps, true performance, and achieving the ultimate output of Agility, requires balance. There has been improvement, but we still have a lot of room to grow.

Chelsea: As an agile coach, what do you see as being some of the biggest obstacles to achieving high levels of test automation?  

Bob: Of course, skills come into play. Another obstacle is whether the business actually values automation – wanting to make the investment. Being able to make your product owner your partner and helping them to understand the value of investing in automation is crucial. You cannot do automation without first getting it on the backlog and being able to show the demonstrable value of it.

Chelsea: So you are saying there is a link between automation and soft skills.

Bob: It requires soft skills to make the case for automation – you have to talk in business terms, speak to product owners, and be both courageous and relentless in making the case. So, in those terms, soft skills are an important part of the automation story.

I do think we end up talking about these high, magic number rates of automation, without first asking ourselves, “how much automation is actually appropriate for this project”? Not every project should have 95% automation for each story as it comes through the sprint. Some may need 50% automation, while the remaining 50% is a mix of manual and exploratory testing. What is important is helping customers and stakeholders determine the right mix, and to think critically about finding what is right for them.  But that is a challenge for many organizations.

Another challenge is for organizations to be proactively maintaining their automation and infrastructure within DevOps environments. So many organizations invest heavily upfront, but they have a harder time maintaining or evolving that environment so that it can grow and improve. Make sure you’re making a longer term business case for your stakeholders.

Chelsea: You are the first person I have talked to today who has used the term “shift left”. What do you think it takes to successfully shift left?

Bob: In a word, I think it’s courage. I think it’s a value proposition. Let’s pick on testers for a minute. What do testers typically believe their value proposition is? Testing of course. Automation Engineers – what is their value? Scripting. Getting more greens than reds on their tests. All of those things are good, but are those things providing demonstrable value to the client? Only in part.

Shift left, to me, is shifting left and getting to the root of the question “why?” Why are we doing this? Why are we running this user story? To me, that is shift-left thinking. That is DevOps thinking. It is trying to be more intelligent about HOW we test by being more intelligent about WHY we test.  That type of thinking isn’t just for testing or development either – the requirements, the UX, the design – all of those things can be benefitted by shift left thinking.

Shift left, to me, is all of that. And that is where speed is. Quality is there. Getting it right the first time means that we avoid rework. DevOps matters, testing matters, but I think what matters the most is the team and this horizontal “shift left” view towards workflow and value delivery. Don’t just optimize the silo – optimize the team and the system.

There is this notion of systems thinking. We are not optimizing parts – we are optimizing the whole. Shift left, to me, is systems thinking.