Category: Agile and Scrum

This is a common issue:  Scrum is best executed with co-located teams, but teams are often geographically distributed.

What is the best way to tackle this?

What are the problems that can arise when implementing Scrum with distributed teams?

Here are some of the problems:

Problem: Time difference

The Scrum Master has to manage this carefully. Ideally everyone should work the same hours, but with remote teams this is generally not possible. If an Australian team is working with a team in India or the Ukraine there is a flurry of activity very late in the day for the Australian team.

This is a problem because the Australian team are not at their best late in the day after a full day of work, so it is difficult to be as focussed and fresh.

Proposed Solution

Let the Australian team start later than usual and work a little later (assuming they are comfortable doing this).  This isn’t going to work for everyone, but it does make a significant difference to productivity when it is applied.

Sitting on the phone at 10pm is not pleasant or desirable.

Problem: Cultural Differences

Certain cultures have very specific etiquette around mode of communication, the tone of communication, mode of address and so on.  It is fairly easy to inadvertently offend a team member without knowing it.

To make matters worse, the team member may not offer up any kind of feedback on any offence taken, and may exhibit other forms behaviour that make working with this person difficult.

Proposed Solution

Get to know the team members well enough that they will feel comfortable confiding in you if the behaviour of a team member is not acceptable. This needs to be discussed with the team explicitly early in the team’s relationship.

If there is an incident, address it with the parties immediately.

There are books and websites that talk about cultural etiquette. These are always worth a look. If nothing else you can avoid the most egregious faux pas.

This has helped me in the past.

For example; in certain cultures it is completely unacceptable to dress someone down in front of the team, get angry, or be abusive to a colleague. If you behave in this way, you may find that the team member is totally resistant to working with you going forward.

Not all team members will be accustomed to a collaborative Scrum environment. They may not be comfortable contributing to the level required. As the Scrum Master you will have to mentor these team members, describe the collaborative nature of Scrum, and nurture their participation.

Make sure everyone is treated with respect and as equals. This is especially true where a team member does not speak English as a first language. Again, as Scrum Master, you must stay on top of this and address any issues immediately if they should arise.

Problem: Distributed teams make it is difficult for team members to get to know each other personally.

This is important as teams function much better if there is personal rapport between the members of the team.

Proposed Solution

If possible, get the team together physically in one location and let them work as a team for a few weeks at that location. During this time, organise informal social activities to allow the team members to get to know each other.

When the visitors return to their home location, communication will improve as the personal common ground that has been established through the visit will add another dimension to communication going forward.

Organise these visits every six to eight months for best results.

Problem: Impediments that stop progress out of office hours

If these impediments or questions  are not dealt with you can lose productivity while the team member waits for a response.

Proposed Solution

Team members need to think ahead so that they can bring any impediments up at the stand up.

If this isn’t possible, they need to make an assessment as to how critical the issue is.

If the issue is critical and there really isn’t anything they can work on, they must contact the Scrum Master. The Scrum Master can decide what to do from there. Sorry Scrum Masters, but this is one of the perils of managing a distributed team!

In order to manage your distributed Scrum team effectively you will also need to do the following:

Choose a great Scrum hosted software tool

This is crucial for any number of reasons, but primarily:

• so that everyone knows their responsibilities
• to manage the tasks and the product backlog
• reporting on progress
• managing sprints, burns downs and other Scrum artefacts

There are many great hosted Scrum tools out there, but the most popular include:

• Scrum Works
• Rally
• Microsoft TFS with Scrum
• Jira and Greenhopper

Run a stand up every day at a time when everyone can attend

This may seem obvious, but not all teams adhere to this and it undermines the Scrum process. Make sure everyone does attend.

Use the best and most reliable communication tools

This is important as many meetings fail because a team member couldn’t join in.

Make this someone’s responsibility (Scrum Master?) to make sure that everyone has the necessary software and access so that they can participate unhindered.

The obvious software tools would include Skype (or equivalent), desktop share, and video conferencing (if appropriate).

I hope you found these tips on running distributed Scrum teams are helpful. If you have any tips of your own, please add them as a comment to projects [at] onedot.com.au.. Thanks.

When a company transitions from Waterfall to Scrum often there will be project managers who will take on the role of Scrum Master. Some of these project managers may not fully understand the difference between being a Scrum Master and a Project Manager. This can lead to many unforseen problems.

What is the difference between being a Scrum Master and a Project Manager?

A project manager:

• is in charge
• directs and manages the activities of the project team
• keeps everyone on schedule
• guides the project through the various phases of the development lifecycle
• reports progress to stakeholders
• makes sure that deliverables match requirements
• Is ultimately responsible for the success or failure of the project

A Scrum Master:

