Hi everyone and welcome to our Scrum focused series of articles, where we share our experience of implementing Agile practices in various organisations. 

This article will discuss a Scrum event – Daily Scrum, or as we called it before, Daily stand-up. We will take a little bit of a different take on it. We will not explain what Daily Scrum is but how to conduct a Daily Scrum with a remote team.

One of the Manifesto principles for Agile Software Development is that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation”. Most teams who adopt any Agile frameworks or methods use a short daily communication session to help the team collaborate and plan as a collective unit. In Scrum, there is a specific event for this called the Daily Scrum. It is usually held at the same time and in the same place each day around the team's Scrum board.

If the team uses a physical board with some team members working remotely, it can be very difficult to have equal participation from everyone in the team. Due to more people working remotely, we had to come up with a different approach to the daily scrum.

We have tried to use a phone, phone with the speaker to include remote members in the discussion, but we did not eliminate one major thing, and that is that people working remotely could not see the tickets on a physical board. We had to read the tickets out, and the people working remotely had to tell us what to do with the tickets. Also, it was more difficult for a remote team member to choose what to work on next.

We had to find a different solution. We started using a virtual board where remote team members could see tickets, their descriptions, and actively participate in the event. The team members in the office continued to use the physical board. However, we have encountered another issue. Team standing around the physical board had a different view of the work than people looking at the virtual board as we were updating the physical board during the Daily Scrum and not a virtual board. After the Daily Scrum team members would hang around to discuss any item in more detail and potentially replan some items, this often meant that the physical and virtual boards were out of sync and still confusing for those people working remotely. 

Finally, we decided that we should all look at the same view and update one board only to eliminate any misunderstanding and double handling. 

We had to use a virtual board and other electronic tools to help us connect team members and give each other updates on what we are working on. 

Before we dive into the discussion around dealing with remote teams just a quick recap on what Daily Scrum is.

Just a quick definition from the Scrum Guide:

Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronise activities and create a plan for the next 24 hours.

Ideally, it is held at the same time and the same place every day as this will reduce complexity and help reinforce the event. 

Also, it is easy for all team members to remember when and where teams synchronise their work. (*)

 

What is the Daily Scrum for?

It is a short session where the development team collaborates to inspect the work completed since the last daily scrum and forecast the next work in the sprint backlog. (*) As part of keeping the session timeboxed, it's crucial to make sure that any detailed discussions are held after the daily scrum. Team members can stay on after the daily scrum to work through any items and potentially replan or clarify anything that is needed. 

 

And how does a development team synchronise on a Daily Scrum?

They simply answer the following three questions: (*)

  1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
  2. What will I do today to help the Development Team meet the Sprint Goal?
  3. Do I see any impediment that prevents the Development Team or me from achieving the Sprint Goal? 

 

What tools can help to connect remote team?

So how can you do this with a remote team? And what tools can help us?

Let us remind ourselves what is the best communication media if you can't meet face to face?

 

 

Even if the research was done in 2002, and information is 18 years old, it is still relevant. Well, mostly relevant as we aren't using videotape and audiotape these days. 

As you can see from the diagram, the best way to communicate with your colleagues is face to face. As this is not possible with remote team members, we need to use the next level of communication, video conferencing. 

 

We have a few tools available that can help us with that.

  • We can use ZoomWebexMicrosoft Teams, Slack, Google Hangouts or Skype for video communication along with chat rooms. 
  • If necessary, we can use email for indirect contact, or as a confirmation of our previous conversations and actions.

 

For visualisation of Scrum board, we also have few options.

  • We can use either Jira, Trello, Rally, Asana or Microsoft DevOps. 

 

 

 

I know, there are more tools available, but those are tools that are widely used.

We are going to assume you already have your product backlog and Sprint backlog sorted. If you want to know more about how to create your backlog, or how to select your work for a Sprint, you can watch our videos on those topics.

Ok, but back to Daily Scrum. 

There are two schools of thoughts on how to run daily Scrum regardless of if it’s online or with a physical board. It is all about time for updating our progress on a Scrum board.

Number 1. Each team member will update the board immediately after they finish their task. We will save some time from the Daily Scrum session, but also we have to be a little bit more disciplined to remember, what we have finished and what we have picked up to work on and update other team members on the current state of development.

And number 2. Each team member will update their tasks during the Daily Scrum. This will obviously take a little bit longer. However, it is valuable for all team members to present and see everyday progress made by the team towards the Sprint goal.

