by Ardiana Spahija
Share
by Ardiana Spahija
Share
Janne Peltonen, certified Scrum Master at Finland-based company Qvantel, knows from his own experience how to make distributed projects more productive and less problematic.
Qvantel has an offshore development center in Hyderabad, India, and offers near-shoring services for its customers in Scandinavia. Hence, it is crucial to find a way the company can operate efficiently in distributed setup, not losing the advantages which are achieved when doing things in an agile way.
– Our team members in Finland knew the basics of Scrum and gradually we got more Scrum training. The best way of learning the Scrum principles is putting them into practice.Furthermore we used Scrum ambassadors to facilitate the learning process; people from Finland traveled to India and vice versa. Softhouse also shared their Scrum expertise and experiences early on with us.
Simple methods
Normally collocation is an essential part of creating a high-performing self-organized Scrum team. Qvantel used ad hoc methods to bridge the big gap in physical location. Excel spreadsheets were used for key Scrum artifacts such as backlogs and burn-down charts. The spreadsheets were under version control system and shared by both sites. Usually it was up to the Scrum Master to maintain those files on a daily basis. Apart from that, Skype was used for daily Scrums, JForum for discussion forums, TWiki for collaboration and Subversion for maintaining the code repository.
– We did evaluate a group of Agile/ Scrum-specific tools but did not find anything suiting our needs. I personally think the tools available right now are too restrictive and force you to do things in some specific way. As Scrum is always a customized implementation, I didn’t feel like having a ready-made tool telling me how to do things. When you learn a process, you must be able to experiment.
Eliminating barriers
Doing distributed development is notoriously hard. Many projects are obstructed by problems like cultural and technical barriers, time difference. The Qvantel team tried to use the project setup in their favor.
– I think Scrum is about communication. Instead of two separate teams, we had one team with team members both in Finland and India. This way we avoided the need for team coordination. The team consisted of eight people who participated in the daily scrum meetings so that everybody always knew what the others were doing. The time difference between the sites is only a couple of hours so it makes life easier, says Peltonen and continues:
– Another major thing is the challenge with cultural differences: people are different and are used to diverse types of working cultures. Once you recognize these, you understand your team better.It is also possible to change the working culture – again, direct and efficient communication and personal contacts are paramount. Also, even if you are agile, good planning is essential. If you plan properly, your plans don’t change all the time and the distributed team is able to understand the project targets and perform better.
Working on the backlog
Always important but even more so in a distributed environment is the way requirements are conveyed by the product owner and broken down into deliverable entities together with the team. Qvantel found a way to manage this efficiently.
– Our product owner role consisted of two people: concept owner from Qvantel and a customer representative, together they were responsible for maintaining the product backlog. We had regular workshops where we broke down more high-level requirements. The team participated so that a representative from the India site was present in these sessions. In the beginning the responsibility was more on the Finnish side, but we soon realized the benefit of involving the Indian team members more as it made them more committed to the project.
Faster development
Traditionally, a strong architectural function is involved in turning requirements into good design. Because of this, Qvantel has a dedicated architect at the beginning of the project. But soon the rest of the team started to contribute more and more to the design.
– I personally don’t like having distinct roles in the team since it can lead to bottlenecks and people not taking responsibility. We performed design work incrementally as the requirements were not all known at the start of the project.
To sum up, what measurable effects have you seen from using Scrum in a distributed environment?
– I think it’s possible to get working software delivered faster than with a traditional approach. The Customer gets to see concrete results early on, which suits a project where all requirements are not clearly defined in the beginning. Quality depends on many things: skilled people, enough testing and right SCM tools to manage the iterations.
With an agile approach you can spot potential quality problems early on and react fast. And it’s all very visible; you cannot hide issues from the team or the customer. My experience has shown that all this makes the customer more satisfied.
STAY IN THE LOOP