Remote Agile
Ever wondered about Agile and time zones? How can Agile work for me in a relationship where I do not have physical access and worse, do not have time zone periods in common.
The following post tells part of the story but like many of the conversations does not grapple with the problems of time zones.
Trust me, it is hard to work Agile over a time zone problem such as Chicago and India. I know, we are doing that at the moment. Is the pay off as good as having your co-located team right there next to each other? No, clearly not. However, it is worth persevering because the benefits are there to be found. There is a price though! And that price is some sleep.
There is no substitute for a daily communication and that means a late day in either India or Chicago. In my case both! This is ALL about working out how to communicate effectively and efficiently when you miss some of the times. Like Remote Agile when you do have time zone cross over, the tool set includes Chat, WebEx, your favorite Agile boards and anything else that helps communication when you are not sitting in the same room.
Discipline is important too. You will feel the need for more communication time, rightly so. I urge you not to side track from your daily scrum and try to solve problems in the scrum. Identify them as roadblocks and work out who will help address it. Don't solve it then unless it is a 10 second answer.
Do work out how to have more communication time. This is where you lose some sleep I am afraid. We are currently running a 15 minute scrum at 7:00am and a 30 minute "information exchange" at 7:15am. The information exchange is planned in advance and we believe it makes sense to schedule a regular agenda for our project right now. Your project might want something more flexible but ALWAYS make sure these are prepared in advance with what will be covered. Nothing derails this idea more than a meeting the participants do not know what is happening. The amount of "face time" is very precious in this relationship - do NOT waste it.
I also extend this late meeting for India with a late meeting twice a week for myself. As a leader it is important to share the pain, so I meet twice a week with the team at 10pm. The older I get the less sleep I need anyway!
Finally, work out how to communicate "out-of-band" to get some of the problems resolved. I confess we are still exploring this one with our current team but if your company uses collaboration software like Sharepoint, Jive or Confluence (or many others) then this is a place to start. It requires discipline - how pointless would this be to post a question and not have it answered? It requires thinking about tools such as discussion boards and tasks to facilitate that collaboration. Even though I see this as a work in progress it is clear to me that the better I do here the less time I waste in the precious communication time where I am actually talking to people.
What have you experienced in Remote Agile? How would you address the issues? Good luck with your Agile projects!
VP at CloudQuant Alternative Data
8 年Communication is the key. But don't let your electronic communication be the only way you communicate. People read emotions into your online communication that may or may not be there. For instance, an IM or JIRA comment of "Great" could be taken as: 1. Great thoughts... I'm really supporting you or 2. Great, now look at all I have to do. The daily scrum, and occasional direct phone calls will often build better performing personal relationships in your teams. They build trust. Great thoughts Jezza. ( I'm really supporting you :D )
I agree Melissa Trulock, there is a concern about distracting resources and making sure they are ring fenced. Part of what we try to measure is the impact of this and part of our daily meeting raises not only such a need, but whether such a thing must be addressed by the developers and whether it needs to be addressed in that sprint. Sometimes it does and the next question is "what must we remove from the sprint in order to meeting this concern?". The good news is that if done right, Agile can help manage that client expectation and produce higher quality code faster so there is less of it in the first place. I think I might consider this topic for my next post in February!
Senior Consultant at LIDP Consulting
8 年James Coplien
Communication is key. Sharing the pain helps to build a team, but I have found that some of the pain can come from a team member that is pulled in too many directions. You can outline a detailed plan and communicate the expectations as much as possible, but if a team member is being pulled into production issues constantly this will disrupt the continuity of the plan. Management must be onboard with dedicated resources.