Heard from a few channels (Twitter, LinkedIn, etc.) that
test engineers are getting burnt out because of the
agile methodologies and continuous delivery.
While Kanban has WIP restrictions to make sure that
we donât take more than what we can, Scrum does not
seem to have anything like that. Although Kanban is
continuous, it does not have fixed delivery time pressures
like Scrum.
Which one do you follow at your work? How do you find it?
Share your thoughts, please! Thank you.
We are in the process of doing a deep dive at the startup where I work into what kind of agility will work in our context.
Scrum ceremonies + Jira is our starting point, so we are going to explore, as a minimum, actual Scrum, XP and Kanban, as well as looking at the Agile manifesto to ensure that we understand values above all else and then find a way that works for us.
Phases like testing bottleneck and gatekeepers are those that we will seek to ensure we donât come across.
Essentially, if anyone in the team is burnt by the âmethodologyâ being used, then the team need to look at that and own it and any changes going forward. It has to involve the team.
I donât mind Scrum when itâs properly done, but everyone needs to understand what it is, why we do things and that the team can change the way it works.
Itâs wonderful that your team is experimenting with the various processes.
Agile manifesto is a very good place to start, and then branch out to the various processes.
Note down relevant data, and prepare âbeforeâ and âafterâ scenarios during each trial, so that you get a feel of which one worked for you better. A/B testing between two methods will give a lot of information.
While I agree that itâs always the people who eventually take care of things at the end of the day, frameworks need to have structures in place for taking care of human well-being.
All said and done, one needs to be diligent about their own well-being and take care of themselves.
Both scrum and kanban can create burnout in my view as itâs never ending!!!
Has anyone got any tips on how to prevent it?
Iâve noticed that doing a mix of things sometimes helps - maybe one sprint you do product and bug fixing, next you focus on tech debt. I find the pressure comes from delivering new things in the product and it can be constant. It can be a battle to fight for other important matters.
Itâs also important for managers / leaders to take care of their people. This is my number one priority of taking care of my direct reports before product.
Happy people = great product
Setting and managing customer expectations low on delivery can help.
I hear a lot of teams going crazy on delivery whereas not
not building real value for the product! Yes, this is happening,
and has to be prevented.
Also, someone told me that attaining simplicity in the process leads to project/product simplicity, and hence avoid burn-out. These were the resources I was given. You could do further homework/research and find out more information. And, do feel free to ask questions if you have any. We can discuss.
These might be developer-oriented, but testers could learn best practices from these too.
Take a look.
Regardless of methodology, style or tools that are used, there is always burnout.
If there is Kanban, some people will always break WIP limits, adding pressure to themselves, or the wider team. This could be individual contributors, or leaders external to the team who want to reprioritise independently.
Scrum can bring itâs own stresses too. These arenât necessarily problems with the idea of the methodology, but the way itâs implemented, if individuals within teams, or teams within larger teams arenât aligned.
Chrisâs organisations processes sound an excellent way forward. My question is, how comfortable are people in raising their concerns with their organisations, so they can be addresses?
And how frequently does this happen, so that problems are addressed rapidly?
This might be easier in smaller businesses, where you can create your own change, without upsetting the apple cart.
Equally, larger orgs might have the processes in place already to handle this, but just operate more slowly, due to their sheer size.
Individuals might fear that they cannot make change in such an organisation, even at a granular level.
For me, itâs about creating an environment where people can say no, where they can say they arenât enjoying the workload, and that they arenât feeling good.
Burnout, for I have lived this, is both physical and mental. And quite often it will also be a problem that is external to your organisation that you canât control or manage such as.
The mental or physical health of a team member
Some challenging life event, such as a birth, bereavement or other personal matter.
The question is how does the organisation respond to such things? Do they let go of that person, and wash their hands of their part in the problem? Or do they adapt to the needs of that individual, so their place in the team isnât jeopardised, and their skills and thinking are retained.
Burn-outs could also happen when a person works in the same technology/field for a very long time and does not enjoy it anymore, or needs a change.
In software, most of the work is mental, so mental well-being has to be taken care of.
If physical circumstances like workplace environments, commute, etc. are not supportive, it adds up to the stress.
If the processes that we follow are just throwing work at us irrespective of how the person is feeling at a point of time, it becomes very difficult. Thatâs why I started the discussion.
Some thoughts:
One of the most imporant things in work is sustainable pace. If the pace is too high, then you get burnout.
In one company a manager asked the scrum master how much he could deliver. He answered with 7 or 8 stories and handling of all incidents in one sprint. The PO had to set the priority right.
Key ideas:
Other ideas:
Yes!!! This is spot on! Itâs all very circumstantial. No oneâs situation is the same, but after 20 years in testing, I am/was feeling a bit exhausted by it.
Learning all the time, yes, but not always the right things, or in the right way.
Iâm intrigued that itâs the test engineers that are getting burnt out, which seems to imply the rest of the team isnât. Which suggests the teams arentât really a team: theyâre not in it together, one of them can lose while the othes still win.
I think both Scrum and Kanban address this. Scrum tells you that people not part of the team can only address the team as a whole. So it can never be âWhy did testing take so long, tester?â, but only âWhy did it take so long to get this done, team?â Kanban focuses on pull and has WIP limits to prevent developers from piling up work in the âto testâ column.
In my experience itâs the stakeholders/managers that can make a big difference here. If they present a number of outcomes they want to achieve with the team, youâll get a very different dynamic than if they present a list of features they want to have delivered.
Didnât say âonlyâ test engineers get burnt out, but since this forum is for test engineers, I addressed that way.
Not sufficient for Scrum to just address the team, but has to have some checks and balances in place like Kanban WIP to make sure that people donât commit/take more than they can. Is there any?
Contents of your final paragraph is agreed, i.e. âoutcomes over featuresâ.
More specifically - âProduct value over delivery/frequency while everyone is having a healthy life.â.
In Scrum itâs the Developers (members of the Scrum team) that decide what goes into the sprint planning, so that does give them the power to prevent themselves from getting burned out. (Plenty of ways for an organization to pressure teams into putting too much in the sprint, though.) On the other hand, I believe it was Jeff Sutherland who said that if a team makes their sprint goal more than half of the time, theyâre not being ambitious enough. I think itâs hard to create an organization where you can set things up like that in a healthy way.
We started with Scrum from the Trenches years ago and added the hard rule of not allowing more than 3 Stories to be In Progress at the same time for a 7-person team. I agree with most of what has been posted so far. The whole team (testers included) needs to agree on stories in a Sprint. The more of the company/organization that buys into the process, the better. More predictable dates, fewer bugs, less burnout.
Some rants in random order, based on the first things that came to my mindâŚ
Itâs not Scrum or Kanban or whatever other processes that puts pressure on Test Engineers.
Itâs their managers and peers, and the testers themselves.
As a Tester you work for a manager who pays you to do whatever he thinks or wants of you - unless his mind is steered in a different direction. Itâs not always that the tester agrees or feels heâs appreciated or making a difference, or has a reason to work for themâŚ
The manager can enslave a tester into: doing useless things, not being challenged, doing the opposite thing of what the tester would want, staying overtime, being the bottleneck, taking all the risk of all the other broken people and processes, being a gatekeeper, being a documentation writer, doing technical support or writing a manual, developing and managing a separate automation checks product on their own, manage environments, steer business and help them create product specifications/tasks, etcâŚ
The testers, even the good ones, are weak at showing their work and talking about it.
So they are easy to be pushed over and be told what to do without being considered much.
The quantity of testers has increased but the quality of the testers has decreased over time.
So the testers are afraid to argue, the managers are not afraid to replace them with another badly paid tester.
And this is made worse with these new methodologies of software development where the risks and decrease of product value are not assumed by managers anymore, but shifted down to the workers that have to push feature after feature in production.
One interesting thing on what you wrote about âtesters are weak at showing their work and talking about itâ. Why is this? Canât they equip themselves with organized data points, metrics, etc. so that they can confidently talk about their work?
The other points are subjective. I have seen highly paid and respected testers. Their morale is also very good.
Yea I came to say much the same as others. No framework takes care of your wellbeing, because these frameworks like scrum and kanban and whatever else people use, are primarily built and sold as ways to work faster and improve âproductivityâ. Only people care for wellbeing, either their own or that of others around them. No framework, no business methodology or anything else whose aim is to make you go faster, is ever going to prioritise your health. Uh, in my opinion. Which is not an expert opinion, but yano open forum and all that. xD
Some additional thoughts from @thomas.binns on Twitter
The âHoweverâŚâ part practically does not happen as per many people who commented here, because organisations try to push as much as possible to be implemented.
As far as âPoor managementâ is concerned, there needs to be a mandate to enforce good management. Letâs see how that can be done.