Ben Barden

Product management and process tips

by

New music: Night Sessions

I’m moving to a new flat on Monday, so I’m quite busy packing and preparing for the move.

Instead of the usual blog post, this week I’d like to share some music I’ve written, which went up on streaming sites this morning. It’s an EP of six tracks, titled “Night Sessions” and written under the name “GFD”.

Here’s the Spotify album:

https://open.spotify.com/embed/album/04eiQOEeJZiOThpRyjm60w

Night Sessions is also available on Apple Music, Amazon Music, Google Play / YouTube Music, Tidal, Shazam, 7digital, and Deezer.

Have a listen — you might find something you like.

Thanks, and see you on the other side!

by

Getting things done

One of the first things I learned in Scrum is the importance of a task being “Done”. In short, until something is done, you don’t get the value.

Getting a task to “Done” might not be as simple as someone picking it up and doing it. Sometimes, it’s good for members of a team to pair up and work on a task together.

Developers might have enough knowledge of the task and the system they’re working with to code it on their own — but they’re going to need someone else to review it.

Unfortunately, what I’ve seen happen all too often is that there isn’t any slack in the team. The mindset seems to be that if we have 5 or 6 developers, we can give them 5 or 6 totally distinct tasks. What do you do if a developer needs to ask someone for help? Or if their code is ready for review, but everyone is busy on other things?

By focusing on too many things at once, and treating everyone as a “resource” that can have 100% of their time assigned to a different task to the rest of the team, what happens is you end up with a lot of things that are partway done.

Instead of having as many balls in the air as you have people, it’s better to get the team to focus on a smaller number of tasks and see them through to completion. That way, you will be steadily delivering things, instead of running into the issue where it seems that nothing is coming out of the team — until suddenly, a bunch of things all land at the same time.

Are you always busy?

This approach can also benefit anyone who keeps talking about how busy they are. Being too busy should not be seen as a trophy — it can mean you’re overloaded and stressed out.

If a task is on your to-do list for too long, and more tasks are being added to your list all the time, you can quickly feel overburdened.

To avoid this, try to limit the number of things you have in progress at any one time. You can do this by focusing on getting things done.

It can be very rewarding to finish a task. It doesn’t mean you can’t add to something in future — it just means you’re marking the task as complete. Make sure each task has a clear goal, so you know what “done” looks like.

By focusing on getting things done, you can start working through your backlog, stop feeling so busy, and finish more things!

Further reading: https://www.inc.com/wanda-thibodeaux/the-real-reason-unfinished-jobs-stress-you-out-according-to-psychology.html

In 2021, I’m trying to write more regularly on my blog – hopefully one post per week. See my progress so far here: Weekly blogging in 2021

by

A few things I’ve learned about software testing

My first tech job was at a large insurance company, in an IT department of 60 people. I started as a trainee developer, and slowly started learning software development.

After a number of years, I noticed an internal vacancy for a test manager*. I remember reading the job spec and thinking, wow, this sounds like something I’d be interested to try. I showed an interest, but my line manager steered me away, saying he thought I should focus on continuing to build on my development skills.

However, a few weeks later, management discussed the role, and it sounded like most of the group was keen on allowing me to move into this position — despite my manager still being unsure. So, I got started.

*A few people were hesitant about giving out a “manager” title. I ended up being “System Test Coordinator”.

What is the purpose of testing?

As part of my test manager role, I attended two training courses. First, the ISEB Foundation in Software Testing. Second, an in-house test management course at head office. The second was fairly boring and I didn’t remember much of it once I returned to my normal workplace. However, the first gave me a qualification, and some genuinely useful things to take back to work.

In the ISEB course, the instructor opened by asking:

What is the purpose of testing?

Keen to make a good impression, I said “to check it works”. I don’t know if the instructor was hoping for a different answer, or was glad to be able to give the “correct” answer. He went on:

No, the purpose of testing is to find faults.

He explained that it’s a lot easier — or more achievable — to prove when something doesn’t work, than prove it does work. (A side note: this instructor spent a fair bit of time explaining that a fault is not the same as a defect. This is more to do with defect categorisation. In practice, as a tester, I report issues as bugs and allow the developers to determine the cause of those bugs.)

And so this quickly became a line I shared with colleagues: Don’t test to make sure it works — test to find what’s wrong.

Years later, at a weekly Tech department presentation at a different company, the QA manager gave a talk. He asked that question again, or a version of it:

What’s the point of testing?

In his view, it was fine to test to find bugs, or to check it works, or for other reasons.

The description I like best is that as a tester, you are supposed to assess the quality of the product. (Source) This can mean looking beyond the scope of a specific change, and looking for potential side effects.

What does a good bug report look like?

Having worked as a Scrum Master on a couple of occasions, my first instinct is to answer this question by mentioning a Definition of Ready, or to mention using a template. But there’s more to this than how the bug report is structured.

Sure, there are a few things that are helpful to include: a screenshot of the error with an accompanying link, steps to reproduce the issue, expected results and actual results. That’s all well and good. But following that format doesn’t automatically make it a good bug report.

The tester needs to communicate the severity of the issue, so the team can distinguish between the major, moderate, and minor reports, and also any showstoppers.

