What a project manager would do?

See for yourself!

How to conduct effective sprint retrospective meetings?

1. Do retrospective after every sprint. No exceptions.
2. Involve all stakeholders. Developers, QA, Product Owners and whoever is involved in the sprint.
3. Define action items at the end of the retrospective and follow through on action items. In every retrospective, review the actions taken on the action items from the previous retrospective. This is very important. When a scrum master follow through and review the action items from the earlier retrospectives, team will start to believe in the effectiveness of the retrospective. If no action is taken, retrospective is just another boring, useless meeting!
4. Make sure every participant shares his/her feedback. Define a ground rule to state that no one interrupts when someone shares the feedback. "Talking token" would be useful in this situation. You can use a fluffy toy or a coffee mug or even a marker as talking token. When someone holds the talking token, he/she can talk and everyone else should listen. Once he/she is done, the token is passed to next participant. This approach will yield two benefits. (a) This reduces the interruption and makes the token holder comfortable to share the feedback without worrying about getting criticized in the middle of the conversation (b) Passing token among all participants helps the shy people to talk as well. 
5. Make the retrospectives fun. Try to use starfish approach detailed here. Nothing beats the wall and stickies. I usually record the retrospective output in Confluence pages as well to measure the retrospective effectiveness and also for historical purposes.
6. When you end the retrospective, ask the team if they want to thank someone for the help he/she provided during the sprint. This will help the retrospective to end in a positive note.

How to design a product/website with a distributed team?

It's challenging enough to design a website even when the entire team is co-located. How about designing a website when the team is distributed? To add a twist to the story: How about designing a website when the team is distributed AND everyone in the team is a volunteer for a charity project?!

This is the situation I faced since January. We, team of seven volunteers, have been doing a project for Taproot Foundation since January. One of our biggest challenges was to collaborate on the design of the website. If everybody is co-located, we could have completed the design in less than a week. However, the team was not only distributed but also working only part-time. We all have demanding full-time jobs. We work in late evenings and weekends for this good-cause project. 

I have used Asana to manage the project, it worked well to some extent. Thanks to people behind freeconferencecall.com, we were able to do weekly conference call on Thursdays to check the pulse of the project. We found that none of these tools replaced face-to-face communication required especially when it comes to design of the website or product. I just came across this article in nextweb. Author outlined excellent ideas for proper collaboration of design ideas. You will find it useful if your team is co-located. When I manage another non-profit project next time, I will probably ask the volunteers to gather in Mount Shasta for a weekend to finalize the design. It may not be a bad idea to go to kickstarter to fund the weekend brainstorming :-)

If you are involved in design of a product, you may find Stanford D School methods very useful, apart from the nextweb article mentioned above. 

I am a CSP (Certified Scrum Professional) !

I am not a big fan of certifications. But, I was intrigued by CSP for almost a year. I went to CSM training last year just to make my resume attractive. But, I learned a lot in that training. My planned next stop was CSP certification. But, I could not even start to prepare for the exams mainly because reading list for CSP was  too looong! 

I kept procrastinating taking the test until Scrum alliance announced to abolish the test route for CSP. That was a wake up call. I registered for the last available weekend before Scrum alliance pulled the plug on the test. I went in last Saturday and aced the test. I prepared for about 4 weeks. It was very hard. However, I learned some interesting ideas just because I was forced to read up tons of books and materials. 

Many years ago, I took the PMP exam. That was brutal. CSP is even more brutal. I am glad that I passed that test!

Missing Retrospective

There were so many times I get the resistance from the team when it comes to retrospective meetings. Usual arguments are: "Why the hell you want to spend one hour in every sprint for this meeting?", "It is a total waste of time", "I do not want to hear all those arguments", "We are matured Agile team, we do not need retrospective anymore", "It is a fish market", etc., 

Among these arguments "We do not need retrospective anymore" is my favorite! It's like saying, "I lost 15 pounds by hitting gym everyday in the past one month. I accomplished my goal. I do not need to go to gym anymore". If you do not continue your exercise, you are going to gain the weight back (and some) very soon. Consistency is the key. Retrospective meeting is the perfect option for all team members to voice their opinions and make meaningful contributions to the team and the project.

