Archive for the ‘Virtual Teams’ Category

Continuing the “I have a feeling….” situations, and how to handle them!

Tuesday, August 24th, 2010

Continuing the “I have a feeling….” situations, there is one more I wanted to talk about which often occurs when working remotely, that is the, I have a feeling something is wrong, but I am not sure what?”  This is a harder to dissect, because it could be anything.  I have a feeling they are not telling me the truth, I have a feeling that they are not telling me something, I have a feeling they are keeping something from me, and the list goes on and on. 

Certainly these feels are exacerbated if you, as the project manager, are located remotely and the rest of the team is located somewhere else.  Or a large part of the team is co-located with smaller groups of people in other locations.

The only way you are going to “resolve” this feeling is by asking questions.  Many managers have issues with asking questions, especially it seems Americans. They often take it as micromanaging. But if you are working at a distance, with people from other cultures, how are you supposed to feel comfortable with what is taking place “over there”, if you do not ask questions.  Beyond asking, “How’s it going?”.  I think we expect to get a lot of information out of such a question, but sometimes you have to ask more pointed questions, like, “Did that design that we talked about work out for the function you are working on?” Or something like, “Did you find a work around for that issue with iTunes?”  These types of questions are not micromanaging, they are questions to eliminate the “feeling that something is wrong”, and make you feel confident that everyone is on the same page.  There is always the good question that I mentioned in one of the previous blogs on how to handle “I have a bad feeling” situation, “Show me where we are, what is done, what remains to be done, roadblocks?”, “Let’s walk through the last/current delivery so I understand where we are.”

In another example, if you have this feeling that, “they are not telling me the truth”.  Without getting too touchy feely, think about when you have this feeling?  Is it when they tell you that the project is going well, and you do not have to worry? I don’t know about you, but someone telling me not to worry, it makes me worry.  I prefer the, “show me so I do not have to worry!”  With most application development projects, developed using an agile development methodology, it should be fairly quick that you can actually “see” something, and know if the team is going in the right direction or not. If not an actual running app, but can you see something from the area in question, a written design, database design, or whatever may be relevant.

In summary for project managers, when you have these “feelings that something is wrong”: Do not be afraid to ask questions, beyond, “how’s it going today?”, until those feelings dissipate. It does not have to take all day, or even take that much time, and it will save a lot of time in the long run worrying about something that may or may not be a problem.

In summary for team members: Realize that managers and other stakeholders, who may be located remotely from you, and even at your location, need to understand exactly where the project is at, and they need you to be proactive and alert them to potential areas for issues.  Asking questions, and offering suggestions about the app being developed also lets the manager know you are thinking about the project, how to create the best app possible, and it confirms your level of understanding of the project and gives your manager more confidence in your skills.

Another “feeling” situation and possible ways to deal with it!

Saturday, June 5th, 2010

Today I wanted to continue our discussion on the “feeling” type of concerns when working with a remote software development team. 

For dealing with the situation, “He/she said yes he will do it, or he said he understands, but I have a feeling he/she doesn’t really understand,” I believe it can be handled in a similar manner attempting to obtain concrete data to support or not support your feelings.  This feeling can be common when dealing with remote teams located in different parts of the world.  If people are dealing with English as a 2nd or 3rd language they may not ask as many questions as you would like which would show they are thinking about the request, or that they understand. The person could be not as comfortable with their English skills to ask the required questions, or they could just be quiet in general, or it could be that they are afraid to ask too many questions because in some cultures it would not be good to question the client.  Therefore it is going to be up to you to dig in further and help dissipate your “feelings” that there may be a misunderstanding.  There can be several ways to start with this.  Ask your remote team to “write down” was is discussing during status meetings and send a recap to everyone in the team, after the meeting.  Review these notes to see what is understood or where there may be issues.  There is also nothing wrong with asking a team member to repeat what they heard while you are in the online meeting or on the conference call, etc.  This request can be validated by simply saying that you just want to make sure everyone is on the same page.  No one should have a problem with this type of request for better communication.  If you are not satisfied with the oral delivery of what the developer is to do, ask them to put it in an email or an IM.  These types of steps should help the PM determine if additional explanation is needed for a particular task.   If you now believe you have done all of the explaining you can do, and the developer has explained what he/she thinks should be done, you should at least have concrete evidence as to the level of understanding; i.e. here is what I told them they needed to do, and here is what they think they have to do and the two do not match.  If that is the case, it may be time to talk with your vendor about the situation.  You may need to make a team member change or you, and your vendor, may need to dig in more deeply as to why there is a disconnect.  The last step should bring even more concrete evidence one way or the other.  Once the developer starts to actually work on the feature or request, you will also get concrete evidence as to whether or not the developer understands what they are doing. More relevant questions should come up, plus you will be able to look at actual code and very quickly you may be able to look at actual results. All of these results will either help validate or alleviate your feelings that there is a misunderstanding.  

I have one more “feeling” situation I want to talk about next time.

I have a “feeling” something is wrong!

Tuesday, June 1st, 2010

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.

Avoid the “Do as I say, not as I do” syndrome!