From our perspective, both approaches are ok as long as they work for the development team. A team can use even a combination of both of them. Most of the time it is enough to update the board once a day, however, sometimes it is necessary to see progress continuously during a day as there may be a need to make a swift decision quickly. So it is dependent on the situation and team which approach they choose.

So how would we handle it with the remote team?

 

Hosting and Facilitating Online Daily Scrum

Before we embark on an electronic tools journey, and you and your team start your first virtual Daily Scrum, you should agree on who is going to host the session. And most likely, also share the screen with your electronic board for everyone during the session. 

The host of the session should be adequately set up for hosting of the session. From a hardware perspective, it is ideal to have at least two screens available as this will allow you to share one screen with your virtual board, and have a second screen available for note-taking and video system controls. This will make sure that your system controls and potentially other applications are not obscuring the view of the board for the rest of the team.

 The person hosting the meeting should schedule it as a recurring meeting at the same time and the same virtual meeting room. This makes it simple for all team members.

Often, it will be a Scrum Master who will schedule sessions and share the screen so everybody can concentrate on their contribution to progress towards the sprint goal. Still, it can be anyone as long as it does not interfere with the running of the session. 

Whoever is the host and presenter for your daily Scrum will have some privileges and responsibilities that a video conferencing system will give them to assure the session runs as smoothly as possible. 

As a facilitator, you may need to ask those who are not talking to mute their microphones to cut down background noise. On most video conferencing applications, you do have an ability to “mute” individuals or all attendees if there is a noise during the session.

As the facilitator, it is also handy to see who is participating in case there is a specific question or finding out who is missing.

There are a few things you can also do. 

  • If you are sharing the screen, it is a good practice to display a Sprint burndown chart at the beginning of the Daily Scrum session to quickly assess where we are in our effort towards the Sprint goal.
  • During the meeting, the facilitator can help a reporting team member to move their tasks to the appropriate column on the board. That will result in an updated Scrum board on the end of the session.

As we assume that a Scrum Master is sharing the screen and updating board, he or she should also capture any discussion points to remind everybody if there needs to be additional discussion on those points after the Daily Scrum.

Attendees

As a team member

  • You should be mindful of other team members and mute your microphone if you are not speaking. It will minimise a noise level for everyone else
  • make sure you give a full update on your progress and impediments if any (as learning for others - short story)
  • pay attention to other team members as you may be able to help them if they are struggling with their tasks.

 

Running Session

Facilitator to initiate a session

The best practice is to start the meeting a few minutes earlier to enable people to join on time and adjust their audio/video settings if necessary. 

 

Share the electronic board with attendees. 

As mentioned before, we have a habit of showing a daily burndown chart at the beginning of the session as an overall view on the team's progress. 

 

This will create an equal understanding of the team progress through the Sprint backlog. And potentially ignite the first ideas of any possible adjustments that will be needed to be discussed after the session.

After that, we go through each team member and answer the three questions. Facilitator of the session will move each ticket according to the answers to the questions. 

In Jira, we are using quick filters set for each team member, to simplify the view and minimise the scrolling through the screen.

Each team member is answering the same three questions as we have mentioned before focusing on displayed tasks.

We have a simple rule for team members reporting - if it is not on the board, you should not be working on it. If anything is identified like this, the team members will discuss the items after the session.

As we usually can't see the entire Sprint backlog on the screen (unless you have an enormous screen at home :)), it is beneficial for each member to have a view of what is next available to work on so we don't have to debate it during the session.  

Very often, we hear that stand-ups are not allowing for the discussion between team members. It is especially true in non-software teams. Those teams, new to Scrum, are often used to having a prolonged conversation to go through the options and agree on the final solution. We absolutely want to support discussion, especially as we have all people together at the same time. Ideally, you will have a conversation with people interested in it and not hold others to listen to it if they can be more productive, so we are encouraging people to have a discussion at the end of the daily scrum event. After all team members finish answering the three questions, the scrum master can ask who is interested in the noted discussion points and let other people go to focus on their work.

So this was our take on the daily Scrum with the remote team members. It does work for our teams, but it is not the only way to run it. We would be happy to hear your experience with the remote Agile teams. Also, let us know what other topics you would like us to discuss.

 

Attending a product owner training is only one of the steps you can take to help become an effective agile Product Owner. It is essential that the Product Owner (PO) has a good understanding of the company strategy, goals, market, your customers and their goals along with your development team capacity and skillset.