• is not in charge. A SM is a facilitator and mentor.
• facilitates the activities of the team.
• assists with the schedule, but is not required to ensure that the members of the team stay on schedule. Staying on schedule is a team responsibility.
• does not manage the phases of development. Scrum does not have sequential phases of development. As it is iterative, all phases of development are encapsulated in each iteration. It is not the SM’s responsibility to ensure all necessary activities within an iteration are completed. This, again, is the responsibility of the team.
• does not report progress to stakeholders. With the right use of technology, the stakeholders should be able to follow the progress of each sprint in real-time. The stakeholders should also be actively involved in decisions regarding the product backlog via the product owner. The more traditional reporting mechanisms associated with waterfall should not be required if Scrum is implemented correctly.
• does not match requirements to deliverables. As Scrum requirements are embodied in the product backlog,  again, with the right use of Scrum technology , it is easy to see what is remaining in the product backlog and what is in the current sprint. Scrum also requires a continuous feedback loop meaning that after each two week sprint the user stories that have been completed are either approved or rejected by the product owner. This is the equivalent of matching requirements to deliverables incrementally, after each sprint.
• is not ultimately responsible for the success or failure of a project, the team is.

Scrum Master Role Defined

• Oversees the process and helps team members with the process where necessary.
• Removes impediments. An impediment is anything that prevents the process from moving forward.
• Works with the product owner to keep the product backlog in order so that the next batch of user stories are ready for the next sprint.
• Protects the team against unnecessary intrusion from outside.

Having a command-and-control project manager as the Scrum Master can lead to the following problems:

The Scrum Masters attempts to ‘direct’ the work of the team.
This defeats the purpose of Scrum. The purpose of Scrum is to allow each team member to take responsibility for their contributions and self-direct their own activities with the support of the team.

The Scrum Master may think that he/she ‘knows best’ what should or shouldn’t happen at any time.
The Scrum Master is not there to impose his/her ‘expertise’ on activities. The SM role is to facilitate the decision making process amongst the team members.

The Scrum Master may question the accuracy of estimates, backlog priorities, technical solutions and so on.
Again the Scrum Master is subordinate to the teams decisions. The Scrum Master may make recommendations, but ultimately it is the team and product owner who will decide whether to implement those recommendations.

Ultimately not all project managers are suited to the role of Scrum Master. The Scrum Master needs to bend to the will of the team and to meet the needs of the team as they progress through the sprints. It isn’t a position of authority per se, so project managers who are used to being ‘in charge’ may find it difficult to adapt.

My best advice to project managers who are embarking on a career as Scrum Masters is to really read up on Scrum so that they have a clear understanding of where their responsibilities begin and where their responsibilities end.

Here is a good article about the 7 Must Have Project Management skills. I really liked the way that it is explained and I believe that these skills are Must Haves for a successful Project Manager.

The skill No. 6 “Recognize and solve problems quickly” rang a bell. I do agree that a Project Manager should be able to see and resolve a problem quickly. However, what I think is a better skill to have is to be able to predict a particular problem or risk before it happens, work on it pro-actively, and nip the problem in the bud.

The difference here is between a Hero and a Silent Achiever. A Hero might be seen as one who goes in a helicopter, stoops low and douses the bush fire. The Silent Achiever is one who realized that the atmosphere is dry and hot, predicted the bush fire and cut the grass / poured water on the field to ensure that the bush fire does not occur. So, for the casual observer, it seems to be Business as usual and the effort put in by the Silent Achiever is not usually noticed.

All said and done, each person has his place. It takes a lot of hard work to be a hero and a lot more to be a silent achiever. Keep your eyes open and make sure to applaud the Silent Achievers as well.

Cheers,
Sampath Prahalad, Snr Project Manager at One Dot.

As the world embraces the Agile methodologies with gusto, it is important to get certain elements right to ensure that the key Agile principles are properly implemented. One such element is Transparency. A mature Product Backlog goes a long way in ensuring transparency.

For the beginner, a Product Backlog is a wish list of features or enhancements that would make your product great. It contains User stories which are features or enhancements written in the language of the end user. Contrary to Waterfall projects which have a baselined and frozen list of requirements, the Product Backlog is kept alive and constantly modified through the life of the Product. It is this changing nature of the Product Backlog that is both an asset and a potential liability. It is important to ensure that the Product Backlog does not become just a stale document of EVERYTHING that might or might not get implemented in the product’s lifetime.

With this background, I shall now attempt to define the characteristics of “A Mature Product Backlog”.

Valuable User Stories: A Mature Product Backlog contains user stories that deliver value to the customer. Each user story should take the product one step closer to the product that the end user desires. Additionally, each user story should have Acceptance criteria clearly listing the boundary conditions, performance criteria and other quality expectations.

Prioritized Backlog: The Product Backlog should be prioritized by the Product Owner in terms of the highest value stories at the top of the list. Another factor to be considered is the Risk involved in implementing the user story. It is a good idea to categorize user stories on User value and Risk and then prioritize the backlog on Value first and Risk next. High Value Low Risk stories would be at the top with the Low Value High Risk stories at the bottom.

