I’m definitely regretting the naming choice here. Return of the bad habits? Return of the imposter syndrome? I’m moving past this whole Star Wars naming thing and pretending it never happened.
It’s been a few months since we got rid of the testing columns, and though we are continuing to evolve and solve problems as they come up, I’m going to conclude this series here. If you’re just coming to this page, then you can find the first post here, but it’s not necessary to read the first two.
In mid-November, we decided (after months of thinking about it, influencing, deciding…) to get rid of the testing columns on our kanban board. The primary outcomes we wanted for this were to reduce queuing time for tickets and context switching for developers who would often have to go back to old work to fix bugs while halfway through their next ticket. We also expected that sharing the responsibility for quality across the team would diminish the number of bugs. This is the round-up, essentially!
Benefits
We were pretty sure that taking the queue times away would make us faster. Tickets were being thrown over the wall into “Ready for Testing” and sitting there while I was testing other things, and then subtask bug tickets I created would sit in “To Do” because the developers had already picked up new pieces of work. Unfortunately, we were forced to move our JIRA board to the cloud in an unrelated event, and thus lost our old metrics so I can’t make direct and specific comparisons – but multiple team members have commented that it feels faster, if that helps. xD Work moves through the board without getting stuck in columns, because the people with the ability to fix problems are the ones in charge of them.
Gone are the days of morning standups full of “Uh yeah this one is just waiting on a bugfix, I asked last week. This ticket is also waiting on a bug fix, and these two have just come into testing but I haven’t had time to start them yet because I’m context switching all over the place.” This is pretty much word for word what every standup was for me, and it was painful for everyone else too.
I wasn’t the only one struggling with context switching – we work in small increments and deploy often, but if a release blocking or high priority ticket had a bug then someone would have to drop what they were working on to fix that, and then come back to what they were doing before. This is taxing and time-consuming, especially if it happens multiple times a day or week. Since the developers are now seeing the work through testing and deployment to production before moving on to something else, they don’t have to switch back and forth between tickets.
Having direct handovers – ie having a conversation instead of putting a ticket in a box and then someone else picking it up out of that box – facilitates closer collaboration between roles. For example, while talking with developers (over slack or in person) about problems, we were able to surface minor issues that I wouldn’t have bothered ticketing up before, knowing that the work wouldn’t get done anyway. It also normalises the behaviour of talking directly to people who can solve a problem, instead of waiting for standup to bring up a vague issue that no one will reply to.
Lastly, getting rid of most of the columns on our kanban board made space for us to add others! We have separate design and dev boards, which makes this weird disconnect between the place we make decisions about what work we do and the place we actually do the work. By moving a design column onto the board, we’ve opened up areas of decision making and made upcoming work much clearer.
Sneaky peak at the tops of some of our tickets, just so you can see our crab emoji. We use this to signify tickets that will be paired/thaired on in design. Our team designer works directly with a developer while creating prototypes or new features. This means we don’t end up with situations where developers have to bend over backwards to fit a specific solution to a problem, and can pair with the designer to come up with the solution/s that work best for everyone.
Problems
There were and are many, but the degree to which each is actually a problem depends on who you talk to.
For me, I find it problematic that our testing for each ticket still happens primarily at the end of development. We have a direct handover, but it’s still waterfall-y in that the phases are the same. A developer develops, and then a tester tests. I need to do a lot more work at earlier stages, and I know in a big fluffy cloudy way how to do those things – but on any given day, in a specific given moment, I never know exactly the thing I can be doing right then and there. This relates to a much larger issue that I’ve had around getting confirmation and agreement from managers (and thus ‘authority’ of a kind to actually do the things I want to do) about what my job role actually is. This makes it difficult to back up actions I take and things I say, because I’m not actually doing my job – I’m just doing more weird Bruce things on my own initiative with no backing. Orr that’s all an excuse I use to avoid holding myself accountable, who knows!
Regardless of the changes in behaviour I hoped would happen semi-naturally, we did meet the goals we explicitly set so we can treat this as a separate issue. Switching to a more collaborative and conversational way of talking about quality opens doors and readies the soil for plants to grow. It is a step forwards, even if it’s not the entire staircase. Sorry, I keep trying to write this in a non-metaphor and then writing a different metaphor instead.
The change has also revealed the severity of two big issues we always had but feel more keenly now.
Firstly, the lack of meaningful automated test coverage. We have bits and bobs here or there, but I would be ashamed even to attempt to put a figure on it. I’d really like to push for trying Test-Driven Development, and am in the process of feeling out individual developers’ views about it so I can do some sneaky influencing on a 1-1 basis (not so sneaky because everyone knows about my blog). So far, it’s mostly been me learning and doing my best; writing and revising a strategy for automation, and attempting to put the basics into place while grabbing help from the developers when I get stuck. I’m really very glad to have the team I do, because I know I can ask for help and find it.
The second issue revealed is a big ol’ bottleneck in UAT. We used to have a bottleneck in testing, which is gone now and I have SO MUCH time to do the things mentioned in the above paragraph. The testing bottleneck was acting as a sort of buffer between development and UAT though, to stop them from getting overwhelmed with twenty million tickets all at once. The faster the rest of the board goes, the worse the pile-up in UAT gets, because the Client Services team haven’t got the capacity to do this activity every single day. We’ve been pretty lucky so far (or unlucky, depending on how you look at it) because some project kick-offs have been delayed and so we’re actually running perpetually close to the bottom of the work available for engineering. Once the kick-offs happen, there will be a big flurry of activity as the pace picks up, and we need to work out how to deal with UAT.
Factors that helped
This change has been an overall success for us so far, but I’m not by any means saying that it would work for every team or every organisation. So here are some factors that contributed to making it work, including behaviours that already existed, team structure, and the extra bits we did on top of that.
As a tester, I was already part of the development team, working closely with them from day to day. I’m not part of a separate testing team, I’m just… an engineer, sort of. I’ve done bits and pieces of engineering work, I understand the structure of our projects and the interactions that happen inside, between and outside of them. I have approximate knowledge of many things. The developers are friends who I play tabletop- and video games with, and one of them is my housemate. I mean, you don’t need to take it that far to have good comms, but the point is that dev and test were already socially integrated before we began. There was no “us v them” mentality between separate teams, we have always been solving problems together. I can’t stress how much this helps, and how much it hurts to have knowledge and skills siloed in different teams.
Secondly, the team lead/manager (I’m not sure what his official job title is, if he has one – we have a fairly flat team structure) was keen, and then we got buy-in from the developers. I think getting buy-in for an idea is a massive topic in itself and I want to keep this short, so the biggest single factor in my opinion was thus: the change was framed in ways that would benefit the entire team. The goals were set so that they would benefit the people who would need to change their behaviours. For example, if I had gone into a meeting and said “I want to make this change because it will give me more time to work on automation and other things around quality which will tots benefit you but not super directly” then everyone would have agreed it was a great idea, and proceeded to do nothing about it.
Going into the talks and saying “hey I’m always hearing you talking about how annoying context switching is, and I heard you. I get it, and I think I have something that might help, while helping me too” was always going to get better results. This isn’t because of malice or uncaring on anyone else’s part. It’s just harder to make a big change to the way you’ve been working for years if you don’t feel any benefit from it. Change can be difficult, and we all need good solid reasons to do it.
Another big factor was that we had meetings about it beforehand. Yes, I know: meetings. I love ’em. I suppose when I say we had meetings about it, I mean we had structured, time-boxed discussions with clear goals in mind. Everyone knew what they were doing there and why, and what we wanted to get out of it. Therefore we got something out of it.
My feelings
Wouldn’t be a Brucey blog without putting my feelings in, so here they are!
I am so happy we did this, genuinely. I have cried, I have lost control, I have felt lost and helpless and wondered why I’m even here because I can’t feel the value I add to the team as directly as I did when I was just testing the next piece of work under my nose and then clicking the deploy button. But I’m glad we did it. It’s weird talking about it now like it was some big event because it kind of wasn’t, and this has become the normal way we work. Not exciting at all anymore, and I continue to feel lost a lot. xD
I’m also writing as if this is done and dusted, but there is no done. There is no end to this quest – if there was, it would be a very boring quest indeed. We’re already working on the next steps, the next big changes, possibly an organisation shake-up to help our separate dev teams work more closely together. I’m just a software tester at the bottom of the decision chain when it comes to these things, but I hope that talking about changes, my influence and part in them, will help me learn and strengthen my understanding of leading and creating change.
And maybe in six months or a year, I will look back over these posts (as I now do with my older ones) and I will think DANG, BRUCE HOW DID YOU SPEND THAT ENTIRE TIME THINKING YOU WERE A USELESS PILE OF RUBBISH?! And future-Bruce, who will inevitably still believe that they are a useless pile of rubbish, will have reason to think that they’re maybe not so pants after all.
I say future-Bruce because I’m not ready to think that yet so I’m kicking the can down the road JUST LIKE YOU ALWAYS DO, BRUCE, YOU USELESS PILE OF RUBBISH, YOU!
Undeveloped Bruce 