The role of the product owner is one of the three roles described in the Scrum Guide and in the Scrum Primer. The Product Owner has a significant role also in agile scaling frameworks. The PO holds and explains the vision, is responsible for maximising the value of the product and the work of the Development team. Product owner is also the sole person responsible for managing the Product Backlog. These factors make it a critical role to success of the project and organisation

 

In our career as agile consultants we have met experienced product owners and also product owners that were pushed to the position without proper training and we have helped them to become successful in their role but when we look back we can summarise 10 characteristics of all successful and effective product owners.

 

  1. Focus on delivering value – The main responsibility of product owner is not product delivery but value delivery for both the business and customers. Effective Product owners understand that they are not managing the product as much as they are managing the problem the product solves for their customers. With this in mind the PO knows that the value can only be delivered when the end user will clearly benefit in changing their habits and will also benefit the company.
    An effective PO will focus on delivering only what is required to achieve the desired outcome.
  2. Promotion and Sharing product vision – PO can spend a lot of time to develop the greatest product vision and alignment with company strategy. Such a vision has to be shared not only with a company management but also with the development team to create common understanding and ensure transparency.

An effective product owner should help create user stories that support the vision how the product will make the life of the customers easier and align with the company strategy.

  1. Keep focus on the vision – Your product vision is a destination that you set and share. Every decision that an effective product owner makes should be in support of this vision.
    The objective is not to unnecessarily change the vision as that would mean that entire development effort would have to be re-focused and aligned with new goals.
    If for whatever reason development diverges from the original vision, it is the product owners job to bring it back on track.
  2. Trust in a product development team – It means to trust intelligence of many. Experienced Product Owners understand what role they play in the team. The PO doesn’t have to have the best idea on how to develop the product but they do have to understand what issue the customer has that needs to be addressed. They should trust the development team to find the best solution to fulfil that obligation to the customer.
  3. Not everything will go to plan – We are people and people make mistakes. So an experienced PO would not be surprised when this occurs. There is no shame in failure if you learn from it. Instead, PO should help the team to focus on speedy resolution and removing any possible roadblocks that may occur. However, one of the best ways to avoid unnecessary mistakes in the future is to learn from one that already happened. An effective PO knows that this is not a blame game rather an opportunity to improve overall team performance and improve quality of product development for now and for the future.

 

  1. Never forget to give credit where credit is due – As an experienced product owner it is very important to make sure that all people involved in the product development understand your appreciation for their hard work. With never ending requests, new features, and other additional product backlog management you can’t forget to praise people for their effort. We have to understand that our work force is voluntary and they can leave any time they want. Due to that fact it is really important they feel appreciated for the effort they put in a development of a product.

 

  1. Never rely on written user stories alone – An effective product owner understands that no product backlog is perfect right from beginning and it will change and it will be re-prioritised and updated. Even with this in mind, people will misinterpret stories. The purpose of the story is to engage people in a discussion around an issue we are addressing for our customer. Not every detail will be written down and the story will be updated as we discuss details of the issue and appropriate solution.
  2. Collaboration, trust and delegation – Effective PO understand that even if the responsibility for the product success lay on their shoulders, they are not alone and they can't know everything. They have an entire team to work with and consequently there may be somebody more suitable to address a particular issue. The PO works closely together with a Scrum Master to bring everybody together and facilitate discussion to address the issue in hand.

Both stakeholders and/or product owner is not the fountain of all knowledge. An experienced PO will recognise a gap in the team knowledge and will engage a Subject Matter Expert (SME) to help/augment knowledge of the team to resolve a particular issue they are facing. Ideally SME will be co-located with the team for duration of issue resolution, to assure timely response to any questions from the product development team.

 

  1. Encourage people to have fun – It is well known fact confirmed by scientists from MIT in their experiments about what motivates people. Surprisingly, it is not always money. It is more often challenge and the ability to problem solves an issue for the customer. We know that if people are really motivated they will create some of the most amazing products and share it with everybody else without any payments (e.g. Linux, MySQL etc.)
    An effective PO understands that setting an intellectual challenge for people and letting them resolve it will not only help to deliver the desired outcome but they can also have a fun with it. A friendly and fun environment will motivate people and as a consequence they will be more committed to deliver value for customers and company.

 

  1. Seek frequent feedback – working in an agile environment means that a product will be developed in the iterative way. An effective PO should look for every opportunity to showcase every incremental iteration developed for customers and stakeholders with the aim of seeking feedback. This will assure not only your customer will be familiar with the product but also that the customer is involved all the way through the product development cycle. Your team is receiving feedback and adjusting during the development so the final product is exactly what customers needs.

 

