Scrum vs Kanban - Which one takes care of your well-being?

Agile is not just about ‘productivity’ but also doing things in small chunks and showcase them to the customer, so that incremental development is achieved. The problem happens when organisations get over-enthusiastic and try to push more than what can be taken by the team.

Good thoughts, and of course, all views are welcome!

1 Like

Agile might be about more than productivity, but I’d argue that kanban and scrum specifically are not. Productivity is their selling point, and the mantra; the justification and reasoning for using them. People don’t pick up kanban or scrum because they know or value the entirety of agile thinking, but because they know that agile teams do more, faster. And if that’s the only value people wanna get out of agile, that’s the value they will get out of it. Not the full values of agile.
So I stand by my argument that neither kanban nor scrum look after the wellbeing of the humans operating inside them. They are not made to protect individuals from burnout. I mean, just looking at Scrum, one of the co-creators published a book called “Scrum: How to do twice the work in half the time”. If that’s not a sign that the primary goal of these frameworks is to work harder, faster, then I don’t know what is xD
But yes, all views are welcome!

4 Likes

Hmmm…I still don’t think productivity is the ONLY goal for even Scrum and Kanban. The point of this thread is to see which framework has inherent methods in place to assure (at least to some extent) that human well-being is taken care of - some Scrum practitioners commented that by the way the team agrees for the work load, it is assured, and in Kanban, WIP exists, and the pull method assures that people don’t take more than they can, thus preventing burnout. But everyone agrees that organisations are pushing for more work than they can handle.

This is kind of summary of what’s gathered so far.

1 Like

It’s one of the reasons I like Modern Agile - https://modernagile.org/ It has four guiding principles:

  • Make People Awesome
  • Make Safety a Prerequisite
  • Experiment & Learn Rapidly
  • Deliver Value Continuously

The “People” in the first principle includes the people building the software, so two out of the four principles cover taking care of your well-being.

Unfortunately, Modern Agile is quite a different thing from methodologies like Scrum or Kanban, so you can’t use it instead of those two.

7 Likes

I like that, I’d not heard of it before.

I have always said that in software development that it is always about people, we break things, we make things, we block things, we unlock things etc.

Will read up on it now and feedback into my team, thanks for the share!!

4 Likes

A digression - Have you read this book? If yes, then did you like it?

1 Like

I’ve made a note of this. Looks interesting! I haven’t come across it before. Thanks for sharing.

1 Like

I like it too! Gonna check it out!

1 Like

Modern Agile is new to me too, I will take a look, thanks.

I’m also going to throw Agnostic Agile into the ring here…

It is all too easy for an organisation to dismiss agile ways of working because they can’t fit a specific framework into their organisation. But why limit yourself to a single framework?

Experiment to discover what works for your team and incorporate that into your working practices. Take guidance from frameworks by all means, but don’t feel restricted to one.

e.g. Set a Kanban style WIP limit for your teams but follow Sprint planning for delivery. Work out for yourself how this work on the ground.

The agile manifesto does not dictate a framework, just a set of best practices. Agnostic Agile embraces this.

4 Likes

I have come across methods like Kanplan and Scrumban. :slight_smile:

1 Like

While we are it, @conorfi is doing a talk on Jan 22nd at
Ministry Of Testing, Bangalore, on Kanban! It’s a great
opportunity to ask him about human well-being in Kanban!

Register here:

2 Likes

Team using both scrum and Kanban should work at a sustainable pace. Both scrum and Kanban limit work in progress. Scrum does this by preventing work being added to a sprint once it has started. Kanban has limiting work in progress as one it’s core features. If members of teams are being burned out then there is something wrong with the way scrum and Kanban have been implemented. How to implement lean and agile are things that teams often struggle with. I have found that going back and looking at the work of W. Edwards Deming is a great help, and I am planning to submit a talk on Deming to the next Test Bash.

1 Like

I read a lot of great comments here about process, techniques, and principles, most of which can certainly help avoid burnout. But in my experience, the biggest problem is one of responsibility, not the chosen framework.

