Posts Tagged ‘Managing Remote Teams’

17
JUL
2012

How Going Slow Can Actually Speed You Up

Comments (0)

As many companies can attest to, it matters less and less where software developers are physically located. Working in a distributed manner with somebody halfway around the world is almost the same as if they were in the next building as communication is disrupted in either case. But there are some key differences to building an internationally distributed software team, and working with them for the long term, versus building another team in the building next door.

U.S. companies are accustomed to expanding internal teams by figuring out how much work is required for a project or how much is in the pipeline for a particular system, and how many programmers will be needed to complete that work; they then immediately hire the full allotment of programmers (assuming budget allows). There may be an onboarding process for new team members which may involve having new team members complete a training course, or work with a mentor, etc., but the main emphasis is on technical skills. These types of companies come to Softjourn eager to “start up a remote team,” believing that everything is going to be wonderful once they have 10-25 top level programmers on board. When you work with a remote team, however, assigning a full team of developers from the very beginning is often impractical and can cause inefficiencies that plague a development team for its entire lifecycle; especially if this is a company’s first foray in to working with a remote software development team.

At Softjourn, our process for helping our clients build software development teams is different but simple: prepare, construct, produce then expand. This means that we build a team on a solid foundation before expansion. If your company truly wants their remote team to be a part of your company, to work directly with another team of software developers who work at your company headquarters, or in other locations around the world, etc., more time and more of a process is needed to bring remote developers in to your company culture. Helping them understand your product and your clients takes effort, getting both sides (your existing software developers, QA Test engineers, product managers, escalation engineers, etc.) comfortable and trusting each other takes time, and this is much easier when you start with a small and focused team. Start with a small team, get the process right, and then expand. In addition to allowing for a more efficient initial training process, this lets the team itself select the right people for the team, to train new members as they are added going forward, and gauge their productivity. As well, your current in-house developers have to get used to working with a remote team. Processes have to be in place for communicating effectively with a remote team, to introduce and get them and everyone comfortable with communicating and working directly, to set realistic expectations for the team, etc.

Every aspect of our system is designed to work for our clients. The key advantages to this process are:

– Every single developer working on your project fully understands the objective of your application, why the users work in a certain way with the application, etc., and is able to communicate the objective to the other members of the team.
– Your in-house team feels comfortable working with your remote team, both to contact them directly, and with the level of productivity of the remote team.
– The team gains momentum as they move forward, completing work faster and faster, as they become more and more familiar with your system. They also are able to provide input to the design of features, and require less and less of your input in order to be able to understand how your company expects features and changes to be designed and implemented.

Once you get to this point with a remote team, you can start adding people. The remote team will be able to identify the right people to add to the team, those that will fit in with the team culture you want. One of the worst things you can do is to start to develop remote teams in multiple directions at the same time (for example, for multiple products, at one time), without having the process at least working for one team. You can expect that there will be just as many adjustments inside your company, with regards to working with the remote team, as there is for the development of the remote team itself.

Distance means that there will be differences when working on joint development, and those differences could cause significant delays in the development lifecycle of a software development team. Taking the time to prepare, construct and produce, before you expand, may seem like you’re slowing things down, but you’re actually solving problems before they even exist – and that improves your ongoing software development from every perspective. For more information on Softjourn’s Prepare, Construct, Produce, Expand methodology, click here.

Categories: Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Project Management, Virtual Teams |

15
MAR
2012

The Value of Hiring the Emerging Generation of Software Developers

Comments (0)

When Softjourn was founded, we felt that the core of our company’s growth should come from maintaining an investment in the emerging generation. Through an extensive training program, we’ve since cultivated a continual pipeline of talented people. Young professionals have much to bring to the table, including new ideas, enthusiasm and an eagerness to learn. The more experienced programmers who teach them gain the opportunity to develop their skills and grow into leaders. We can’t emphasize enough the role that hiring and training plays in the success of our projects and relationships with clients.

Developing the next generation of bright programmers is such an important part of what we do that we’re partnered with the National Technical University in Ivano-Frankivsk, Ukraine, where our software development center is located. Many students are in a five-year master’s degree program in computer science or other software engineering related disciplines. One of our Project Managers is an instructor at the university as well. Many interns come in as third or fourth year students. They work for us as junior programmers while finishing their degree, and then become a part of our regular development team. This preparation process gives them the opportunity to develop their skills under the guidance of experienced software professionals, and gives us the benefit of their enthusiasm, and gives them time to get up to speed on Softjourn’s methodologies.

Our training program is equal parts trainees and trainers. Developing future managers and project leads is another benefit of integrating training into the work environment. Team members who volunteer or are “volunteered” to take on the role of mentor get the type of hands-on experience that’s essential to management training. By training others, mentors learn how to lead a software development project before they’re officially in the position. They’re managing another person and taking responsibility for someone else’s work. They learn to communicate on their feet, so their non-technical skills evolve naturally. Employees interested in management know they can best demonstrate their potential to lead and work with clients by doing a knockout job at training our newest software developers. A senior developer in Softjourn also has taken on the responsibility to liaison with the National Technical University. He continually presents to the students’ different topics which aid in their development, as well as talks with them and mentors them on their technical interests whether it may be java, or .NET or mobile development.

