Can Agile make a tester more Dis-empowered

Question

Was a single tester(TA) in waterfall project. company went through mergers Currently going through Agile transformation.

before -works under product owner (PO) and had more autonomy of selecting tools. way of (level of) testing. Could make independent (of course after discussing with PO) decision whether to release ready or not. Could prioritise which product(has couple of) to test first. What to test and what not to. Could spend small time on research stuff etc.

Now - A Developer promoted to a PM and given some of responsibilities PO had, and PO is more focused on customer value, new BA role established. Now the all processes and decision (team related) was made by PM and senior developer/s. TA is being bombarded with JIRA tasks. Only say is time estimation for testing. PO is a powerful role in both instance. Now PM/BA has more interaction with PO and information flows through PM/BA to TA.

When the News spread we are going to work in agile I was really enthusiastic. it suppose to be more collaborative, empowered and space for professional growth. But now of course professionally I'm on reverse gear. My questions is what is wrong with this agile setup? Is it natural to TA to loose responsibilities and confined just JIRA task testing (in agile transformation)?. Or since PO role was so powerful in company, I enjoyed too much responsibilities? How should I react to this situation. What method, tools could I used to overcome this scenario.

Answer 1

For starters, Agile is not an actor.

One doesn't "work with Agile", "uses Agile", or things of this sort. Also, Agile doesn't act, it "doesn't do/make things".

Agile is a mindset described in the Agile Manifesto and other documents.

By reading your short description, it seems that before you used to work in a manner closer to the Agile Manifesto than now.

Principles:

The best architectures, requirements, and designs emerge from self-organizing teams.

Before: "autonomy of selecting tools", "make independent decisions"

Continuous attention to technical excellence and good design enhances agility.

Before: "spend small time on research stuff"

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Before: "of course after discussing with PO"

And now it seems these practices that worked for your context went downhill.

However, as you said, different people are playing different roles. You may not have the same relationship with them now. In the organizational charts parts of the team, you may be accounted as part of the team, but in practice, you may not be, because of this weak relationship.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The role of any person, while in a team, is to discover how his/hers skills can best serve the team, even if this role doesn't explore all skills a person has. For that, you need to observe, talk, and experiment. Adjust not only your work but suggest to others different ways of working so that the set of contributors work in the same direction. It's your role and your teammates to discover it (vide the self-organizing principle above).

A parallel can be found in football: Xavi Hernandez once said his playstyle would never make him the Player of the Year, but that it would create many Players of the Year. Xavi understood his place in context he was in and, together with his teammates, adapted and adjusted.

If "PO is more focused on customer value" is a reality in practice, you and your teammates can use the PO knowledge to discover what is important to your organization and then implement development practices aimed at maximizing this value. Practices that don't focus on it will be clearly exposed to higher management disapproval - meaning that if some people want to act as bosses for the sake of it, in contradiction to the business value, the team will be able to fight back.

Most probably "all processes and decision was made by PM and senior developer" is a practice that doesn't yell the best business value (vide the self-organizing principle). Maybe not. Depends on your context. Again, you and your team are the ones responsible to discover if that's the case and propose/implement necessary changes to improve.

