Originally published on ScrumAlliance.org
With Agile as a philosophy and Scrum as a framework, ScrumMasters are sometimes on their own, left out in the cold when it comes to specific tactics. While I heartily recommend such practices as BDD (behavior-driven development), continuous delivery, and so on, there happen to be some simple time-management practices that I have found to be beneficial for almost all of my teams that have chosen to adopt them.
Team time facilitates collaboration
As every Agile practitioner knows, collaboration is essential to succeeding in Agile so that all parties can discuss the work that needs to be done. To increase collaboration, most of us facilitate grooming sessions with our teams to do things like pointing, writing acceptance criteria, and breaking down epics.
But there is one challenge many of us face: how to effectively schedule and ensure participation.
From my experience, one useful way is to establish “team time” every day right after the daily stand-up. Every day for my teams it takes the form of 45 minutes after the stand-up, which allows us appropriate time to sprint plan, sprint review, retrospect, backlog, story groom, and maybe tell a joke or two.
One of the major benefits is that every team member knows when they are going to meet in perpetuity, so they can more easily find productive time unburdened by a great number of ad hoc meetings. It also lends a very nice rhythm to their day! Since this (and my other technique, outlined below) is agreed to by the team and its efficacy discussed in retrospective, it’s a great example of how a team can maximize collaboration. I have had multiple teams use this technique over the past few years, and I honestly can’t recall one that did not feel it was beneficial.
“Office hours” allow team members to focus and find flow
Veteran ScrumMasters know that individual team members should not be scheduled for eight hours a day. In fact, most know that getting five good hours in a day would make for a productive day indeed! Besides, if you are using the team-time technique discussed above, then you’re starting an eight-hour day with only seven. But here’s the big question: How can I make sure I can get in those five productive hours a day?
In order to ensure that individuals get the needed focus needed to achieve a flow state, one that is necessary for good concentration and coding, most of my teams use “office hours.” These are time slots, decided upon by the team, when they are available for productive work only (e.g., tasks assigned during sprint planning). They will usually schedule a two-hour block in the morning and another three-hour afternoon block in Outlook (if you don’t use that, then you can use a real calendar! No, just kidding).
Not only does this eliminate disruptions but it is compatible with pair programming or other team interaction work when needed. As with team time, it is rare for a team to try this simple technique and then choose to go back to, as one team member put it, “scheduling chaos.”
Stronger together than apart
To summarize, using team time as discussed is an excellent way to facilitate engagement while also ensuring that the team’s rhythm is unbroken. As well, office hours provide a great, chaos-free environment for the team to buckle down, since the time blocks are clearly outlined. While each technique, in isolation, is beneficial for many users, I have found that team productivity soars when the two are fused together.
To see what this looks like in action, take a look at my example spreadsheet below. This will give you a starting point for your own implementation of these two techniques (and maybe jog some of your own inspiration!). I hope that this makes the Agile road easier to travel, because believe me, the journey is worth it.
For additional reading, here are two articles I recommend that touch on this subject:
- The 10 Principles of Agile Project Time Management
- Time and Distance: Enemies of Agile Project Management
If you have any questions, feel free to reach out with commenting below or with social media. Thanks for reading!