The tester needs to categorise the issue correctly, depending on the issue tracker or project management tool used. Testers should know the ins and outs of these tools better than anyone.

Where relevant, the tester needs to crosslink related issues in the same area, to illustrate the cumulative impact of “rot” in any part of the system. A small bug might not be worth fixing on its own — but as part of a larger collection of bugs, this can strengthen the case for fixing a whole section of the software.

Above all, the tester should aim to write bug reports that are hard to dispute. From reading the bug report, it should be clear both what the issue is, and also the impact. The bug report should be reproducible: intermittent issues, or things you’ve not yet pinned down to a specific cause, are harder to fix and can waste a developer’s time. Overall, a tester should make sure their bug reports are written with conviction, getting the reader to see why the issue needs fixing, and — ultimately — giving the developers an irrefutable bug to address.

Don’t automate too much

Test automation is a big topic. For some organisations, the holy trail of testing seems to be — automate all of the things! But automation is expensive, and can become a time sink if you’re not careful.

Automation shouldn’t be a blanket statement — and it isn’t a replacement for any and all testing.

There are a few things you can — and should — automate. Unit tests are a key part of test driven development, and are worth writing (by their nature, they are automated). Certain integration tests, regression tests, or “smoke tests” — that is, testing an environment is functional once it’s set up — are all candidates for automation too.

The extent to which you should automate these largely depends on your team size and experience, and your ability to keep up with future changes to the software by similarly keeping the tests updated. Also, consider the time to automate each part of the system, and whether the capabilities of your test tools will make automation possible. Test your test tool first — don’t just plough on with automating everything.

Remember that automation will only test as far as you ask it to. Don’t treat, say, a passing set of unit tests that the software quality is good. Look at expanding coverage of negative tests — don’t only focus on “happy path” testing, aka the “just test it works” mindset.

Don’t try to automate exploratory testing, UI testing, or user acceptance testing. These are best done by a person, not by a computer.

And don’t try to phase out the need for any kind of manual smoke testing or regression testing. Sometimes, a few sanity checks of both the software and of your test scripts can go a long way.

In 2021, I’m trying to write more regularly on my blog – hopefully one post per week. See my progress so far here: Weekly blogging in 2021

by

4 tips to get your in progress column moving

A simple Kanban board has 3 columns: To do, In progress, Done. Tasks in To Do haven’t been picked up yet; In progress shows tasks that are being worked on; Done contains the tasks that have been completed.

If you’re not careful, the “in progress” column can get overwhelming. Here are a few things to watch out for, and some tips to help keep things moving.

1. Set a WIP limit

A WIP (work in progress) limit is a way of setting a maximum number of items that you want to be in progress at the same time. How this is handled varies depending on the tool. Jira displays a red highlight if you go over the WIP limit, but it doesn’t stop you from doing it. Unfortunately, I haven’t found a way to do this in Asana.

The WIP limit is a number, which is often the same as the number of people in the team – sometimes team size plus 1. You can only do one thing at a time, right?

If the In progress column is already full, you could finish the task you’re working on, or help someone else finish theirs.

You don’t get the value from a task until it’s Done, so why not focus on completing things before pulling more into In progress?

2. Identifying blocked tasks

Sometimes a task is picked up that lacks info or starts to become more challenging than expected. If you’ve ever been asked “Any blockers?” then this is the kind of thing I’m talking about.

It’s important to identify blocked tasks on the board. I don’t recommend immediately throwing them back to “To do”, or worse still, a dedicated “Blocked” column. It makes it too easy for them to be forgotten about. Instead, you could use a custom field, you could prefix the title with “BLOCKED”, or you could add a flag to the task (Jira does this nicely).

While it’s not good to hang around waiting for answers when you could be working on something else, switching to another task too quickly could mean you end up having 2 things in progress. When the blocked task becomes unblocked, you’ll need to context-switch and go back to it. So, make sure you mark the task as blocked, and try to unblock it before jumping to another task.

3. Prioritise the things that are closest to being done

Once code has been written and is awaiting review, it’s closer to being done than a brand new task of the same size and complexity.

It might be tempting to get going on the next task, but leaving a lot of things awaiting code review means you’re not seeing the value from the code that’s already been written.

If you keep seeing tasks awaiting code review, or there’s another reason why things are consistently getting “stuck” in the in progress column, there’s another thing you can do.

4. Splitting up the in progress column

Purists will argue that you shouldn’t split up the in progress column. But when it’s getting full and some tasks are sitting there for ages with no movement, it can be helpful to isolate some of the most common sticking points into the own columns.

One way could be to split the column as follows – the four columns in the middle are all a stage within “in progress”:

  • (To do)
  • Development
  • Code review
  • Test
  • Ready to deploy
  • (Done)

The main benefit is you can see much more clearly if a lot of tasks are stacking up in one of these sub-statuses. And if you combine this with a WIP limit, you can steer a team away from picking up a new task as soon as they submit one for code review. The focus becomes more about getting a task fully done and to the end of the process – instead of focusing purely on writing code.

Perhaps you don’t need that level of granularity. However, I’ve seen some teams benefit greatly from this structure – or something similar. You can always adjust it – maybe try adding one more column and see how it goes.

In 2021, I’m trying to write more regularly on my blog – hopefully one post per week. See my progress so far here: Weekly blogging in 2021