In most organizations, whether they follow Scrum, Kanban, Scrumban, or whatever, I’m sure you’ll find that testers are responsible for verifying that the acceptance criteria of a ticket are met by a developer’s changes. Of course if a tester finds that some criteria hasn’t been met, they should bring it up. But very few organizations challenge the idea that testers are responsible for telling the programmers that they made what was asked of them.

@testervenkat mentioned the Toyota production system, which details a “pull” system, also baked “Kanban”, where new work can not enter a given process until the currently processing piece of work is 100% complete. The problem is that most organization operate as if verification of work is a separate process, when it should be the same (Toyota even has a Kanban rule saying “processes must not send out defective items”). They also tend to operate as though the automation of verification is a separate process, despite the fact that all previously committed work must remain complete in order for new work to be considered complete (although that seems to be unique to software).

When the process is a sequence of stages that are viewed as separate processes themselves, with a different person handling each one, you get waterfall. When everyone is trying to move as quickly as possible, they’re likely going to get sloppy when they can trust that a person downstream from them will tell them when they miss even the most obvious things, because they can treat it like it’s a new piece of work (rather than the wasted work it represents). Those upstream will inherently have more power than those downstream, and those downstream are more likely to burnout (or at least burnout faster) because of it. This is especially the case, when a stage is inherently more complex than the one before it (testing, when done by another person, at a higher level scope than development, is inherently more complex than the development, and that’s not necessarily a good thing).

Neither Scrum, nor Kanban can take care of your well-being if executed poorly/improperly. They’re both commonly executed with verification being handed off to someone else and treated differently, which makes it more wasteful, time consuming, vulnerable to confounders, and potentially creates harmful power dynamics. From what I can see, testers are at far greater risk of burnout when placed at the end of this sequence, whether it’s per ticket, sprint, or in general.

Also, if it helps, here’s a simulation I did regarding the sustainability of these kinds of systems. It might be useful/helpful to have/see some numbers and graphs.

1 Like

This brings us one more perspective that whoever writes the code should test it, to put in a nutshell. I guess this is an extension of thinking of T-shaped team which has multi-talented team members - like developers can test, testers can write code, etc.

Testing, even in the SDLC, is not about pushing testing to the fag-end of the product development. Even in 1990s, testing included reviewing and analyzing requirements, taking part in functional and design specification reviews (sometimes even in code walkthroughs), testing (including automation), and post-release production support. So, it is not correct to say that testing is at the rear-end. This is “testing-everywhere” as it is called today (@danashby et. al).

Having said that, what proof do we have that ‘testing at the fag-end’ is the real cause of burn-out of testers?

Also, it’s better not to fantasise developers doing the testing (however lucrative it may sound in terms cutting down the team size and saving a few engineers), thinking that the same developer who wrote the code should test. It is not going to happen because developers already are busy with their architecture, design, code, programming languages, frameworks, and the related head-aches that accompany the constant changes in these. So, they won’t be motivated to do testing also, which is a full-time activity in itself in tester’s mindset (yeah, you could learn it, but you won’t have time to do it).

I am not against T-shaped team, but I wonder, are you asking the developers to learn UI/UX, product management, ops. related to release, etc.? Aren’t they not part of ‘product development’? Why only target testing?

I have said it in the past, and I’ll say it again. The term ‘development team’ in Agile has to be changed to ‘product team’, so that all these misconceptions about ‘developers being able to do anything’ can be gotten rid of.

1 Like

I’m not suggesting having the developers do all forms of testing. I’m also not suggesting that they learn how to tell if something is of value to the customer (although, that is something they should be concerned with, as mentioned as the fifth ideal in The Unicorn Project). They don’t need to know how to do UI/UX design, or set up a k8s cluster (although Spotify has a culture of making it easier for developers to do things like deploy an environment themselves).

I’m just suggesting that they write the automated checks for the acceptance criteria of each ticket they take on, whether that be done at the unit, component, integration, end-to-end, or UI level. I’m suggesting that they figure out whether or not they built what was asked of them through automated checks. That is not all there is to testing, though (but that’s another conversation).

