5 simple tips on starting a new scrum team

As many companies within the IT industry move away from Waterfall/PRINCE 2 and more towards Agile/scrum, it can be hard for project managers and scrum teams to know what the best approaches are for a new scrum team.

There is a lot of information online that provides information about what scrum is, what tools are available, and what the scrum process is. I have worked in the digital/ IT industry as project manager/ business analyst since 2005 and have worked with scrum since joining Inviqa at the start of February 2014. The transition has been a steep learning curve and in this article I will share some of the practices I have learnt to improve scrum team efficiency.

(Before anyone points out that the project management role doesn’t exist within scrum, most project managers now adopt the scrum master role, so the following tips are applicable for all of your team!)

1. Establish individual members expectations

Depending on the size of the organisation in which you are practising scrum, the team members may never have worked with each other before. If you find yourself in this situation as a scrum master, it is good to establish the experience and capability within your team.

I’d suggest doing this by having either:

• A group meeting (with all members of the cross-functional team)
• Individual sessions with each person (this could be just the scrum master or technical team lead and team member)

In the meeting(s) you need to establish how each team member is used to working and also re-confirm the expectations of their duties (see ‘provide boundaries’ below).

If your team consists of three backends, two frontends, a tester, and a TTL, all roles are covered within the team. However, if you expect them to pick up tickets that aren’t their assigned role without communicating this you may be in trouble. 

For example, if you expect all team members to test tickets they haven’t worked on, but have not communicated this effectively, you may find tickets far from ‘done’ at the end of the sprint.

If you’re in the development team, you don’t have to wait for the scrum master to establish this. If you have a preferred way of working, put it forward…it may be something that the team prefer or are willing to try. Any suggestions for improved working will always be welcome!

Ensure you have the same conversation with the product owner. If your product owner doesn't know what you are expecting from them, you're unlikely to have a functional sprint.

2. Provide boundaries

The amount of guidance required will depend on the team, but it’s essential to ensure that everyone has the same expectations and boundaries have been clearly defined.  

This could be as simple as: For all daily scrums the team must stand up and turn on their camera.

This may seem like overkill, but believe me it's not. I once had a developer tell a client in a daily scrum that they had achieved nothing the previous day, which sounded like they had done nothing all day on the client’s budget.

When I followed up afterwards, it turned out what they actually meant was their task was bigger than thought so it wasn’t finished as expected. What should have been said was:

Yesterday I worked on X. After starting the task it turns out it was larger than expected and I didn't complete it. My new estimate for it is Y. This means that there is a difference of Z.

The team member in question had taken the Agile materials they had read too literally. Because the task wasn’t completed within the estimate, the developer deemed it a non-achievement. Ensuring that expectations are matched across the team, and the team fully agrees what is defined as ‘done’ or ‘achieved’ will avoid issues later in the sprint.

3. Enable the team to self-organise

This goes hand in hand with point 2 above. Simply having a scrum team without guidance and expecting the team to self-organise may work out in the end, but will most likely be inefficient and waste client budget.

Having a cross-functional scrum team means that the skills to complete the project are within the team. Allow them to use that knowledge and trust them to make their own decisions.

Don’t tell them exactly what to work on. If a team member is asking what to pick up next, answer with 'The stories are in priority order; the focus should be to get each story done' rather than 'Please look at ticket x'. You will get the same result, but the team member will feel like are involved in the decision.

There are some exceptions to this. For instance, if there is a known blocker, you may choose to give the ticket number to ensure that it is picked up, but this should be an exception. If the team are communicating effectively, the team member will be aware of the blocker ticket anyway and would pick it up without being told. Whatever happens, ensure you give them the tools they need to help themselves.

There have been a few instances where I have had to miss the meeting day (which consists of demo, retrospective, and planning), leaving my team without a scrum master / facilitator. If the team are truly self-organising, they should be able to carry on without a Scrum Master if they have been given enough information to do so.

Retrospective: Ask for a volunteer to run the session and provide them with options for format. Don't just nominate who you think should do it.

Planning: Let them know the team capacity and what you would normally recommend committing to based upon that capacity. Give them any calculations you use to determine this.

Simply having a scrum team without guidance and expecting the team to self organise my work out in the end, but will most likely be inefficient and waste client budget.

4. Provide channels for direct communication with the product owner

One of the first things that you should do it remove yourself as an information gatekeeper.

Enable the project team to communicate with the client and make decisions without your involvement. If all information needs to be via one person, that person can become a blocker to progress.

Setting up a group channel on a direct messaging system such as Slack or Skype allows a team member to ask you a question. You should encourage them to contact the client directly via the agreed avenue. You can monitor the progress, without being directly involved. It is important to get the team to communicate with the client in the group channel and not a direct message, so the whole team can see the communication and can offer advice if needed.

5. Don’t commit to work on the team’s behalf

A big part of scrum is team ownership and enabling your team to commit to completing all stories taken into the sprint.

If they aren’t consulted about what they believe they can achieve and the discussion is pushed on them, your team will be less likely to agree with it and the commitment may not be achievable, which will result in an incomplete sprint.

In order for the team to take ownership they must make the commitment as a team. I use the follow calculation to work out to how much my team can commit:

Team capacity - (minus) meetings - training/holidays - x for bugs - contingency  = commitment capacity

This would give you the amount of hours the team should be committing to, but this is very much a team decision. If you have calculated a commitment number and the team have said they want to commit to a few hours more, you should flag any concerns you have, but should go with the team’s decision.  

Following the basics above should help improve efficiency within your scrum team. Setting expectations, providing realistic and helpful boundaries, and trusting your team members to do the right thing will help to create a more enjoyable and productive team.