Communication is a primary concern of many prospective clients. Therefore, non-technical skills are among the most important qualities for the emerging generation of software developers to cultivate. To be successful in this industry, we’ve pushed the communication skills of every person at our company. That means not just English language skills but skills in working with clients. It’s our priority to grow team members who are capable of putting themselves in the clients’ position. It’s not enough to ask a client what they need. Our people ask the questions that help pull out essential information for a project, and they realize the concerns a company may have in working with remote software developers. As a company, we’re able to relate, and that’s what keeps our clients coming back.

Categories: Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Project Management |

26
SEP
2011

I was so hoping to learn something new!

Comments (2)

But did I?  I just finished reading Terence Brake’s book, “Where in the World is my Team?”.  I was intrigued by the reviews saying it was not a regular business book, and of course the topic of virtual teams, so I decided to pick it up.

If you are not familiar with this book, indeed, it is not like usual business books in that there are actually points in it that will make anyone laugh. At the beginning, we are introduced to Will Williams, the new assistant to the CEO at a gaming company, The Fun House.  He is working in London, but there is a whole host of characters all over the world, with whom Will interacts. Will is tasked by his CEO, to put together a Briefing Report on the new workplace, working virtually, technologies that aid the new workplace, etc., for her upcoming TV appearance.  The readers “learn” along with Will, as he wades in to the new workplace.

The set up having to go through Will’s introduction in to working with virtual teams is a bit much, having to go through each of his meetings, and his personal feelings on meeting with his ex-girlfriend or the “interesting” analyst, whose work Will never bothered to read, dealing with his parents, his new love, etc.  But you really can’t skip any part of the book. The dialogue of a relevant conference call talking about ways to improve communication in virtual teams may be between a few paragraphs about the crazy analyst or Will’s colleague in the next cubicle.  You can certainly skim those parts though.  By doing it in real world fashion though, every reader, who has worked in global virtual teams will recognize similar mistakes they have made as they have learned to work with virtual teams.

Many of the points made in the book, building virtual trust, communication, etc., have been stated in other books, but I do like the diagrams that are used to show the different points.  For example the Collaboration Controller is good.  I also like the diagram on pg. 25 on virtual trust and its different aspects.

Some of my favorite points include:

–    Being in a virtual team, and especially leading one, means communicating when you don’t have to – not just when you want something from someone.  Only when you want something makes it very shallow relationship.  Do you know anything else about them?
–    Also under process I like the emphasis on the transition from establishing a relationship to going in to the task.  The delicate balance between these two processes – of course I did not see in the book any details about how to actually do this transition.
–    Working in isolation, means less communication which builds paranoia, people get anxious.  Which I have talked about many times.
–    The confusion caused by vague communication, lack of transparency, etc.
* I like the example given – an American to a Brit – “I created a “straw man” agenda for the upcoming meeting, and I have a “hard stop”, at 3:00pm”.  What does that mean?  Writing something like, “I created a preliminary agenda for the upcoming meeting and I have a deadline of 3:00pm, can you provide feedback until then”, would do.  Why do we write in the first way?  I think a lot of Americans can relate to this example, we tend to use a lot of buzz words and are almost judged on our use of them.
* I also like a lot of the comments in the book, such as why do we waste time being vague…..as there is enough distance between people!!! It just leads to a lot of second guessing…..and the need to communicate a lot more in the future….

–    With virtual teams, problems can easily be blown out of proportion!  – so true!!!
–    I like the emphasis on understanding the purpose – the book puts it out on the “purpose” of the team, or the “why” the team is doing what it is doing.  I have always liked the emphasis on the “why” as to “why” the users need to work the way they do, why the system needs to work in a certain way, but I like the emphasis on “why” the team has formed.
–    Team members tend to side with those who are located closest to them
–    I like the list of 10 Behavioral Rules for The Fun House –  10 rules I think are great for any team!

About halfway through the main portion of the book (and one too many paragraphs about Spinks – read the book if you want to know who this is), I decided to skip to the Briefing Report located in the appendix,  to see if something could be learned from reading that portion of the book only.

There are some points that I think could stand on their own if a reader was looking for a quick reference.

–    The Collaboration controller chart on pg. 187, I like the outlining of the challenges and how to counteract them.
–    In general good parts on the 6 items that make a team work well
–    Section 3 on Cooperation is good – similar to other books though, especially on giving and getting trust.
–    The general pointers part of Section 3 is good – pointers for building cooperation, although also ones you can see in other books.  But at least something you can read quickly and get some ideas.
–    Good questions for testing your readiness for managing the team and for testing the preparedness of the team members
–    I like the cultural intelligence section, section 8.   The Worldprism™ model

