I was part of a very interesting discussion at a Silicon
Valley high-tech giant a couple of weeks back that focused on doing
Agile with distributed teams. We discussed several aspects of Scrum/ XP
practices in distributed teams – and it turned out one of the main
(some said “the only!”) challenges was the ability to run a Daily
Standup meeting well!
I was part of a very interesting discussion at a Silicon Valley high-tech giant a couple of weeks back that focused on doing Agile with distributed teams. We discussed several aspects of Scrum/ XP practices in distributed teams – and it turned out one of the main (some said “the only!”) challenges was the ability to run a Daily Standup meeting well!
Having been part of conference calls, WebEx meetings and other virtual gatherings for the longest time, this surprised me somewhat. So, in the last week’s Kaizen Camp Seattle Un-conference, I decided to do a session on that exact same topic. Fortunately, a handful of people were very interested and we had a spirited discussion on doing Agile in a distributed environment.
Much has been written about the challenges and benefits of doing Agile in a distributed environment that needs no repetition. We also went through our own challenges of running a well-oiled Standup meeting. Our team members are in Mountain View and Los Angeles, CA and in Mumbai and Bangalore in India – possibly the worst in terms of time overlap, with distribution along product architecture and some functional dependency!
However, three areas that we have increasingly become good at are worth sharing. It was also heartening to get some level of affirmation of the importance of these areas in these recent discussions.
Running the Daily Standup “by Exception”
Standup meetings – whether distributed or collocated have become notorious for a variety of reasons. They take too long, there are too many people in there, each member takes too long to give their update, meetings get side-tracked into specific issues, “some team members take too much time”, and so on!
Over a period of time, and especially after we started using Swift-Kanban for all of our development activity, we have learned to use a combination of the virtual Kanban Board and the standup meeting to keep everyone on the team on the same page. While Swift-Kanban provides all of the standard information anyone might have – such as who is working on what, where is a specific user story or defect, what interaction has happened on each of them, the Daily Standup is used to handle ‘exceptions’ – cards that are or might be in trouble.
We love our Board Filter, especially the Exceptions – as do our customers!
We start with “Blocked Cards” using a standard board filter. All cards that are blocked and might need some help are displayed first. The developer(s) describe their problem and the team discusses possible solutions. If it goes on for more than 2-3 minutes, it is taken up by a specific team member for further discussion with the developers.
We then go on to cards that might be Delayed or are Unassigned for some reason. Finally, sometimes, we may look at cards by Class of Service (especially Expedite and Fixed Delivery Date) as well as Priority (Critical and High).
All discussion that happens on each card is recorded on the Card discussion.
Before the meeting, all team members have usually updated the cards they are working on or finished with – so in the rare cases we need to look at those cards, we can easily filter by Team Member and discuss them.
We are normally done in about 30 minutes or less with our stand-ups! While this is admittedly longer than a recommended standup meeting, given our team size and distribution, it has worked really well for us.
Separation of Product Management and Engineering Boards
One of the biggest sources of discussion during our meetings used to be on User Story decomposition and clarification. After trying out a single lane board for our product development for about 9 months, we switched to a two swim-lane design – and separated the Feature - User Story decomposition, estimation, implementation approach and detailed user story description into what we call the Planning Board.
(Since we started, we have added a couple of more lanes for customer-specific and intangible work!)
This separation of the initial backlog prioritization and fleshing out of the features from the Dev activity has helped us tremendously in ensuring that we focus on the right things at the right time! The Planning Board team – primarily Product Management, UI and Sr. Architects – meets once a week to discuss implementation approach and high level specification, and focus on the Planning Board – which helps the Product Management and UI team to work smoothly on the detailing of user stories and UI prototypes.
Once User Stories are described in sufficient detail, they are ready to be pulled into the Development Board. The Daily Standup involves all functions, but focuses only on the Development Board.
Contextual Collaboration – Synchronous and Asynchronous
This obviously is one of the most critical requirements for a distributed team – to have the right tools for collaboration, discussion and tracking of all work that needs to be done or has been completed. Besides using Swift-Kanban, our teams completely depend on Skype and WebEx for all of our interaction. So, we have become very good at synchronous and asynchronous collaboration!
The key thing we have espoused to our customers and we do very well ourselves is contextual collaboration. Having suffered emails in our past lives, we try and keep all discussion and sharing of ideas on the Kanban board itself. All discussion summaries, action items and to-dos as well as documentation of user stories, issues, defects and so forth are saved in the context of the relevant card. We specifically discourage use of email for any such interaction. No searching for missing documents, specific versions and so forth.
So, when a meeting starts, everyone is logged into WebEx, Skype and Swift-Kanban – and off we go for another short yet contextually rich meeting, charged for the rest of the day or the week!
How do you do Agile in the distributed environment? Do share your thoughts with us.
Mahesh Singh
Co-founder/ Sr. VP – Product, Digité/ Swift-Kanban
I was part of a very interesting discussion at a Silicon Valley high-tech giant a couple of weeks back that focused on doing Agile with distributed teams. We discussed several aspects of Scrum/ XP practices in distributed teams – and it turned out one of the main (some said “the only!”) challenges was the ability to run a Daily Standup meeting well!
Having been part of conference calls, WebEx meetings and other virtual gatherings for the longest time, this surprised me somewhat. So, in the last week’s Kaizen Camp Seattle Un-conference, I decided to do a session on that exact same topic. Fortunately, a handful of people were very interested and we had a spirited discussion on doing Agile in a distributed environment.
Much has been written about the challenges and benefits of doing Agile in a distributed environment that needs no repetition. We also went through our own challenges of running a well-oiled Standup meeting. Our team members are in Mountain View and Los Angeles, CA and in Mumbai and Bangalore in India – possibly the worst in terms of time overlap, with distribution along product architecture and some functional dependency!
However, three areas that we have increasingly become good at are worth sharing. It was also heartening to get some level of affirmation of the importance of these areas in these recent discussions.
Running the Daily Standup “by Exception”
Standup meetings – whether distributed or collocated have become notorious for a variety of reasons. They take too long, there are too many people in there, each member takes too long to give their update, meetings get side-tracked into specific issues, “some team members take too much time”, and so on!
Over a period of time, and especially after we started using Swift-Kanban for all of our development activity, we have learned to use a combination of the virtual Kanban Board and the standup meeting to keep everyone on the team on the same page. While Swift-Kanban provides all of the standard information anyone might have – such as who is working on what, where is a specific user story or defect, what interaction has happened on each of them, the Daily Standup is used to handle ‘exceptions’ – cards that are or might be in trouble.
We love our Board Filter, especially the Exceptions – as do our customers!
We start with “Blocked Cards” using a standard board filter. All cards that are blocked and might need some help are displayed first. The developer(s) describe their problem and the team discusses possible solutions. If it goes on for more than 2-3 minutes, it is taken up by a specific team member for further discussion with the developers.
We then go on to cards that might be Delayed or are Unassigned for some reason. Finally, sometimes, we may look at cards by Class of Service (especially Expedite and Fixed Delivery Date) as well as Priority (Critical and High).
All discussion that happens on each card is recorded on the Card discussion.
Before the meeting, all team members have usually updated the cards they are working on or finished with – so in the rare cases we need to look at those cards, we can easily filter by Team Member and discuss them.
We are normally done in about 30 minutes or less with our stand-ups! While this is admittedly longer than a recommended standup meeting, given our team size and distribution, it has worked really well for us.
Separation of Product Management and Engineering Boards
One of the biggest sources of discussion during our meetings used to be on User Story decomposition and clarification. After trying out a single lane board for our product development for about 9 months, we switched to a two swim-lane design – and separated the Feature - User Story decomposition, estimation, implementation approach and detailed user story description into what we call the Planning Board.
(Since we started, we have added a couple of more lanes for customer-specific and intangible work!)
This separation of the initial backlog prioritization and fleshing out of the features from the Dev activity has helped us tremendously in ensuring that we focus on the right things at the right time! The Planning Board team – primarily Product Management, UI and Sr. Architects – meets once a week to discuss implementation approach and high level specification, and focus on the Planning Board – which helps the Product Management and UI team to work smoothly on the detailing of user stories and UI prototypes.
Once User Stories are described in sufficient detail, they are ready to be pulled into the Development Board. The Daily Standup involves all functions, but focuses only on the Development Board.
Contextual Collaboration – Synchronous and Asynchronous
This obviously is one of the most critical requirements for a distributed team – to have the right tools for collaboration, discussion and tracking of all work that needs to be done or has been completed. Besides using Swift-Kanban, our teams completely depend on Skype and WebEx for all of our interaction. So, we have become very good at synchronous and asynchronous collaboration!
The key thing we have espoused to our customers and we do very well ourselves is contextual collaboration. Having suffered emails in our past lives, we try and keep all discussion and sharing of ideas on the Kanban board itself. All discussion summaries, action items and to-dos as well as documentation of user stories, issues, defects and so forth are saved in the context of the relevant card. We specifically discourage use of email for any such interaction. No searching for missing documents, specific versions and so forth.
So, when a meeting starts, everyone is logged into WebEx, Skype and Swift-Kanban – and off we go for another short yet contextually rich meeting, charged for the rest of the day or the week!
How do you do Agile in the distributed environment? Do share your thoughts with us.
Mahesh Singh
Co-founder/ Sr. VP – Product, Digité/ Swift-Kanban
Agile in a Distributed environment
ReplyDelete