How we approach a daily scrum


Agile, agile, AGILE!

Many companies in the modern fast-paced world of tech begin their day with a daily scrum, and ‘agile’ has become a common keyword that you’ll find on almost any randomly googled IT company. Why? Probably because this seemingly new trend is one everyone wants to say they follow. But I wonder: do any of these companies have a complete understanding of what it is they are doing and what value it really has?

The Cogworks’ struggle with morning meetings

A few years back we used to start our day with a daily scrum. The whole development team reviewed what they had done, will do and highlighted blockers. As a part of this, we also used a board with a high-level view on all projects that are currently worked on. As a small company, at the time we just had developers and project managers, both responsible for the quality and tests. However, as the company grew, we noticed that our fifteen minute daily scrum had been growing past a half hour meeting and we were still not done! Something was wrong - we needed to fix it.

Houston, we have a problem!

Maybe the form of the meeting was wrong? Did we need to review what we were doing in so much detail? Perhaps no one was interested in other projects they weren’t involved in? These were relevant questions. However, when in doubt, we did what any good agile practitioner does, we reviewed the process, adjusted and tested the outcome.

We altered our format, changed it to a reporting meeting, following our Trello board structure, updating each other on the progress of each task. Although we were following the cards, there was no emphasis concerning what we did to achieve the weekly goal. Task A was moved to the client’s environment and would be tested that day, Task B is half-done and means the dev is working on it and task C is still in review and the developers will begin working on it that day. We kept doing it—it was working!

And then…we saw bored team members who were standing there and sometimes not saying anything for the whole meeting. This was because PMs didn’t need to know the technical details and devs didn’t need to know the PM parts.

“Ok,” we said, “let’s try again. Let’s try separating our meetings - PMs have a meeting at 9:30, devs at 9:45 - but let’s keep a couple of senior devs in the PM meeting. They will be useful!” We tried it for a couple weeks then we realised that the PMs were getting updates from developers anyway after those meetings! Estimations were then pushed later in the morning. Did we really need to mix management meetings?

And… we’re back with the daily scrum. The same but improved?

After a couple of tries, we’re now back to the daily scrum format. We have our team stand-ups - the content team starts in the early morning, then project managers meet together, and then developers. After months of using the meeting as reporting, there was some debate within the team as to whether we really wanted to change. But something still wasn’t working, we needed to improve! And I’m personally very happy about it. In my opinion, doing the real daily scrum is very useful as we’re talking about our everyday work and I get to know more about other’s people projects. Occasional catch-ups don’t give you those details. And if one of my colleagues goes on holiday or is off sick, the handover is much easier.

You’re not doing Scrum!

Now you may say: “A daily scrum without a development team?! What are you doing people?!” Well, I’m not saying that we do Scrum - we take what we need from the Scrum process and adapt it so it works for us. We’re using parts of the framework that fit our needs, we are flexible, we are agile, we’re using the solutions that work and helps us to be more efficient.

Project teams now have their own stand-ups and they do involve all the teams working on a project.

We’ve found a way to make Scrum work for us and we suggest you can make it work for you too. Just try some or all of the following:

Daily scrum: the perfect way

After this long introduction to our experiments - which in the end brought us back to where we were years ago - let’s talk about the daily scrum itself. It is a Scrum ceremony that everyone working with Agile knows. It seems to be pretty simple; but is it really?

According to the Scrum guide, stand-up should be timeboxed to fifteen minutes and every member of the Development Team should give the status of their current work.

Asking the right questions

The three standard questions that people answer during the daily stand-up are:
What did I do yesterday?
What will I do today?
Do I see any impediments?

It’s worth remembering that the time spent in the daily meetings should focus on giving updates about the progress in the current sprint and about how to achieve a sprint goal.

So the right questions should be (according to The Scrum Guide):

  • 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 see any impediments that prevent me or the Development Team from meeting the Sprint Goal?

You’ve learnt the right questions, that’s awesome, but your job is not done! You need to follow the sprint progress so that you know how much work is still to do (or how much has been actually completed). This will help you avoid a surprise at the end of the sprint when the half of the tasks haven’t been completed.

Follow the progress, find the right tool

How? Listen to each other, look at your scrum board, follow it, measure the progress, use a burndown chart. It’s important that everyone in the team is aware where we are in the sprint. Scrum boards should be visible and easily accessible to everyone - they can be a physical board, or a virtual one (there are lots of tools which offer help on organising your sprint - e.g. Trello, Jira). At The Cogworks we’re using Trello and our Head of Development—Anthony, who you probably know as a famous Umbraco star—is writing some magic to customise and automate this tool to meet our needs. Use what works the best for you. Remember that if you can see the board, the burndown chart and you can see the progress then you know where you are in terms of achieving the goal.

Scrum Master?

In this article, I describe the daily scrum that we’re having for managers. Please bear in mind that if Scrum is used in projects then your team will have a Scrum Master who will make the Development team’s life easier. In The Cogworks’ world this role hasn’t been delegated to anyone - also because we don’t really do a pure Scrum. As experienced Agilists we’re aware of the role and we kind of share its responsibilities in the Project Management team.

Meetings are for your team, not for your manager or stakeholder

Remember that a daily scrum is a meeting for the team (not the Product Owner, client or stakeholder). The team members are reporting the progress to each other so they know where they are. If you’d like to invite other people to your meeting, please make sure that your Scrum Master explains to guests what exactly the daily scrum is and that they’re not the only ones it’s been created for. Following Michael James and his Scrum Reference Card: "The Daily Scrum is intended to disrupt old habits of working separately. Members should remain vigilant for signs of the old approach. For example, looking only at the Scrum Master when speaking is one symptom that the team hasn’t learned to operate as a self-organising entity."

15 minutes of essential information

Don’t forget, there is a reason stand-ups are standing meetings - if you need to stand for more than 15 minutes then it’s probably going to get quite uncomfortable for your feet. Don’t go into too much detail! If there are problems that need to be discussed, then it is a good time to flag them, but it is not always realistic to resolve them during the stand-up itself. Timings are important because they prevent the team from going into lengthy discussions which might, for example, only involve two people in the room. Essentially, you don’t want to waste the daily meeting time! Simply give people the most important information in a clear, concise and valuable way, receive the most important information and go back to delivering your sprint goal.

Start your adventure!

The daily scrum is for you and the development team and by implementing an efficient strategy, it will become a vital tool that helps you in your everyday work. Don’t be afraid to use it in other roles such as management, marketing or sales. I used to work as a Marketing Specialist and I had daily scrum meetings with my team. If your team needs it, do it! You don't need to follow the full Scrum process, take what you need from it that works for your organisation. Agile is not about following one particular framework. It's about open communication and removing blockers to ensure the process of getting work though an organisation is as smooth and efficient as possible, the tools you use are irrelevant, use whatever you like as long as they work for you, and make sure you test, test, test! How do you know your changes are working and you process is improving (or not!)? If you’re saying that you are Agile, then be agile! Be flexible, play with solutions, experiment, find your own way, don’t be afraid of a change. Start your management adventure!