Ben Barden

Products - Projects - Process

You are here: Home / Archives for Agile

Agile

by

How to practise good etiquette in team updates

Many of the teams I’ve worked with have some kind of regular team update – often a daily session.

In the team update, each person in the team talks about how things are going, and they can raise any questions or issues.

These can be really useful but it’s important to steer them a bit. Here are a few tips for how to do that.

How to implement these tips

A team should agree to try a new approach and see if it helps.

Changes should be trialled one or two at a time. If you make a lot of changes in one go, it’s easier for the team to push back purely because it’s more disruptive.

With smaller increments, you can try things out, get used to them, and keep them if they feel like a good change. Then you move to the next change.

Onto the tips…

Timebox the session

The team update shouldn’t be an exhaustive rundown of everything. Long drawn out updates can lead to people switching off. Keeping it high-level will help everyone digest the updates.

15 minutes is a pretty good timebox to use – if you’re using Scrum then this is already how long the Daily Scrum should be.

Nobody wants to prematurely end the session at exactly 15 minutes if someone is speaking. Someone can call out when the time reaches 5, 10, and 15 minutes if it’s useful.

Plus, the change can be gradual – if a team is routinely taking 40 minutes to do their update, getting this to 20 or 30 minutes is a good start.

Nominate the first/next speaker

Giving updates in the same order gets repetitive, and can make people at the end feel that their updates aren’t valued. Varying the order can help with this.

Don’t ask “who wants to go first?” – as this can also lead to the same order every time. The first person to speak could be the first or last to join the update, or they could be nominated.

When a person has given their update, they nominate the next person.

Make sure everyone in the team has a chance to speak – don’t miss anyone out.

Take discussions offline

It’s ok to ask someone a question about their update, but don’t let this take over the whole session.

If it needs a wider discussion, this should be taken offline – i.e. discussed outside of the team update – but it’s important to make sure this happens.

The person asking the question or the person giving the update could arrange a discussion with the relevant people if needed.

Try not to stay on after the session

Whether it’s in-person or virtual, it can be tempting to “stay on” to have the offline discussions there and then.

That can work if there’s only one discussion – but will get messy if there are more.

The risk is that the discussions will feel like they are part of the shorter team update, and may end up being discussed as they come up instead of afterwards.

Plus, people may have other things to do, or they may need a quick break.

Your approach may vary, but my view is it’s best to give people the opportunity to leave the current meeting before getting into further discussions.

Avoid talking in-depth about process

It can be tempting to talk about the team update in the update. After all, you’re doing it there and then, and any thoughts are fresh in your mind.

It’s ok to hear the comments if you have time, and give a quick answer if possible. Anything more and it’s often better to set up a dedicated time so the topic can have sufficient space for consideration.

Refine and conquer

The team may come up with small tweaks to the team update (and other parts of your process) as they get used to it.

Refining the team update as people think of improvements helps to remove pain points and keep things fresh.

Keep doing this as much as you need to.

by

Practical tips for organising your backlog, from my home improvement project

For the last two weeks, I’ve had a bit of a break from blogging while moving into my new home. This week, I’d like to write about taking a backlog of work or ideas and getting them organised and ordered.

However, instead of talking about software projects, I’m going to use my recent move as the example. Since moving in, there’s lots of things I want to with the place — so it makes sense to organise these into some kind of order.

What you need:

  • Post-it notes, Sharpie pens, Whiteboard, whiteboard markers
  • Or, a suitable digital alternative

Step 1: Get the ideas written down

First, we write down everything we want to do.

Grab a stack of post-it notes and a Sharpie (per person) and start writing things down. Stick to one idea per post-it note. Keep the text brief.

You can use online tools to achieve a similar effect — particularly while we are working from home, but also if anyone in your group is working remotely.

With several people involved, you may want to timebox the task to 5–10 minutes, or you’ll have more ideas than you can realistically handle.

Step 2: Review and rank the ideas

First, read all of the items and see if they make sense. Are any of them too broad or too big?

For instance, “electrical work” would be too broad of an idea for the things I’d like to do in my flat. Instead, I can break this down into a few specific things — replace fuse box, add new plug sockets, replace socket covers, replace light fittings, and so on. Or, these could be broken down further — replace light fitting in lounge, replace pull cord in bathroom, replace light switch cover in lounge, and so on.

Look out for any duplicates and stack those together. Then, you can rank the ideas.

There are a few ways to do this. Giving each person 3–6 votes and taking the items with the most votes is fine if you don’t have dependencies, or if there’s not already a natural order — i.e. things that you want to do above anything else — or things you have to do.

You can use “MoSCoW” — i.e. Must have, Should have, Could have, Won’t have — to rank which tasks by order of importance.

Or you could do what I did and simply use High, Medium, or Low.

Step 3: Order the ideas

If you have a lot of ideas, you might not get to all of them yet. Start with the ideas with the most votes, or those that are the highest ranked.

Some things can be done in parallel, while others might have to be done before others — or you might want to push a few important things to the top. In a new home, safety is very important, but then so is heating, which might include replacing the windows, or getting new radiators. An electrician could do lots of small things in one day, but it’s probably better to focus on addressing any potential hazards before making the light switch covers look nicer.

The ranking of ideas will help, but the highest priority ideas might not be the ones you can do first. Replacing the windows in my flat is something I’d like to do right now, but there’s a lead time of a few months. The job is all booked in — but I can do other things in the meantime.

To actually write up the order, I titled up 3 columns on a whiteboard:

  • To do
  • Next up
  • In progress

For each task I’d like to do next, I’ve put them in the “Next up” column, in the order I’d like to do them. As a task gets underway, I move it to the “In progress” column. Other ideas I’d like to do soon, but which aren’t top priority, go into “To do” for the time being.

I’ve decided not to have a “Done” column — instead, when I task is done, I add it to a Google doc that lists out everything I’ve completed so far. And I’ll take the post-it note off the board at this point, freeing up space for other tasks.

You might find you have more tasks than you can fit on the board — and that’s fine — you can set them to one side for now. I’d recommend writing these up somewhere, either keeping them in the backlog of your issue tracker, or keeping a short list documented in Google Docs or Sheets.

Step 4: Keeping the board up to date

In a previous post, I explained that the Agile board should reflect reality. It’s all very well to get things in a nice order, but you need to keep the board up to date, too.

That means:

  • moving things to In progress when work starts;
  • moving things to Next up when space frees up;
  • changing the order of tasks as required;
  • adding more things to the To do column as space frees up.

While you can (and probably will!) do this in digital tools, there is a lot to be said in having a physical board. Moving a post-it between columns can feel good — seriously, try it! — I’d say it feels better than moving things around in something like Asana or Jira.

Having limited space is similar to a WIP limit, but it’s much harder to circumvent when you physically don’t have any more room for post-it notes. I guess you could get a bigger whiteboard — or a second one. I will admit to having just bought my second, although they will be used for different things.

This isn’t a particularly new or groundbreaking process, but keeping my home improvement ideas organised in this way has helped me to feel more on top of them, and to see progress being made. It’s very rewarding, and I’d recommend trying something like this for any project you do — tech or otherwise.

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

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

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