Dev team from different timezones
Hi all,
I started a new project about a month ago, and I'm trying to show the bank that using SCRUM shouldn’t be something to be afraid of. However, I’m already facing a challenge: the development team is made of 4 people, but 2 of them are in a different time zone (+3.5h). It’s not a real team in the SCRUM sense — it’s essentially composed of members from two existing teams, and they’ve been asked by management to allocate only a percentage of their time to this project while continuing to work on their usual activities. I’m aware that this is not good practice for SCRUM.
These two original teams also have their own daily standups (in our case they're long and boring “status update meetings”), so to avoid overwhelming people with too many meetings per day, we decided not to run an additional daily meeting for this project. Instead, we’re doing a weekly standup, which usually lasts 30–45 minutes. We however unlock ourselves whenever a blocker happens or doubts arise by doing a quick meeting.
During our 2-week sprints I’ve noticed a recurring problem: the same developers — usually the ones with more responsibilities in their original teams — consistently fail to complete the tasks they committed to during sprint planning, because new urgencies come up every week in their main teams. This outcome brings some frustration to the same developers. Right now there’s no strict deadline pressure, since most of our work is blocked by an external provider. But I’m worried about what will happen in the next sprints, when the provider finally delivers the APIs and the workload increases significantly.
How would you handle this situation to avoid ending up with developers who cannot commit to the project? I thought about exposing to our manager a possible issue we could face with the project if people have to context switch in future, but then I also thought that this could worsen the frustration for the same people involved in the context switching. Any advice or similar experiences would be really appreciated.
In Scrum, projects are not committed to any more than tasks are. Goals represent meaningful commitments, as does the Definition of Done.
Who in the organization actually cares about the issues you are seeing? It's unlikely that Scrum is something they are afraid of, and more likely that change is.
Interesting post Alexandru.
Lots of issues in there but time-zone does not seem to be the main one.
Here are my thoughts.
- Daily scrum overrunning: Be strict, use a timer and only focus on your plans for the next 24hrs. Anything else should go into a separate meeting. A daily cadence is way more effective than a weekly one. If it continues to overrun, take it into the retrospective and ask them how to set limits.
- Shared resources: Often a problem. I normally push to get 100% of resources. If not, maybe set some boundaries where you get them x days per week.
- Urgent items mid-sprint: Of course this happens but it shouldn’t become the norm. I suggest the Scrum Master should work with the stakeholders with the aim of not disturbing the team mid-sprint but to put items to the top of the backlog.
Hello Alexandru,
so many issues in one post. My gut reaction is, this is not a good candidate for an agile project. We all live in the real world, not an ideal world. It is absolutely legitimate that the priorities of the company and urgency lie outside the value you are trying to achieve in your project. You don't even seem to have a representative of your external deliver in your standups. Moving from dailys to weeklys is also basically abandoning the pyschology of scrums. If you have to stand there everyday and say "i did nothing" it's a motivation to do something. If you make that weekly, then they walk in and say "i had no time" and walk out again and forget you. There also seems to be a contradiction in your mail. You say the company shouldn't be afraid of agile, yet people are already in standups. So do they want agile or not?
I think the biggest contribution that you can make to this company is acting like a scrum master. Take your observation about the unproductive pseudo scrums "status meetings" and ask to lead these meetings like a scrum master does. Get people focussed in the meeting, make them talk concisely and focus on impediments. If you can generate happiness in the staff by achieving this, then you can address other critical meetings, Reviews, Retrospections etc.
That is what I'd be focusing on for now.