Wednesday, May 26th, 2010

“How do I get my remote software development team to be more productive?”  It is something we all want to do, be more productive. One observation I have made with distributed co-located software development teams (i.e. more than one team located in more than one geographical location) is there can be an attitude of: “Do as I say, not as I do”. This can come from the team that works at headquarters or any team that is working in a multi-team situation.  This situation can apply to both in-house teams in multiple locations as well as if outsourced teams are involved.

We know that all teams working on the same application/product should have the same goal; to make the application the best that it can be and provide the best service to the company’s customers.  What can affect this goal is perception that one team is not living up to that goal, i.e. not being as productive as possible.  And what can affect productivity is the knowledge that there are different rules for different teams, or more specifically the enforcement or said rules.  The rules I am talking about related to productivity may be rules for design, level of design documents, coding standards, conducting peer reviews, commenting, documentation, etc.  I am making the assumption that there is one set of rules for development for the entire system, which most likely there is, every company strives for this.  But productivity, let alone motivation, can go down real quick if one side sees that they have to follow the rules and another team does not. 

It can be hard enough, but not impossible, to make distributed teams feel like they are one team and working towards the same goals, but when one side sees clearly (and in software development it is not hard to see concretely the differences) that another team is not held to the team coding standards (whether they be team specific standards or industry standards), or testing standards or documentation or commenting standards, etc., motivation goes out the door. If everyone is co-located, we tend to more easily enforce standards across a team, but it is an easy thing to let it lapse when there are several co-located teams in multiple locations.  It is easier to dismiss one team as not being productive, and to not delve in to why that may be occurring.

The fix to this issue is simple. Make sure all team members are living up to the standards the team and the company have set for themselves and for the application and system that is being built and supported. There is never any excuse for one team to get away with not following standards because it is felt they have to push some changes through at the last minute always, for example, and therefore never have time to follow the standards. In software development, what team ever has all of the time that they would like?  No team ever does. If it was truly the case where a last minute fix needed to go in, go back and make the necessary updates to meet coding standards, documentation standards, etc (although most teams would let it slide, for the good of the team, if they saw that this was an emergency situation and rarely occurred). Having one team do their own thing, and tell the other teams, well “Do as I say, not as I do”, doesn’t work for teams the same as it doesn’t work for the leaders and managers of teams. Follow the same rules for all team members, no matter where they are located, and distributed teams will work much smoother!

Book Review – “101 Leadership Actions for Creating and Managing Virtual Teams”

Wednesday, July 30th, 2008

The structure of this book is not new; i.e. one page or a page and a half per idea, but it fits very well for busy managers. I have recommended other books about virtual team management that give ideas that can be quickly implemented, “101 Leadership Actions” is definitely one of those books. You could pick up the book and open up to almost any page and find and an idea that you can implement in part or in whole for your virtual team, but you probably will not want to go through the book in that manner. Perusing the table of contents first will tell you where to start.

I found the first useful suggestions for my own work with virtual teams in the very first chapter, with something so simple that I can’t believe it I have done it before, or thought of it in such a simple manner. Leadership Action #10, Identify the Benefits of Virtual Teams, in and of itself does not sound new until upon reading further the suggestion is made to have the team itself think of why working virtually is going to make them a better team; why not being co-located is going to make them a better team. Often virtual teams which come together for a specific project may do this type of team start-up process, but think of the virtual team that develops more gradually; most development is done in one US city and then they hire an offshore person who works alone in another country, and then they add another one several months later and so on. These teams often have a harder time of thinking of themselves as virtual and it would be a great quick question to ask during a conference call status meeting, So what does everyone think the benefits are for our team now that we are virtual? It puts the responsibility on everyone to think of what the benefits are, not just the manager. Some suggestions that are made that will be helpful are actual helpful for any type of team, not just a virtual team, such as #18 “Regularly redesign your meeting structure”. Which suggests moving the team agenda around so those persons who speak always at the beginning of a meeting know they can tune out after their turn, or those who always speak at the end can sleep during the first half of the meeting. It is a great and simple suggestion to shake things up once a while so people stay awake. To give you an idea of the number of actions which you may find useful from this book, below is a chart of the number of actions I thought I could put to use or put to better use within the teams that I manage:

Chapter # of useful actions
Strategy and Virtual Teams 1
Structure and Virtual Teams 2
The Practices of Virtual Teams 6
The Tools of Virtual Teams 2
Managing Virtual Teams 3
Technology and Virtual Teams 2
Systems and Virtual Teams 0
Total: 16

The result is that I found 16% of the actions immediately useful, not bad for a book that took maybe a couple of hours to read. You may find more or less similar results. Note #80 and #86 are two very useful actions which I continually stress to managers of virtual teams and they cannot be repeated often enough; #80 “Make the Transition from Managing Time to Managing Projects” and #86 “Use the Phone More Often”. I would recommend this book to anyone managing a virtual team as a good resource which will provide immediate ideas that can be incorporated to make your virtual team run better.

101 Leadership Actions for Creating and Managing Virtual Teams
By Ollie Malone, Ph.D
Copyright © 2004