In summary, it seems you need to work on understanding the people and your context and use your social competency to implement changes you see fit for the business (regardless of anyone's "power", current, past or future).

Answer 2

It can work both ways, it depends on the situation

In some companies Agile is bunch of buzzwords used to cover the fact that waterfall and command and control are really what's going on.

In other companies Agile is used in an empowering model giving more voice and input to all folks including QA.

My experience is that the former approach is what exists in most companies.

In your case, instead of being able to take those things for granted you will now have the additional task of being an evangelist / teacher to spread the good word.

Answer 3

The sad reality is that the organization or team toxicity is being masked by buzz words like Agile, DevOps etc as Michael and Joao pointed out.

They miss the main principle of Agile: (http://agilemanifesto.org/principles.html)

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

If these methodologies are implemented in the correct sense then it's a huge opportunity for the entire team. But sometimes you end up with toxic team strategies.

I also had such experience, where I was taken in as Test automation engineer and in reality, the team wanted me to do test automation as a side job.

The main reasons for such a mindset are:

1. Not knowing the value of QA
2. Having a QA just for the process sake
3. Thinking agile is all about passing PBIs to done and never revisiting them
4. Not understanding the impact on the customer base, if one feature is missing or not working
5. Products are usually internal
6. Taking customers for granted, being confident about market shares as there are no visible competitors
7. The mindset that QAs are people who lack technical skills ( not giving access to DB, not giving rights to create repos, not giving configuration rights in CI/CD etc are signs of it).
8. Professional Ego and trying to move quality responsibility from the team to just QA , and thereby playing the blame game.

To name a few....

The things you could do here is:

1. Work on proof of concepts
2. Ask for local setups of database and CI/CDs and create a proof of concept in your free time.
3. Start learning new tools, and implement them one by one
4. Show the demos not in regular sprint meetings but in important team meetings where you get visibility among other stakeholders.
5. The document you work and publish in internal newsletters and articles.
6. Help other teams wh are interested in your proposal, help them to set up the project and use that project as metrics on how your solution will provide greater RoI.
7. Document all the findings and observations, but don't be adamant to get it fixed. Just use them as references if you get the same feedback from customers.

I know the journey would be hard, but its a chance for you to learn more people skills than just technical. All the best with your effort

Answer 4

Yes, "agile" can dis-empower anybody when it's used as a buzzword rather than actually being done. It sounds as if you're in that situation now.

Here's what agile, when done right, can look like. I can't tell you how to bring your situation in line with what's below, but at least knowing where to aim can help you at least move parts of your organization in that direction.

The Agile Teams

In agile, or at least in XP, there are just two teams: the customer team (also known as the product owner, the business folks, or similar) and the development team. Each has distinct responsibilities and control over a particular area of the development, and they don't step on each other's areas. It's possible for someone to play a role in both teams, but she would have to be careful to keep those roles separate, wearing only one "hat" at a time.

Testing is done by both teams, for the obvious reason that the customer must do at least minimal testing just to see if he got something resembling the story he requested. It's not unreasonable for the customer team to have professional full-time testers on it, if the customer feels the need, but that would indicate a certain level of distrust in the development team that should probably be worked on. Testing is a lot cheaper when done by the developers than when done separately because code can be designed to be tested more easily, if the developers know what's needed.

The development team will be doing extensive testing, whether formal or not. In the worst case, it's done by an individual developer just running things "by hand" as he programs until he decides he's done working with the story. But usually there will be automated tests of various kinds (unit, functional, UI, system), discussion of testing strategies, perhaps continuous integration, and so on, all of which is designed to give both the developers and the customer confidence that what they think they've done actually works.

In this world, full-time professional testers are developers, and full members of the development team. It doesn't matter if they're not writing the code under test: they're still working with the rest of the team on getting stories completed, contributing to the design of the system (particularly in the area of making it easier and cheaper to test), often working on and even writing test frameworks, and so on. This is where you want to be, as far as I can tell.

Agile Project Management

Your phrase, "a Developer promoted to a PM," rings alarm bells. "Project managers" on the technical side are generally bad news in agile since their traditional work is done by the actual workers in the development and customer teams in agile.¹ The customer and developers work out the stories, the developers estimate them, and the customers choose the order in which to build them, and the developers keep track of story progress and team velocity. In particular, the only people who should be contributing to producing estimates for a story are the ones that are actually doing work (or willing to do) work on the story (be it writing the software, testing it, or deploying it).

PMs often realize, consciously or not, that there's not a lot of need for them in this scenario. This often leads to a situation where they are (again, consciously or not) subverting the process by trying to set estimates for work they don't do. It's a difficult and often very political process to prevent this from happening. But if you can't prevent this, you're moving away from agile, not towards it.

To move away from such situations, the general approach is usually to:

• Have non-developing PMs move into the customer team, helping to handle the details of their work (negotiating stories with developers, figuring out what order in which to do them, and estimating and tracking overall, long-term progress on the product).
• Have developing PMs spread the work they do amongst all members of the development team, such that there is no longer a "PM" in the develoment team but the PM work is spread amongst all the developers.

Summary

What you want, and what will work well (if well executed), is probably to become a full-fledged member of the development team, contributing to the development in the particular areas in which you are skilled. I can't give you specific advice on how to make this happen because that's completely dependent on the particular situation in your company, and the willingness of others to accept that "testers" are developers too. But I hope that these ideas can at least give you a framework in which to try to move towards this.

---

¹_{It's more complex than this in larger projects, but that's a whole separate topic.}

Answer 5

information flows through PM/BA to TA.

Sounds like a mini-waterfall to me. Agile frameworks like Scrum and XP have values like: Courage and Respect.

Have the courage to address this in a retrospective. Handovers are error prone, I think it is better to start with testing earlier. A common pattern is doing Three Amigo sessions before you start the work on a backlog item. Ask the team to experiment with it. I think it will make you feel more empowered if you have been part of the work from the start.

The best architectures, requirements, and designs emerge from self-organizing teams.

As for respect, I think the team should respect your input. Understanding it is not about pushing work to roles, but that roles pull work. Telling people what to do shows not a lot of respect for autonomy. You do not sound very self-organized.