Scrum

Distributed Scrum Teams: Never End a Sprint on Friday

Scrum team members know that things get very busy near the end of an iteration. The coding and quality activities need to be wrapped up, demo preparation occurs, the sprint review is held, the sprint retrospective is held, and the next sprint planning meeting is held.

If the onsite team team prefers to end iterations on Friday, they might naturally assume they have all day Friday until evening for these activities.

However, look at what that would do to a remote sub-team in India – it would mean working until early hours on Saturday morning. A better practice is to split the end of sprint activities across two days, ideally during the overlap time dedicated for sub-team synchronization. This insures minimal impact to normal working hours at the end of each sprint.

Distributed Scrum: A Day In The Life Of A Distributed Team

by Avienaash Shiralige 4 Comments

In my earlier post on “How to Address People and Communication Challenges on Distributed Scrum Teams” we discussed about importance of communication in building trust. Quality and Quantity of communication needs get amplified as soon your team gets distributed.

Distributed teams I have worked with have organized their schedule and overlapping hours some thing like below.

Distributed Agile: How to Address People and Communication Challenges

by Avienaash Shiralige 12 Comments

The main challenges of Distributed Agile revolve around People, Information sharing / Communication, and Project Structure.

Let’s talk about first 2 challenges and how to address them. I wrote an article couple of weeks before on “10 Best Practices of Distributed Agile“. You will find few more practices in that article to address below concerns.

People

[pullquote]Effective, honest communication and trust is the foundation of all Agile teams. Most productive development teams thrive in an environment of trust.[/pullquote]

Half or more of your development team is distributed across continents. How do you create that all important environment of trust and alignment to common vision when your team is distributed?

Your development team (onshore + offshore) now consists of engineers whose primary language is not English, or at least sounds different than your version of English. It adds another complexity to communication.

Cultural, tone and body language differences will compound the challenge. Multi-shore Agile requires changes to the norm. The best environment is when all developers (local and remote) feel part of the larger team and make decisions for the benefit of the single team. But how do you do this?

5 WHYs: Positive Root Cause Analysis To Find Good Practices

by Avienaash Shiralige 3 Comments

In my earlier article I shared my opinion about using 5 WHYs to find root causes. What I really missed to point was, it is not just applied to find root cause to problems, but it can be used to find root cause to good things that are happening on the team.

In sprint retrospectives we usually pick some problem that occurred, try to figure out why it happened, and then understand how we could prevent this problem from happening again in the future. Our root cause analysis meetings are usually always on “What is That Not Going Well”.

Now let’s apply 5 WHYs thinking to this question…

Distributed Agile:10 Good Practices of Successful Teams

by Avienaash Shiralige 8 Comments

10 good Practices of Distributed Agile Teams

Distributed agile teams can exist in different forms like.

Product Owner is onshore, Team is offshore
Team split between two or more locations
A complex model like product owner not with onshore team and development team distributed across time zones

I would like to share top 10 good practices that are implemented by successful distributed agile teams.