One last thing that as an effective PO you should never forget is that you need to organise your day in a way that you are available to the team as much as possible. Your role is really important to the success of the team as it is you who should answer most of the business related questions, help the team to overcome “show stopers” and other issues that may slow them down in their development effort. We strongly recommend that you co-locate with the team to simplify communication.

We hope that above points will help you in your quest for become a very effective product owner.

Hi everyone and welcome to our Scrum focused series of articles, where we share our experience of implementing Agile practices in various organisations. 

This article will discuss a different way of doing Daily Scrum - walking the board. You can use it with a co-located team or remote team as well.

Walking the board is a fantastic format for Daily Scrum if you want to make sure the team focuses on the most critical stories and their parts first. 

I like to combine two approaches during a Sprint. Usually, I switch the standard three questions format of Daily Scrum to walking the board slightly after the Sprint's midpoint if the team is not entirely sure we are going to complete everything in the Sprint. In this way, we can ensure we are focusing on the highest priority items first.

So what is walking the board?

In our previous video of Daily Scrum with the remote team, the focus was on team members answer the three questions:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I have any impediment that prevents the Development Team or me from achieving the Sprint Goal?

This will enhance team communication, create focus and improve self-management.

In walking the board format, we are going to focus on cards (stories). We assume that your Sprint backlog is ordered by priority from top to bottom, and in that case, your team started to work on the story at the top of the board first as it is the highest priority story for the Sprint.

If this is not true, perhaps a discussion with the team on the importance of priority could improve that.

But if this is how you work, your “walking the board will start from the top right part of your board.

If you ask why from the top-right? What is on top is the most valuable story agreed by the Scrum team during the planning session so our focus should be on those stories. Also, most likely stories on the top of the board, are closest to being finished. Once finished, this may then be used by your customer and result in delivering value for both customer and the team.

Each story that is on the board is typically broken down into smaller parts - tasks. These smaller parts allow the story to be worked on by more than one person and provide a plan for completing the story. Usually, a member of the scrum team will facilitate the session (often the Scrum Master). Each task that is being worked on has been selected by a team member, and they assign their name (ar picture, or an avatar ...) to the task. The facilitator asks the assigned person to explain what was done on the card yesterday, what needs to be done today to move it to do, and any potential obstacle to finishing the task. The facilitator then moves to the next card to the left of the current one until all tickets on a story in progress or about to be worked on have been discussed. The facilitator then moves down to the next story again starting on the far right of the board.

As with any daily scrum, potential discussion points should be moderated. Yes, we are asking questions, but we are after short answers for each ticket.

But what if a ticket requires more discussion? Remember, the daily scrum is not the right place to have an extended debate, but it also is not a discussion killer. You have to consider that not all discussions require the entire team to be present. Other team members may instead go and do some work rather than stand around and listen to other team members if the point debate is not relevant to what they are doing. So a simple solution for that is to have a more extended debate right after the daily scrum. You already have the team available, so why not to use it. We usually use a parking lot (special place on the board) to remember all the discussion points raised during the session. Please, watch our video on how to use the parking lot during the daily scrum to capture and prioritise discussion points after Daily scrum.

We will progress from the top right to bottom left and discuss progress on each card on the board during the session. Well, maybe not each card as we are not working on all stories at the same time. We don’t have to talk about stories we are not working on at that particular time unless there is a specific need.

By walking the board, you are touching every story on the board you need to discuss, and hopefully, all team members have a clear plan for the day and understanding of what the team achieved yesterday.

As I mentioned before, I like to switch to walking the board sometimes after the middle of the Sprint. This gives a team a little bit of a different look at where we are with our effort during the Sprint and identifies stories that may be at risk of not being finished during the Sprint. If we have some stories that we are not confident of finishing during the Sprint, we will have an appropriate discussion with our Product Owner if necessary.

So this is our way to do a daily stand scrum in a little bit different way. It does work for our teams, but it is not the only way to run it. This is also working really well with the remote team and online Scrum board tools. We would be happy to hear about your experience. Also, let us know what other topics you would like us to discuss.