INVEST(ed) User stories: A mature Product Backlog has user stories that follow Bill wake’s Independant, Negotiable, Valuable, Estimable, Sized appropriately and Testable (INVEST) mnemonic.

A definite list: The backlog is a list of user stories that will make your product great and it is not possible to only have a certain number of user stories in it. However, instead of having an endless list of small and big features, all I want you to do is a) Keep features that are due to be implemented in the current Release very detailed, b) Group similar features that are part of future releases into Epics and c) Keep user stories from future releases big and break them down into smaller user stories only as you come close to implementing them.

Estimated User stories: This is an Optional requirement for a mature Backlog. It is great to have a Product Backlog with user stories that are assigned story points to determine the size and effort involved. This helps the Product Owner in prioritizing the user stories. For estimating a large number of user stories, Planning poker could be ineffective and the Affinity estimating technique will be a better method.

Over to you now. Please let us know if something is missing in this list.

Cheers,

Sampath Prahalad

All over the world, Agile methodologies are leading to faster value realization for both the businesses and customers. The value that Agile methodologies are bringing is evident from the fast paced and the high volume of companies and organizations adopting Agile.

What we shall explore today, however are the personality improvements that individuals get from being on an Agile team. These are assets for life that team members get from working in a self organized Scrum team. These traits are visible across most flavours of Agile, but we shall stick to Scrum for the moment.

Small steps with feedback: Scrum advocates frequent small releases to market with valuable content rather than one big release at the end of the project. This way, each time a small release is made, feedback is obtained and is ploughed back into the product to make it better. Scrum understands that planning is important, but it is more important to get moving. Similarly, with each personal goal, it is good to identify the goal, break it down into smaller parts, implement them one at a time, observe the results and fine tune or change the goal as needed. Many times, the personal goals and resolutions need constant reminding and by making frequent small changes, you are not only keeping the goal alive, you are also taking steady steps towards the destination. As Ralph Waldo Emerson puts it “An ounce of action is worth a ton of theory”

Effective Improved Communication: Scrum puts power into your hands as a team member. To exercise this power, you have to talk and express yourself in planning and estimation sessions, make your voice heard in daily stand-up meetings and voice your opinions in Retrospectives. Scrum’s rituals are all about being heard without being dominant. Initially, it might be hard for some team members to lose their inhibition, but Scrum’s daily stand-ups, planning meetings and retrospectives urge each one to open up and participate. In a positive way, team members are forced to open up in a trusted team environment and over time, this gives confidence to individuals to be more expressive in bigger groups and forums.

See the other person’s perspective: A team composition in Scrum consists of subject matter experts (SMEs) in Development, Testing, etc. As they plan together and work together Sprint after Sprint, they orient themselves towards the Sprint goal each time. With this, once a person is done with his/her task, he/she is now looking to pick up and contribute towards any other task that needs to be completed to meet the Sprint goal. The team member is picking up new cross functional skills and looking at things in a new perspective along with contributing towards the Sprint goal. Development and testing silos are broken and the team becomes self organized. Each person is able to understand and appreciate the other’s views and experience.

This experience teaches us to think more broadly when we face a situation in life where instead of criticizing a person who holds a different perspective, we try to put ourselves in his/her shoes and think from their perspective. Though this is no rocket science, the experience from working in an Agile cross functional team allows us to pause and listen to a perspective that could be valid and totally different.

Do let us know how your personality has gained by working in an Agile environment.

Agile methodologies are gaining increasing importance and acceptance as an excellent way to create software. More organizations are moving from Waterfall to Scrum, Kanban or XP with each passing day. However, as much as we hear about the success stories of organizations that have embraced the Agile methodology, we are also hearing horror stories about botched implementations and problems faced by organizations that have attempted to go Agile.

I believe that when an organization makes the transition from Waterfall to Agile, you would need buy in from the people that are directly involved: the developers, the product managers and project managers. They have to be trained, mentored and completely bought in.

However, what I believe is more important to the success of the Agile implementation is the support from the senior management. They need to be completely bought in and have to understand the principles as well. They would need to support the teams making the transformation and not have conflicting demands which could take them back towards Waterfall. A change from the earlier “Command and Control” mode of operation to a “Team empowerment” mode. A change in the ways of planning, execution and reporting.

See this article on How senior management misconceptions could lead to a failed Agile implementation. Stay clear of these and that would be a good starting point.

By Sampath Prahalad, Snr Project Manager at One Dot.

Scrum, in under 10 mins
Posted on May 27, 2014 Agile and Scrum by admin
New to Scrum or need a refresher?

All excited about Agile and can’t wait to learn Scrum? Or do you just want a Scrum refresher?

Take a look at this fast paced video by Hamid Shojaee of Axosoft. Don’t worry, it would take less than 10 mins. 😮 )

Scrum in 10

The video can get a little too fast at times, so, be prepared to hit the pause button, soak it in and move on.

Sampath Prahalad
Snr Project Manager at One Dot.