• When a company is in the middle of a reorganization, then people are more focused on keeping their jobs rather than becoming Agile. We would advise against coaching while this is going on because the pressure on the team will be too distracting, and you will probably be wasting your time.
• To help Agile teams improve, you need to work with the individuals in the team. They’re the number-one experts on how they work and why. Tap into their expertise to reveal what’s holding them back. Listen to their concerns and ideas one-on-one to give you insights on how they can improve. Give them feedback to help them see where they can improve.
• When you are acting as a mediator, be clear that in this role you can’t take sides. Listen to the problem from each side, and demonstrate that you understand what is being said by restating the problem in your own words. Next, try to detach the problem from the individuals and frame this in the context of the team. It may be useful to create a diagram of effects to explore the forces involved.
• Make Change an Experiment: Once a team takes the plunge and tries a change as an experiment, team members get used to the new way of working. Now, making the change back to original way of working is the change that they hesitate over. You’ll also notice that each change they adopt reduces their resistance to the next change.
• Take care about using “why” questions, because they can shound like you’re criticizing when you don’t mean to do so. For example “Why did you do that?” sounds accusing, whereas “What were you trying to do?” sounds friendlier.
• There is no point asking about what got in the way if issues aren’t followed up. Avoid saying “Let’s take that offline” every time the conversation meanders or someone raises an issue, because this is ambiguous. Rather than scribbling notes about issues in your notebook, write each item that requires follow-up on a whiteboard that everyone can see to create a parking lot for issues. At the end of the meeting, revisit the parking lot to prioritize the items and work out who needs to be involved in any follow-up.
• A coach acts as the conscience of the team.
• The whole point of use stories is to ask questions to better understand what users need and to find ways of breaking requirements down.
• If the team is making one small changes to support live applications, rather than actively developing a product, there may be no benefit in getting the team together to create a longer-term plan. Instead, you might e better applying kanban, which focuses the team on improving the flow of work.
• The team’s productivity will not improve by wishful thinking and “trying harder.” At worst, it plummets under excessive pressure.
• Team velocity often slows down a little as the project grows and the software supports more user stories. Plans should be based on the new measured velocity rather than continuing to plan with the old velocity, hoping the magic will come back.
• When planning doesn’t make sense (lot of bugs to fix, on vacation members) create a prioritized queue of work on the team board. Consider moving to a kanban style of development which doesn’t depend on iteration timeboxes to limit work in progress.
• Agile teams need to learn how to work together to meet their goals. They are not kicking a ball; instead, they pass software between team members. Each person on the team plays a part in getting the work done.
• Don’t let them get away with adding a single task lebeled “Testing” for each story – this is a cop-out! A few examples of testing tasks are writing automated tests, preparing test data, and setting up environments.
• The job of testers is to “prevent defects” rather than collect them .If a story is still on the team board, then any problems that must be fixed should be posted there too, where the whole team can see them. Recommend the team uses bug-tracking software only for bugs that are found after the iteration ends.
• Encourage the team to design for now and to keep their design as simple as they can for current needs.

Scrum synergies the chiefs of each story and also the copilots so that everyone is on the same page regarding the goal of a sprint, and overall product goal. When a conflict arises between two chief surgeons where one is needed as copilot for the other one, we fall back to the prioritized sprint backlog and complete the higher priority story first, then concentrate on the later ones even if it means leaving some stories undone.

I found this blog post very helpful to create our burndown charts online. Nice tool to solve a trivial problem.

In an idle world, you are suppose to have your prioritized product backlog ready before your sprint planning meeting. But it may happen that you have a lousy product owner who forgets to update the backlog, or may be she is sick and couldn’t work on it before your next sprint planning. What do you do now? You have different options:

• You can stop sprinting and take a day off while your product owner sorts out the backlog for the team. This can be a good break for the team as you know you can’t be sprinting all the time, then you are actually jogging instead of sprinting.
• You can take a ‘lab day’ and ask your team members to work on what they think important from previous sprint, or previous feedback from sprint review meetings. You hope that your product owner will sort out the backlog meanwhile as your team focuses on working what they think important.
• You can carry on with you planning meeting without the prioritized backlog. This works if your team has already completed couple of successful sprints and knows the direction of the product. You ask your team what they think important for the product, and form stories from their feedback. You share the planning meeting details with the product owner and give her the option to change priorities/stories as she wishes.

