Agile software development practices have now become mainstream with SCRUM and Kanban being the most popular practices. Although the fundamental tenant of these practices is colocation, any medium to big organization will have teams spread across different geographical locations which may even be in different timezones. Over the past few years, I have worked in such setup and want to describe my experiences.
What works:
Distributed yet collocated team:
In this setup, even though the product or engineering organization is spread across multiple locations, the scrum team is collocated in each location. This means that the team in each location will have cross functional team members such as developers, QA, scrum master and business analyst. The team could potentially have dedicated architect and DBA. Although there is a single product owner, the business analysts acts as proxy product owner in distributed collocated team. DevOps movement furthers this by even bringing operations folks together with dev team.
The team in respective location will have its own sprint planning, backlog grooming, stand up and retrospective. Sprint review can be independent or combined with other scrum teams. It would be best to have engineering manager in each location who is accountable for the deliverables of his or her team.
Common backlog with feature grouping:
Product backlog, about which I have written earlier, is a key artifact for any agile product development team. It is recommended to have one product backlog with features grouped under themes. This allows the collocated scrum teams to focus on feature groups which can be included in product releases. When the team gets really large, single product owner may become a bottleneck. In such situation, there can be area product owners responsible for the particular area of product.
Collocated release planning:
Release planning activity involves deciding high level scope of a release. In a distributed team, it is preferable to get required members such as dev manager, leads (Dev and QA), project manager, product owner in a single location and plan the release. In order to plan a release, it is important to be ready with high level estimates of different features.
Face to face interactions:
It is a widely accepted fact and I have also experienced that communication is 70% non-verbal and 30% verbal. Best way to communicate is always face to face. In a distributed environment, this can be done through video calls and conferencing. I have found that face to face interaction through video calls makes a huge difference. Most IM tools now have the video call capabilities. I have also used google hangout as a back up if enterprise tool doesn't work well.
Invest in collaboration tools:
Most organizations use tools for collaboration and content management but the best collaboration tool in my opinion is WIKI. It is very light weight and effective. Although many teams use physical agile boards, it helps to have agile project management tool to complement physical boards. I have used Agile JIRA and VersionOne and found both useful.
Travel Budget:
Video communication helps with regular interactions among distributed teams but nothing beats in-person interaction. I have found it very useful for team members to visit remote teams and work with them for at least one sprint. This also breaks down any barriers that may exist between team members.
Travel is always considered an expense and gets slashed as part of cost saving efforts. However, in a distributed environment, it goes a long way to get people to meet once a year or at the very least, beginning of a project.
Common engineering practices:
Each team may have its own work culture and schedule but it is very important to follow common engineering practices. This may include but not limited to continuous integration, code review, DOD (Definition Of Done), coding standards, version control strategy etc.
What doesn't works:
Distributed scrum:
I have seen and experienced many teams performing stand ups and planning through conference calls and webex meetings. This is not only ineffective but inefficient as well. People are generally multi-tasking in such meetings and there is constant context switching which is highly inefficient.
Some organizations have adopted totally distributed model where everyone is remote. This not only requires a different culture but also effectively use set of tools and practices to bridge physical gap.
Remote employees:
Many teams claim to practice scrum where most of team members are in one location but 1-2 employees will be remote or home based. In this case, remote employees will dial into conference call for scrum meeting. This is not very efficient as mentioned above. Although occasional working from home is very common, in the past, we adopted a practice where entire team works from home on a agreed upon day of the week. This way everyone is either in office or remote.
Separated functional members:
Separate dev and QA teams is totally anti-agile. A common organization setup is developers and QA reporting into separate hierarchy. This may be ok as long as they work as part of the same team. It also applies to analysts, architects and DBAs. Handing off work to functional team members who are remote, doesn't work.
Detailed Estimation by remote teams:
Remote team members getting on a call and estimating backlog doesn't work well. Estimation requires common understanding of the project/backlog which requires discussion. This is best done in a collocated setting.
What works:
Distributed yet collocated team:
In this setup, even though the product or engineering organization is spread across multiple locations, the scrum team is collocated in each location. This means that the team in each location will have cross functional team members such as developers, QA, scrum master and business analyst. The team could potentially have dedicated architect and DBA. Although there is a single product owner, the business analysts acts as proxy product owner in distributed collocated team. DevOps movement furthers this by even bringing operations folks together with dev team.
The team in respective location will have its own sprint planning, backlog grooming, stand up and retrospective. Sprint review can be independent or combined with other scrum teams. It would be best to have engineering manager in each location who is accountable for the deliverables of his or her team.
Common backlog with feature grouping:
Product backlog, about which I have written earlier, is a key artifact for any agile product development team. It is recommended to have one product backlog with features grouped under themes. This allows the collocated scrum teams to focus on feature groups which can be included in product releases. When the team gets really large, single product owner may become a bottleneck. In such situation, there can be area product owners responsible for the particular area of product.
Collocated release planning:
Release planning activity involves deciding high level scope of a release. In a distributed team, it is preferable to get required members such as dev manager, leads (Dev and QA), project manager, product owner in a single location and plan the release. In order to plan a release, it is important to be ready with high level estimates of different features.
Face to face interactions:
It is a widely accepted fact and I have also experienced that communication is 70% non-verbal and 30% verbal. Best way to communicate is always face to face. In a distributed environment, this can be done through video calls and conferencing. I have found that face to face interaction through video calls makes a huge difference. Most IM tools now have the video call capabilities. I have also used google hangout as a back up if enterprise tool doesn't work well.
Invest in collaboration tools:
Most organizations use tools for collaboration and content management but the best collaboration tool in my opinion is WIKI. It is very light weight and effective. Although many teams use physical agile boards, it helps to have agile project management tool to complement physical boards. I have used Agile JIRA and VersionOne and found both useful.
Travel Budget:
Video communication helps with regular interactions among distributed teams but nothing beats in-person interaction. I have found it very useful for team members to visit remote teams and work with them for at least one sprint. This also breaks down any barriers that may exist between team members.
Travel is always considered an expense and gets slashed as part of cost saving efforts. However, in a distributed environment, it goes a long way to get people to meet once a year or at the very least, beginning of a project.
Common engineering practices:
Each team may have its own work culture and schedule but it is very important to follow common engineering practices. This may include but not limited to continuous integration, code review, DOD (Definition Of Done), coding standards, version control strategy etc.
What doesn't works:
Distributed scrum:
I have seen and experienced many teams performing stand ups and planning through conference calls and webex meetings. This is not only ineffective but inefficient as well. People are generally multi-tasking in such meetings and there is constant context switching which is highly inefficient.
Some organizations have adopted totally distributed model where everyone is remote. This not only requires a different culture but also effectively use set of tools and practices to bridge physical gap.
Remote employees:
Many teams claim to practice scrum where most of team members are in one location but 1-2 employees will be remote or home based. In this case, remote employees will dial into conference call for scrum meeting. This is not very efficient as mentioned above. Although occasional working from home is very common, in the past, we adopted a practice where entire team works from home on a agreed upon day of the week. This way everyone is either in office or remote.
Separated functional members:
Separate dev and QA teams is totally anti-agile. A common organization setup is developers and QA reporting into separate hierarchy. This may be ok as long as they work as part of the same team. It also applies to analysts, architects and DBAs. Handing off work to functional team members who are remote, doesn't work.
Detailed Estimation by remote teams:
Remote team members getting on a call and estimating backlog doesn't work well. Estimation requires common understanding of the project/backlog which requires discussion. This is best done in a collocated setting.
No comments:
Post a Comment