If some members are not able to attend retrospective, I do not cancel the meeting altogether. I would always reschedule or conduct the meeting with available team members. I use GoToMeeting or Join.me to connect with remote team members. At the worst case, I send out emails with questions, collect answers and schedule a brainstorming session in the following week. 

Gathering feedback and refining the process based on feedback is the core of Agile process. I would not miss it for any reason.

Managing Conference Calls

If you are managing remote teams, there is a high probability that you are doing scrums and sprint planning sessions thru GoToMeeting or other similar tools. Wall Street Journal published an useful article on this topic today - Surviving a Conference Call.

Key takeaways from the article are:

1. Scrum Master (Meeting leader) must set firmer ground rules than they do for face-to-face meetings and tighter, more explicit agendas
2. If a new member joins the scrum team (whether remote or onsite team), Scrum Master should ask everyone in the team to introduce themselves to the new member
3. Scrum Masters should talk less than in face-to-face meetings and listen more
4. Rotate the note taking responsibility among team members to increase the engagement

How to effectively manage globally distributed teams?

There are two twists to this question. One is how to effectively manage teams distributed across the world; another is how to do that in Agile mode.

Managing distributed teams is hard irrespective of whether you use Waterfall or Agile. Communication is the key. It may seem obvious. But, you will be surprised how many managers consistently mess up in that area. It is easy to assume a lot of things about stakeholders who are not physically present in your office. I have witnessed incidents where a product owner in London assumed that developers in India would work non-stop, in varying shifts, for few days before the launch. We had a client in Caribbean islands who assumed that modifying UI for iPhone app is just a matter of adjusting  some CSS; he thought his change request would take only few hours whereas the development team took more than a week. The list goes on and on.

If the team is multicultural, that adds more spice to the project manager's life. Remote teams in India, Japan, France or Dubai have holidays that may totally surprise project managers in U.S. It is not uncommon for remote teams to assume that everyone in the world know about their traditions. Some countries have Fridays and Saturdays as their weekend. Some have Thursdays and Fridays. Project managers need to educate themselves on culture and tradition of all stakeholders while managing distributed teams.

When we first started Agile, there was a lot of apprehension about using Agile with distributed teams. It turned out that Agile would actually make project management easier compared to Waterfall. If the offshore team is going to have religious holiday on a Monday, that discussion will come up in daily scrum many days before that Monday. Ideally, that would come up in sprint planning. Scrum masters may need to move around sprint meetings (sprint planning, sprint retrospective, etc.,) to suit the timings for all stakeholders. But, that's part of the game anyway.

To effectively manage globally distributed teams, following are vital:

1. Team collaboration software - Example: Confluence, Asana, Basecamp, Google Docs, etc., These tools help the team to collaborate on the project requirements and other project documents. Asana and Google Docs are free.

2. Backlog management tools - Example: JIRA Agile, Rally, etc., These tools will help you to maintain your product backlog and sprint backlog. These products are not free, but worth the price.

3. Web conferencing software - I would use GoToMeeting whenever possible. It's a paid product, but does the job very well. If you don't have budget for it, join.me is a good free product to use.

If your stakeholders are not familiar with any of these software products, train them before starting your first sprint. That will save you lot of headache.

Before concluding, an important point about daily scrums for distributed teams: 

Set a time for daily scrums, ask all teams including remote team to participate and stick to the time. This is a tricky part. Timing may not work out well depending on where your remote teams are. If your team is in San Francisco and your remote team is in Ireland, holding daily scrum at 8:45am PST would make sense for all team members. However, what would you do if your remote team is in Japan? I have seen companies doing 4pm PST scrum to accommodate both U.S and Japan teams. One of those companies are having two scrums every day -- 10am PST scrum for teams in U.S. and 5pm PST scrum for Japan team. That is very unusual, but happens.