For one of my teams, I chose the last option and so far everything worked smoothly. The team is well into their sprint and product owner is happy after changing one story from the Sprint backlog, and replacing it with one of her higher priority one.

Our board after sprint retrospective meeting

For a team to go from good to great, it needs to look back and evaluate itself against the decisions it took and figure out how to improve on it as it carries on the development. Sprint retrospective just facilitates that and helps the team to regroup for the next upcoming sprint and get better in the process.

As we are getting matured with Scrum, we find a pattern in our retrospective meeting which matches what Henrik Kniberg says at Scrum and XP from the Trenches. We merged our way of retrospective with Henrik’s way, and found that our retrospective meetings have become a source for motivation for the team, as well as helping the team to improve.

These are the steps we currently follow during our sprint retrospective meeting:

• What we did good: We start with a positive tone and find out what was good in our last sprint, what issues we implemented from our previous sprint which we thought important for the team. We write down the points on stickies and put them in our board.
• What could be better: A nice way to find out about the ‘could be better’ ones is to ask the team what they would have done differently if they had the chance to go back to the start day of the sprint using a time machine. We list inputs from all the team members and stack them on the board along the ‘could be better’ column.
  

  Team voting on important items

• What is important to implement next sprint: This is where the whole team works together to collect items from the ‘could be better’ column and move them to ‘important’ column. After they are done, we vote on the important items. Each member of the team gets three magnetic buttons and allowed to place on any important items she chooses. She can also choose to put all her votes on a single important item if that one has such importance level.

As I’m involved with multiple teams’ retrospective meeting, one interesting observation I’ve found out that most of our teams have one common ‘important’ issue, which is “Having tech-session between teams.” So, knowledge sharing within and among the Scrum teams seems to be a common goal for our teams.

Currently I’m practicing Scrum with my teams who are working as offshore development facility for our US counterpart. One of my team is on its’ 10th sprint, and I am listing some of the  practices in my team which made our journey successful so far:

1. We follow Scrum, not ‘Scrum BUT’: On some of my previous companies I worked with teams where I found them not using proper Scrum – what they ended up using is ‘Scrum BUT’. Though they were trying to follow Scrum, but they weren’t doing strict time boxed sprints with sprint review meetings, retrospective meetings, or even proper sprint planning meetings. With my current teams, I follow Scrum, and don’t allow any ‘Scrum BUT’ scenarios.
2. We have our product owner constantly communicating with stakeholders and users: Even though our Scrum team is offshore, we have our product owner(s) working in US close to the stake holders and users. Thus we are getting the proper prioritized backlog for feeding our sprints and creating useful software for the stakeholders after each sprint. Our teams talk with their product owners on a daily basis even if it is just to say hello.
3. A team with diverge expertise: When we created our initial Scrum team, we believed that if you put few good motivated developers together, they will self organize within the umbrella of Scrum and be productive spontaneously. So we gathered a team consisting diverge expertise which really helped the team to grow and produce successful sprint coping up with the diverge needs of the product.
4. All our team members went through Scrum training: Before a team starts sprinting for the first time, if the team is new to Scrum, we have all the members go through the Scrum Master Training session for two days. I believe this helps the team to get familiarize with Scrum’s practices and also helps them to break the ice so that they get ‘in gel’ quickly.
5. Uninterrupted high bandwidth net connection: For an offshore team to succeed, this one may be one of the most important point that needs to be taken care of. We made sure that our teams here enjoy enough bandwidth that they need for their daily development, screen casts, meetings with the product owner, etc.
   
6. A place where geeks can just be geeks and enjoy their craftsmanship: We ensure a happy, productive office space for our employees so that they look forward to coming to office every day and enjoy their stay here. We believe that if you are a true ‘geek’, you don’t need to be told to work, you enjoy working spontaneously for the betterment of the product you are involved with. Our office on the other hand makes sure that you are well fed, you can take rest and play a game of Table Tennis or something else you enjoy doing when your brain wants to take a break.
   

These are some of the practices I though worth mentioning for any other offshore team out there who find themself struggling with their projects.