“Where in the World is my Team”, is certainly not an ordinary business book and it is not dry, so it is something new. One of the negatives I have often found with many of these books is the lack of real life examples.  “Where in the world is my Team?”, provides those real world examples (of course changing the names to protect the innocent!).  The bad part is that you can’t skip significant sections of it or easily hone in on sections that may be relevant to your situation.  The information comes to you in bits and pieces through reading the dialogue of conference calls, or reading email exchanges that Will has engaged in.  It is an easy read and, and I hate to say it, but I found myself wondering what was going to happen to Will’s father, but at the same time I was often frustrated with all of the “filler” stories and was skipping ahead when I could. However, if you are new to working with global teams and with virtual teams, this is a great first book to pick up. Why pick up a regular business book, when you can have a “story” to go along with it!  If you are more experienced, you can still pick up new points, you will just have to wade through a lot of “story” to get to them.

Categories: Book Review, Outsourcing SMB's, Outsourcing Ukraine, Project Management, Virtual Teams |

24
MAY
2011

Business expertise versus technical skills!

Comments (4)

In talking with a group of product managers recently about working with distributed software development teams, where part of the team was in the US and part of the team was in an offshore location, there seemed to be a big consensus that one of the most difficult issues in working with the offshore team was getting them to understand the “business side” of the system.  For example one person was very vocal about the issues with the developers in the offshore location not always understanding why the payment system needed to work in a particular way, or why the users needed to work in a certain way.  Other examples came up with billing systems and with the developers not understanding why sales commission had to be calculated in a certain way. This got me to thinking as to why this could be occurring?

According to the group of product managers the reason was specifically based on the fact that we are exposed to “how certain things” work more often in the US than in some of the offshore locations.  I agree this can be a factor with understand such things as “calculating sales commission”. Well at least the basics of calculating sales commissions, because as many people know there are many many ways to calculate sales commissions. It can greatly vary by company. So any developer would need to know what is the algorithm/s used by the company. 

After thinking about this question for a while, I started to think about how many companies search for outsourcing partners. A top priority for many companies is technical skills, which of course are very important when choosing who to work with. But I think sometimes technical skills are given a higher priority than if the outsourcing partner has related business or experience with your vertical market.  For example if your company is in the payments space, working with an outsourcing partner which has experience in that space will go a long way towards helping to overcome issues with understanding how the system has to work. Many companies when they start to look for a partner, are thinking, well we have the domain expertise, we are the experts, which is definitely true, and we can help pass that expertise on to anyone that we work with.  What we don’t have is enough technical skills.  If a company makes a concerted effort to pass on the needed domain expertise then the combination of your side having the domain expertise and the vendor having the technical skills, can work. However, in a distributed environment, passing on the domain expertise will take more effort, and it is easy for it to fall by the way side. It seems to make sense then to give, if not equal weight to both business domain expertise and technical expertise, then at least put business domain expertise in a close second place, when choosing a partner to work with your firm on software development.

Categories: Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Project Management, Virtual Teams |

1
JUN
2010

I have a “feeling” something is wrong!

Comments (0)

We have all had these types of feelings when dealing with people who are located a distance from us.  Or even from managing a project where everyone is co-located.  Maybe it is just part of being a project manager; we are looking for any possible risks that can cause our projects to fail.  Managing at a distance can exacerbate these feelings when you can’t see each other all of the time, or at a moment’s notice when the feeling comes up.  

I have heard this phrase stated in several ways:  

• “I have a feeling they won’t do what I need them to do”,  or
• “He/she said yes he will do it, or he said he understands, but I have a feeling he/she doesn’t really understand.”   Or a more general fear,
• “I have a feeling something is wrong, but I am not sure what?”

I think there are ways to mitigate these risks or feelings that can come up. One of those ways can be to ask more questions and another is to use the work completed as a guide.  

First make sure you feel comfortable with what you have asked them to do and what you are concerned that they won’t do.  Are you concerned that they won’t code something in a certain way?  Are you concerned that if you ask them to make a change they won’t do it? Are you concerned that they “can’t” do what you need them to do?  A lot of these issues are very different but most of them can be addressed by history, if there has been any history of working together, or by asking questions.   For example, if you have not been working together long, and if you have a feeling they won’t code something in a certain way, ask them for a “design” of how they plan to code the feature (for those who are afraid of written documentation, this does not mean they have to write a large document, you are not asking for the world).  This can also be done orally, and if not good enough, ask for a written explanation.  If the design is not what you expected, you have other issues, and you will have to determine and make a judgment as to whether or not the issue is; they did a poor design, it would work, but it is not how you would have done it, or it would work but it is not how it needs to be done for this application.  But at least you will have validated the “feeling” that you had and now you can deal with a concrete situation and not something abstract. 

I will review another one of the “feelings” of concern later this week.

Categories: Outsourcing Offshore, Outsourcing Ukraine, Project Management, Virtual Teams |