Collaboration 2.0 – A book review

Sunday, June 15th, 2008

While not news for many of us, much of what is driving the developments in Collaboration and the developments in collaboration tools is the necessity to create a Virtual Team space (VTS).  Early in the book the authors define 10 trends in collaboration, the most interesting to me is the trend which they call, “Presence Everywhere” which means being able to detect which involves basically being able to quickly find a person whether they are online or on the phone or in a conference room. A typical scenario as to when this may be useful is given (and I am sure a familiar one to everyone); A and B are working together via web conference and they need C to help solve an issue. Typically one or both A and B will be looking through their buddy lists to see if C is available online, if not both may try calling C via various numbers; office, cell, etc., and if they are finally successful in finding C it may take several clicks of sending links to bring C in to the web conference. IBM is working on their Sametime product to have this type of capability to reach external contacts. LiteScape also apparently has ways to detect the availability of users not only via instant messenger buddy lists but also from your list of outlook contacts and detect their presence via mobile devices.

If you were not already familiar with the term, the book introduces you to mashups as another trend in collaboration. A mashup is the process of creating a hybrid application built from data or functionality found across a number of different applications. An example of this can be seen in a site listing real estate, for example, which uses a 3rd party site or application to provide information about criminal activity in or around the house which is for sale.

There is no shortage of collaboration tools which the book introduces you to such as TimeBridge which can help you schedule meetings faster, but a great part of the book is the emphasis on the human aspect of collaboration. As they say, collaboration is 10% tools and 90% people.
The second half of the book takes a look at the human side of collaboration with chapter 7 specifically focusing on virtual teams. A very good point is made at the beginning of the chapter that the challenge has traditionally been how to minimize diversity among the people on teams whereas the key in the future will be to embrace the differences and work with them. I agree with this whole heartedly and would extend this to all aspects of working in a distributed manner, for example – time differences, location differences, etc.

Chapters 8 through 14 also focus on different aspects of people and processes. A lot of what was written was review on how teams work, it will most likely be review for a lot of people. What I found funny was, for example in Chapter 9 on Interpersonal communication, the author mentions how important Mirroring/Identifying is in building report, but he doesn’t go in to the next step of how you do this when using collaboration tools.

Chapter 15 is supposed to bring it all together; the human side and the technology side, but I found it a bit lacking. It talked more about the different stages a company may be at in using collaboration tools, and why they may have problems implementing them, but it did not seem to go that step further and talk about how to overcome the actual road blocks to working with distributed teams and actually using the technology.

In general this is what I thought was lacking in the book overall; actual examples or case studies of the use of tools and use of team interaction processes to overcome problems. On pg. 194, the authors discuss the work of one of their clients, and I agree it is an excellent example of an operational agreement between two distinct agencies. There is a lot of detail there, however, there are very few other real life examples given in the book. Adding additional examples and case studies, which I have no doubt the authors must have from their consulting practices, would have made the book much stronger.

My first thought with this book is that it is especially good for larger companies which are working with a number of collaboration tools, or looking to implement them. However, chapters 1 through 6 which relate to the different technologies that are available, as well as the appendixes listing a number of different technologies, can also be very interesting for smaller firms which are often working virtual from the very start of their existence. As well, for most anyone who reads this book, unless you are a study of collaboration tools you will most likely be surprised at the wide range of tools available and perhaps at what is considered collaboration technology. As far as functionaries who will appreciate this book; marketing folks can certainly get a number of ideas for tools that they can use to do their jobs better, software engineering folks, and anyone who has to deal with remote teams on a daily or almost daily basis will benefit from reading this book.

Collaboration 2.0: Technology and Best Practices for Successful Collaboration in a Web 2.0 World
Authors:  David Coleman and Stewart Levine
Published: January 2, 2008

How do I know they are really working?

Wednesday, April 16th, 2008

This is a question I often hear from people when they are dealing with a distributed team; whether it a team of software developers or anything else. For some it is more difficult to feel comfortable with the fact that work is getting done when they cannot see the people doing the actual work.  Hopefully there should be better ways of feeling comfortable with a remote team delivering than phyiscally seeing them sitting at a desk from 8:00am to 9:00pm.

Usually what I ask people when I hear this type of a comment is, “How do you know persons in your office are working?” Surprisingly the answer is not, because I see them working, but rather, “because they are getting work done!”.  Well it is the same when you are dealing with a distributed team. 

If you have agreed a schedule for delivery (and frequent deliveries) with your remote software engineering team, and they are meeting that schedule and delivering quality work, they are most likely working.

There are things you can do to help build that trust, that your team is working, as quickly as possible. If you are working with a brand new team, make your deliveries very frequent, even within the first week, have daily deliveries. A day’s delivery may be an updated work plan for the project, or a design document for a part of the work, etc., it is less important what the daily delivery is, than having work delivered every day that was agreed to.  Daily conversations are also very important at this stage as well.

As trust is built, while the team is delivering as they said they would, it should become less important to physically “see” that all workers are at their desk between 8:00am and 9:00pm.Â