Writing those checks themselves, at all relevant levels, is essential for maintaining internal software quality, and is a very effective way of designing the code and systems in and of itself. If they don’t do it, the internal quality will suffer, which will inevitably slow down development by creating even more headaches from messy code or problematic system design.

(I’d put a link to Martin Fowler’s post on “Is Quality Worth It?” here, but can only include 2 links)

The developers are already thinking about how to verify their work as they’re writing it anyway. They ask most of the same questions testers might be asking to verify a ticket’s requirements (at least at face value). They need to be asking those questions in order to figure out what the code and systems should be. They would only need to write those questions down as automated checks. The difference though, is that this would be very easy and quick to do with well designed code and systems, as most of those questions can be broken down into very atomic questions that can be handled at the unit/component level, with very few needing to be done at higher level scopes.

When the developers are responsible for writing those checks, they will find the motivation to write them and most of the headaches tend to go away. They will invest in making the code and systems be better designed so that writing the checks becomes easier (at least, if given the time by management). When they do this, velocity improves because working with the code and systems becomes easier.

The testers don’t become unnecessary when this happens. They’re just freed up to focus on more hidden bugs, or other threats to the value of the product (or even opportunities for value to be added).

This is by no means a fantasy, and if you’re curious to see an example of this in action, Atlassian has some nice write-ups about why they operate this way, how they transitioned, and what role testers play in their current development practices.

I’m also not trying to say that this is the one true cause of burnout. But because testers have little or no power in a waterfall system, and have to do work that is usually more time consuming then either the development or planning, they will inevitably be forced to make hard decisions about what they have time to verify or how well they verify things. They will also be highly encouraged to work overtime, or through meetings, or on their time off, because if something gets passed them and into production, the question asked is often “how did this get passed QA?” which implies that the testers are at fault.

Of course, if management doesn’t want to allow this to happen, then it won’t. But if it doesn’t happen, it’s unlikely burnout will ever be avoided, because there will always be an unfair imbalance in power that discourages those downstream from telling those upstream “no”.

1 Like

I will go through the Atlassian write-ups.

It’s not true that “testers have little or no power in a waterfall system”. Not true at all. I have led several test teams in SDLC where my views were respected, and we had the say on whether the product was ready to ship. I don’t know where and how your perspective was formed.

2 Likes

Great that you’ve had such a positive experience with waterfall @testervenkat. Unfortunately my own experience on several such projects does not mirror yours and I’d have to say when I was on waterfall projects, it’s very true that the test team had little or no power in the waterfall system.

2 Likes

That’s awesome! It sounds like you have a really healthy, strong culture where you work.

To clarify, when I say “little to no power”, I mean systemically. Culture can certainly rise above these kinds of systemic issues, but this is the exception, rather than the norm.

In a “push” waterfall model, it works very much like an asymmetric prisoner’s dilemma. The process itself gives developers no reason to mutually cooperate with the testers, because the testers have no means to “defect” from the developers. It’s not that the developers are malicious. It’s often that they have a means to “defect” (i.e. being less careful/rushing with their work and lean on the tester to find the serious problems), but there’s no mutual defection (i.e. consequences for doing so) to help them understand what they’re doing.

Luckily, it sounds like you have social/cultural structures in place to allow for mutual defection. That is to say, being less careful/rushing and leaning on the tester to catch the problems can cause social/professional consequences for a developer (even though it may not come directly from the testers), which gives them a way to understand when they aren’t mutually cooperating.

1 Like

That’s so sad to hear, @heather_reid . The organisational culture plays an important role in keeping the checks and balances so that everyone’s view is respected and there is a fair play. This is true across all the processes - SDLC or Agile.

1 Like

SDLC or Agile, everyone in the team needs to be mindful of Quality. Quality can be achieved in several ways, not necessarily by just writing test scripts or owning more of the testers’ jobs. Even developers would resist doing tests saying that it is not in their job description. But the testing/assessing mentality should be in-built in everyone irrespective of their job description for the sake of Quality.

Agree to the extent that if developers expand their minds to big picture and think end-to-end rather than focusing their own modules/integration, will yield a lot of in terms of Quality. In this aspect, testers could teach developers how to do it.

1 Like