by Liz Sedley

What do I do each day?

When I first became a full time coach the thing I found hardest was knowing what to do each day. After all, running the agile meetings is hardly a full time job. What was I actually meant to do from 9 to 5?

The following section will talk about some of the things I have found to be a good use of my time in my pursuit of creating a great team that produces great software.

Prepare for the Daily Scrum

When I arrive at work the first thing I do is look at the team board. What happened yesterday? Are we on track to deliver at the end of the iteration? Reflect on the board and prepare for the daily scrum. Are there any announcements we want to make? Do we have any questions for the team? Do we need to remind the team of their commitment - and the days left till the end of the sprint?

As the team arrive don't forget to talk to them! How was their evening? How are their family? Did their football team win last night? For some people this is obvious and doesn't need to be said, but other people are more focused on work and forget to do this. Engaging with the team at a friendly and personal level will create a deeper bond, more respect, and also enables us to be aware of personal factors that may be affecting work.

After the daily scrum

After the daily scrum there is more work to do. The burndown chart needs to be updated. We may want to follow up with team members about things that were said in the scrum meeting - or things that weren't said.

Then we need to think about any problems that were raised during the daily scrum. We may need to talk to people to get more information, or enlist help in removing an obstacle or making an improvement.

Were there any things that weren't raised, but that we observed? For instance did we burn down as expected?

Where are we in the iteration lifecycle? If we are nearing the end of the cycle, is the work left to do also small? Are the customer team ready for the next iteration? Do they know what they want?

We should check the build status of the software. Is it building as expected? Have more tests passed today than yesterday?

We should look at the software. Does it run? Does it behave as expected? Does progress match what is reported on the team board? Is there any testing we can do?

Can we pair with anyone in the team? Don't forget as well as pairing with developers we can also pair with testers. Pair with someone in the customer team to help create user stories. Are their expectations realistic but high? Are they in tune with how the software will be used? Do they have a cohesive and compelling vision?


My favourite part of the day is lunch. Eating with our team when possible is an important part of our job. This is when we often find out about the real problems the team are facing. It is also a time for bonding, dreaming, and building a team vision. How can we create software the customer really wants? How can we improve our code base and working practices? An engaged team will frequently talk about these kind of issues at lunch. I have got into the habit of always taking pen and paper with me. There is always something I want to action when I get back to my desk.


The concept which can be the hardest to get used to is - you are not meant to be busy all the time! Part of our job as agile coach is to bring new ideas into the team. This can only be done if we have new ideas. Spend time researching what is happening in the world outside our company. Reading books, reading blogs, listening to podcasts, attending conferences.

Do we have any peers in the organisation? Spend time talking to them and building a relationship. Otherwise how will you learn from them, how will you know if they can help you or you can help them?

Spare time is also needed to reflect and think deeply about the state of our team. How are the team doing? Are they motivated, energised and focused? How is the product doing? Will it delight the customer? How is our process? How can things be improved?

If we are busy all the time these things will never get reflected on, long term goals will never be progressed and hard to action things will never happen.

Are there any retrospective actions that need work on - or problems that seem too hard to tackle. Is there anything at all that can be done? Even just the tiniest step towards our desired end state?

Also you need to be available for the team - they might want to speak to you. Spend time observing the team. Who works with who? Who is fully engaged? Who's surfing the web? Listen to the conversations that are happening.


We also need to spend time promoting our team, their product and their process. This promotion may be overt or subtle and may take many different forms. But spend time networking with other people within the organisation. The more that people know about our team the more they will like and respect our team. Promoting our team can protect us from all sort of organisational games that otherwise might happen behind our back.

So attend meetings, demo the product, but also be friendly and chat to people throughout the organisation. Just simply chatting to people is part of our job (it took me a long time to be comfortable with this).

Sometimes you can be the representative for the team in meetings and save someone else being disturbed and bored through a meeting which isn't of much relevance to them.


The hardest thing about being an agile coach can be working out what to do all day. Remember if you are busy all the time you won't be able to do your job properly.

Take an active interest in the team, the software, and the build. Try to spend time each day looking at these things.

It is our job to improve the team, market the team, and protect the team.


These are the kind of things an agile coach should be doing each day:

  • Prepare for the daily scrum
  • Run the daily scrum
  • Follow up actions from daily scrum
  • Play with the software
  • Prepare for the next iteration
  • Have lunch with the team
  • Reflect on the team, product and process
  • Network outside the team

Recommended Reading

Slack by Tom DeMarco Scrum master's checklist by Michael James