How to introduce Agile to a waterfall company as a Tester?

Question

How to introduce Agile to a company working in the waterfall paradigm?

1. People

How to best describe it to

• management
• developers

Can Agile "guarantee" some quick wins? Does it depend on the type of people working in a company? Will some people resist it because it will push them out of their comfort zone?

2. Personal

Is there a risk that pushing for the Agile might be seen as a personal project of a person pushing it? If yes, is it too big of a project for a single person?

3. Downsides

Since nothing is perfect, one-size-fits-all solution, Agile might not be suitable for every software company. What are the signs Agile wouldn't be a good fit?

Note

This sounds like a very broad question, an ideal candidate for Needs more focus flag, but I think, while pretty broad, it might be a starting point for testers finding themselves in a new company and wanting to do Agile, but still not knowing enough about the company culture and the coworkers to start pushing for changes.

Answer 1

Agile is known everywhere. Most folks know the terms and activities. That is your main challenge.

What you see is not agile. but it is likely that the people involved are not ignorant about agile and terms used.

More learning is required by you.

a starting point for testers finding themselves in a new company and wanting to do Agile, but still not knowing enough about the company culture and the coworkers to start pushing for changes.

A good question though. The answer is to spend a few months learning why they aren't agile. Listening to spoken words and watching unspoken body language. True agile doesn't mean the ceremonies commonly referred to. There is no mention of a stand-up in the manifesto :) A truly empowered workforce could have different approaches to different problems.

When agile isn't present you need strong buy-in all the way up the management chain. Arguments from the bottom are hard to make and of course change is really hard for everyone. Even if you have stand-ups and ticket-grooming, it's all 'in-name only' with the intent likely lost unless there is major buy-in at the C suite and all levels of management. Changing to more agile practices is a multi-year process for many large companies that requires dedication, focus and whole company commitment. Testers don't usually get the authority to drive that message.

All said, my answer to your question is to switch from the "big picture of introducing agile into the organization" and focus on testing for agile environments This means focusing on the test pyramid, how it exists and what it promotes, focus on unit, integration and UI testing, Focus on 'quadrant 4' issues such as usability, performance and security. Focus on the benefits of TDD and BDD by using them yourselves in some way. You will likely have a more receptive audience as it is likely these are terms folks already know and use and have practices for.

The big picture for Agile is that it requires changes in every aspect of the company, from hiring, to HR to compensation to reviews to physical environment to management techniques. When some pieces aren't done or funded or supported or introduced correctly, you end up with the mess we often see. Multiple rounds also lead to 'agile fatigue' where the mere mention of the buzzwords is either annoying or ignored.

Answer 2

Well you'd likely start by addressing the Manifesto, and trying to get the company behind some of these principles.

And the values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

(valuing left over right, but not instead of)

It's tough for anyone to disagree about valuing working with the customer, or responding to change instead of blindly following a plan, working or not. So you could start by introducing some of these. You don't need to start with sprints and a kanban board / scrum team. However, you could perhaps put your own tasks on a kanban board, visible at your desk, to visualise your workload for others.

Take the principle Continous attention to quality - if problems are appearing, you could start talking about shifting left in testing - more early on tests, unit tests, static analysis. You could also talk about meeting with the business people, the devs and yourself - to discuss tasks before a dev builds it, to exactly clarify the acceptance criteria for said task. It's amazing how many potential future bugs can be ironed out.

Take it slow, and introduce one at a time, or where you see an opportunity.

One place I've worked at where it struggled was a bank. They claimed 'agile' but when everything is audited, signed off definitively before a project starts, and your daily standup has 35 people, it wasn't working great, despite a scrum master trying to improve and deliver change.

Answer 3

Solve a real problem using it.

Any process has value in proportion to the value it adds by solving a real problem in a real team in a real project.

How would you solve a real problem in your project using agile? Think it over.

I would suggest going small. Plan small. Point at low-hanging fruits and quick wins which adds substantial value as a starter to win confidence. CONFIDENCE of the right people who matter. As long as you can solve real problems even though they are small using it in a visible way, you are demonstrating an idea that can be applied to solve bigger problems in the same way.

Eventually, you will win the confidence of the right people who are decision-makers when they can see the actual value added by the process.

Answer 4

As most QA testing companies work on Agile model nowadays, hence to explain them in an apt way, we need to clarify the future roadmap and targets that we want to achieve in the coming quarters. Moreover, for the growth of both individual and company, it is an important step to practically implement the Agile processes within small projects in an organization.

Answer 5

In the tester’s language, agile can be defined as an iterative practice where cross-functional teams work collaboratively on the entire software development lifecycle. It is a project management approach that involves testers, developers, and technical teams working together right from the time requirements are defined to the development, test, and release phase.

All in all, if you need to avoid errors and have overall effectiveness with the development process, agile testing allows you to deliver value and foster quality assurance solutions. You can read more about the importance of Agile Testing in SDLC here.