Archive for the ‘Project Management’ Category

23
APR
2013

“Distance is dead, but time zones are not!”

Comments (0)

I do not 100% agree that the issue of distance no longer exists; however I agree time zones are here to stay! According to the authors of, “I’m working while they’re sleeping”, we do not have a problem communicating across distances because there are so many tools available to ease this process, however, issue of differences in time is still there and will remain. Even some of the evidence the authors present in the book, on team dispersion versus productivity, refutes the claim that the issues of working across distances are all in the past. This part I did not get….. One of the examples given was the issues teams experience, even when they are located in the same building, efficiency still goes down……probably due to people thinking that less effort is needed if you are in the same building. I think we have all seen this, even with a difference in floors, in the same building, there tends to be knowledge on some floors that has not been dispersed to people on other floors. However, the authors gloss over this issue for the book, stating there are no more issues across distances, but rather concentrate on talking about the issues caused by time zone differences.

This is the third book which Erran Carmel has been an author on, which I have reviewed. Therefore I was anxious to take a closer look at it. For me it was the first book that I have seen, that concentrates chiefly on time zone differences. I am vacillating as to who is the best targeted audience for this book? After reading through, I am thinking it would be most beneficial to those who have already worked, at least once, with teams across many time zones. The situations discussed would be very familiar and it would be easier to pick up tips of what to do next time, than to pick out planning tips that could be used for your first “distributed across multiple time zones” team. The authors seem to elude to this as well, that time zone differences and how to deal with them, is not a concern until it becomes a problem; i.e. not usually seen as an area to talk about upfront when starting a team. However, I do see this as a book that could be very useful for the person who is looking to become, or has been tagged to become the “global liaison”, as the author’s refer to the person who works between teams in different locations (this person could also be the product manager, project manager, project coordinator, or have a host of other titles).

The book itself is broken up in to three sections: The Fundamentals, Time Zone strategy, and the last section is titled, “Time and a Half”. I had to laugh at the comment in the section on fundamentals, about outcomes, and that, “The advantage of distributed work is that you can blame distributed work for the project being late……”. An excellent point is made, that bears repeating, that we need to understand when coordination is truly necessary. One team may be effectively coordinated but at an extraordinary cost, thereby driving team performance outcomes down. A good example of this is when a coordinator (or global liaison) manages too few people, not an optimal number; the cost is high and the performance is lower than it could be.

An oft repeated topic in books related to virtual teams, or global team management, and frequent topic of conversation among project managers is a discussion of the pros and cons of complete time overlap for a team, versus receiving at least some benefit from only having some overlap (not in the follow the sun type of way or round the clock meaning, but just two or three hours of overlap). Working during the same time, of course provides the widest window for same-time interaction, but it also leads to more interruptions. The authors add further research to this discussion that gives food for thought. Having some kind of a time difference may force the team to establish better practices, which includes having some quiet time for individual team members. This is where the question comes in. What is better for the team members? All knowledge workers and team members will have an opinion on this. It is seen as a benefit of distance that less time overlap means less interruptions, or at least interruptions can be more planned. It is a well-known fact that interruptions cut down on productivity, it is harder to get back to what you were doing before after every interruption. However, the book contains interesting research that shows that 44% of the interruptions we face during a day are self-imposed (checking our email, checking Facebook, getting a cup of coffee or tea, playing a game of ping pong (one of my favorite interruptions), etc.), and that actually with interruptions, we tend to be more productivity. We tend to try and make up for interruptions and work faster. However, allowing for these interruptions does tend to raise our stress levels. So it seems that because of 44% of our daily interruptions are self-imposed, we tend to work harder, and be more productive. However then the other question I have is, if 56% of our interruptions are not self-imposed, do we work harder to make up for those interruptions as well? The experiments do point to the fact that the social interruptions may be very beneficial (whether virtual or face to face) for generating ideas, or to get a break from a difficult problem and come back with a fresh head and perhaps a new way of looking at the problem. This I think we all know from water cooler or kitchen discussions which pop up during the day and that can be very helpful. Appendix D continues the discussion on the science of interruptions and is worth the read.

You will want to pay attention to the time zone strategies introduced, some of which are familiar; Follow-the-Sun, Round-the-clock, and real-time simulated co-location. As well as the six time-zone configurations that are discussed. The authors discuss examples to determine what works best for what type of activities; i.e. can software development really be done using a follow-the-sun strategy, i.e. every shift is handing over work to the next shift. As many people know in this industry, this strategy has been tried and tried again. Technically it can work in certain situations and with the right structure; i.e. the right combination of developer sites, to reviewer sites, so one location does not become a bottle neck. The authors discuss examples of companies which have tried this method; what worked, what did not work, and how they eventually tried to sort things out.

A benefit to reading the book is to pay attention to the benefits and target activities for each time zone strategy. For example according to the authors, the Follow-the-sun strategy, which involves; unfinished work that is handed off to the next sit on a daily basis, it is about speed, sites are very dependent on each other. Works best for activities like: Rapid prototyping – creative task, with serious coordination.

However, I thought it was very interesting that based on the examples used, the authors drew the conclusion that with follow-the-sun quality goes down. The reasons being that the tasks are more complicated, maybe there are more questions, and the team cannot ask them during the day, so they are guessing, and guessing wrong. What I am wondering is, especially in a situation like rapid prototyping, can any benefit be gained by a follow-the-sun methodology? Is there any benefit to having the team work in a silo (at least for several hours in a day)? Would you, or could you get something unexpected, that turns out to be better than what was planned for? Instead of direction coming all from one location or one source, ideas come from many locations with different backgrounds and differnet takes on the project, which could make for a better product in the end? I am wondering if this theory has been tested. I suppose it has somewhere, just need to dig for the results. I am also curious if the “reduction in quality” that was sighted for follow-the-sun, has been full researched? What do they mean by quality? Sometimes it means the product was not done the way I would have done it. If you are going to be working on something like rapid prototyping, global teams should have a lot of autonomy to make decisions on their own. That seems the only way to get the full benefit.

It was also good to note, and get straightened out that may global teams think they do the follow-the-sun approach, but if they are doing any part of a parallel approach or phase approach, then they are not really taking advantage of time zones. i.e. this location is working on this independently, and this one is working on this independently. The workers just happen to spread across the globe. That is not true follow-the-sun. Another key of course to making follow-the-sun really work, is to have the right development methodology. The authors believe that agile works the best- short time bursts, iterations. I think the key here is that the team is big enough that some function is always being fully developed and fully tested each day and can be delivered continuously. In this way the different time zones can concentrate on development, testing, and review and acceptance. The authors make a good note for agile development which is that personal time-boxing curbs perfectionist tendencies, procrastination and prevents an individual from over committing to a task.

Finally in the last part of the book, the authors offer two radical options for handling time zones. The first strategy is to establish a 24 hour culture within a company. People who work all hours are supported, but it is important that anyone in the company realizes that at any time they may have to work night or day, depending on when the client is working. The question is, can this be sustained? The second radical strategy is to engage in Real-time simulated co-location (RTSC) (of course this one also really requires the 24 hour culture…….). For this strategy, always on audio/video is required, something similar to Cisco’s Telepresence. Also needed is an awareness technology such as a shared dashboard to look at key project data. Co-located teams work in the same room, where developers work together, elbow to elbow. The rule for co-location strategy is (near) perfect time overlap. Video overlap screens let anyone look at who else is working. Then you can just walk up the screen and call the person you need to talk with. I think some teams would like this, to be able to see who is working and to know if they can bother that person at that moment with something. Would it lead to more spontaneous discussion like a discussion the kitchen, I am not sure. Also, what does this feeling of being “watched” do to the developers? It is one thing to be in the same room with people, where everyone is getting in to their own zone, but to know that in the back of your mind, a camera is on you……not sure. It may seem more like something to be used by management, just to see that people are working, rather than as a tool for more collaboration. But I think this perception will be changing. In any case, both of these strategies require a literal 24 hour culture, and who is going to be the major time shifters? That will be a power struggle between locations, and between countries. So I am not sure either one of these strategies, as described in the book, would be the answer for the long term. I do agree though, because of technology improvements we will continue to move in the direction of being able to walk up to a wall and seeing who is working thousands of miles away and connecting with them immediately (as opposed to what we now which is ping them in skype or call their phone and see if they have some time to talk).

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

29
MAR
2013

Sharepoint, what can it do for you and why?

Comments (0)

Thank you Kostya for your insights in to Sharepoint; what it is best for, etc. Also thank you to Olga for interviewing Kostya and providing this write-up.

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

28
FEB
2013

Coming soon to all Planeta Kino IMAX movie theatres in Ukraine…

Comments (0)

Ticket scanning at the movies in Ukraine!

We recently developed a new iOS ticket scanning application for one of the cinema networks in Ukraine! Thank you to Yevgen V., Denys K. and Vitaliy I. for the great job they did!

This app is using the Linea Pro scanning device, along with an ipod touch (it also works with iphones), from Infinite Peripherals.

Infinite Peripherals also has a new scanning/credit card swiping device that can be used with ipads! Here is an example of how it is being used.

Categories: entrepreneurs, Linea Pro, Mobile Development, Outsourcing SMB's, Outsourcing Ukraine, Project Management |

27
DEC
2012

Akamai’s Content Delivery Network

Comments (0)

A big thank you to Ivan K., our Sr. Engineer/Team Lead for sharing his experience on working with Akamai’s Content Delivery Network (CDN)! A great write-up!

Categories: Outsourcing Ukraine, Project Management, startups |

31
AUG
2012

How important is that daily check in with your team?

Comments (0)

The answer is VERY!!  I cannot stress it enough that a daily check point is needed for the majority of software development projects and this becomes even more important when part of that development or work is done remotely.

Many companies already use the agile development methodology and have daily stand up meetings, in other words, what did I work on yesterday, what am I working on today, what issues, if any, am I having that I need help with.  These are really standard questions that have been asked in status meetings for decades, now this process is called the agile methodology….but that is another story.  However, there is something more important happening during these meetings. The possibility for real time discussion! Let’s say for example that this status, instead of being in real time, is given via email, or posted in an online collaboration tool. That’s great, but if someone writes in their status, worked on item #3768. Ok, if you are the manager of the team, yes of course you know what item #3768 is, but do you have the opportunity to discuss with the developer, how long it will take to finish that item, or what solution are you using for that issue, or to ask other questions.  Yes you can do this via email, but no matter what that will take MORE time that just a quick conversation in real time, and the one issue most managers will say is that they never have enough time. So it continues to confound me why some managers do not want to do daily real time discussions?

Some of the reasons most often given include:

  1. I don’t want to get up that early or stay up that late. I can definitely understand that.  But for many situations, if the time difference is 10 hours, for example, one side can get up a bit earlier, or one side can stay a bit later at work, and it is not that inconvenient.  When you get in to fifteen hours’ time difference things can get a bit more tricky one party will always be inconvenienced. I once worked with a company in Arkansas and was living in Irkutsk, Russia, a fifteen hour time difference.  We had our daily meetings at 9:00am CDT and 12:00am for me in Irkutsk.  That was a bit one sided. I would not recommend that for teams, at least not on a permanent basis. It could be that way for a week or two weeks and then switch to something like 7:00am CDT and 10:00pm Irkutsk time. At least move it around a bit to not inconvenience one side all of the time.
  2. I do not want to talk in real time.  Believe it or not there are people who do not like to talk in real time. They would prefer to receive an email and then think about it and then respond. On one hand this is understandable especially when there are differences in native languages. However, no matter what the asynch communication of email or posting messages in a collaboration tool still takes more time than synchronous communication. Depending on the project being undertaken or the phase of the project, nothing can replace real time communications.

In short though, no matter what the situation, nothing can take the place of real time communication. If you are wondering what may be going wrong with your project. Start talking every day and digging in to what is happening; you will be on your way to a more successful project.

Categories: Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Project Management, Virtual 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 |

6
JUN
2012

How Communication Eliminates Nightmares During Software Development Projects

Comments (0)

Entrusting the development of a web-based application to a software services company, with their programmers located outside your home country, can be a fearful proposition. The application needs to be right, the code needs to be flawless, and the vision for the final product needs to be executed properly. But equally important is the provider’s ability to keep the client comfortable and confident throughout the development process. This is achieved through making communication and responsiveness a top priority.

Communication should begin from the very first contact with the company. Do they return a sales call? If not, that should raise a red flag. If the company doesn’t respond to a client when they are seeking service, there can be little confidence that the company will respond to questions or ideas about the product they are developing.

The goal of communication for a software services provider is to make the client feel like a partner in the process. It should eliminate the guesswork and focus on what the final product will look like and how it will function. In some instances, a vendor relationship, where the client asks for something and the product is simply delivered, may be all a client needs. But when a new and unique application is required, the client needs to feel invested in the development process, and they need to feel like a partner in that process.

When a client pays for the expertise of software developers, they want to have input into the process. They need their provider to be responsive and to tell them when ideas don’t make sense or when there is a better solution to a problem. The goal of the services provider should be to make development a collaborative process with the client and allow for fine-tuning throughout development. This sort of constant interaction ensures that there are no surprises when the final product is delivered.

Softjourn approaches communication with its clients with unconditional responsiveness. Phone calls and emails are always acknowledged and returned. Softjourn prides itself on making the customer feel important in the development process, because they are. The client is the person or company that has the vision about what they want from the project and it takes constant communication to fully grasp the goals they have for their tools and software. Ultimately, the better the communication and responsiveness, the better the final product will be.

There is little debate that remote software development is a viable and cost-effective way to get development work done. Typically, hiring equivalent talent and expertise in-house can be expensive and superfluous. But the provider should provide more than mere execution; they need to communicate and collaborate with the client to make the best of everyone’s expertise: the developers’ expertise in creating applications and the client’s expertise about the tools they need for their business.

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

31
MAY
2012

Qualities of a Great Service Provider/Partner!

Comments (0)

There have been a lot of nightmare stories circulating about working with remote developers and web-based applications. Many companies describe running into challenges with time differences, language, and the quality of code in the final product. So how do you choose a great software vendor to work with?

Many software services companies promote their use of the Agile methodology, but what’s more important is how they actually employ it. Their ultimate goal should be to collaborate with the client and keep them aware of the work being done. If you choose to work with software developers outside your country, you don’t want to sit and worry about what is happening with your project and feel like there is nothing you can do but hope it is what you asked for.

Softjourn stresses constant customer interaction and frequent deliverables in their use of Agile. This means you will continually see the product as the project evolves, and you will be able to provide feedback and request changes. Dependent on the project time-frame, Softjourn schedules regular delivery dates, so that you can view the progress, as well as weekly conference calls to further involve you in the development process.

Another trait of a great software development firm is their ability to understand a client’s vision. You may not know great code from bad code, but you can envision the end product you need for your business. That’s why it’s so important for a service provider to be able to translate your vision and needs into the appropriate programming and applications. This skill should be easily identified during the bidding process. Offshore developers should be able to take your brief mock-up of the product and requirements and be able to return to you with ideas about how to achieve it along with detailed questions that indicate they really understand you. After all, you are hiring a services company for their contribution of expertise, not to just simply fill an order.

Perhaps most importantly, your service provider needs to prioritize communication. As mentioned earlier, this should be demonstrated by their approach to the Agile methodology: communication with the goal of developing a collaborative relationship with the client. Another factor in communication is responsiveness. Do they always return your phone calls or emails? Do they make you feel like an important client? This is an area in which Softjourn takes great pride. Through strict attention to communication and making the effort to partner with their clients, Softjourn is able to solve problems before they exist. And, to ward off those fears of any language barrier, Softjourn provides the client with a liaison for meetings with the programming team to increase the client’s level of comfort.

It’s important to remember that a software services firm can offer more value than cost-savings alone, if you choose the right company. A vendor that doesn’t make you feel like a small client can mean big returns for your business and your investors. How is your vendor treating you?

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

8
MAY
2012

The Challenge with Dynamic Teams!

Comments (1)

Last time I talked about what could be some of the benefits to a company if they decide to work with a dynamic team, and a dynamic team versus a dedicated team. This time I would like to take a look at some of the challenges for a company when using this model.

To start I want to give an example of a dedicated team scenario and that same scenario with a dynamic team.

Let’s say a company has a one person dedicated team, and let’s say it take a developer two months to get up to speed on the company’s application. Once the developer is up to speed, all is well, and they can work very fast. But then suddenly after one year, they leave. In a best case scenario two weeks are needed to get a new developer in (if one was waiting in the wings to give notice at their current job and start with the company right away – always happens right?), and then two months for them to get up to speed on the company’s application. So the cost to the company in lost productivity could be approximately two months of fully loaded salary while the new developer is getting up to speed plus two weeks with no one available.

Let’s look at that same scenario and how it may differ if the company was working with a dynamic team. One year ago the further development and maintenance of the company’s application was assigned to a 5 person dynamic team. During the first two months all 5 persons touched and got to know the company’s application as a result of working on adding new features and fixing bugs. Knowledge was shared during pair programming, daily status meetings and code reviews. After one year, one of the five persons leaves the team. A new developer is brought in to work on the five person dynamic team and begins to learn the company’s application. There is no loss of productivity while the new person is getting up to speed, as there are 4 other person’s with knowledge of the system.

If you compare the two scenarios then the dynamic team scenario sounds ideal as there is no lost productivity. But is that always the case? What are the challenges or risks in working with a dynamic team?

The biggest challenge that always comes up in discussions about dynamic teams, and the one I want to focus on here, is that in a dynamic team, no one developer gets to know the system inside and out, because they are also working on other systems at the same time. Looking at the scenario above, we can assume approximately 2000 hours of new functionality were added to the system in one year. For a dedicated team of 5 persons, each would have worked on the system approximately 400 hours (it is also assumed of course that they heard about the system via code reviews or status meetings or common discussion of issue meetings, etc., as well), versus 2000 hours for one person, in the case of the dedicated team.

Who is going to know the system better? There can be nothing to make up for the experience gained by working with the same system daily. Therefore we can agree that the dedicated team is always going to gain better individual knowledge of an application, especially in the short term, there is no way around that. But in looking at this challenge we have to look also at the risks or challenges with dedicated teams. One was referred to before in the scenario, the risk of losing that one or two persons who have all of the knowledge. But there is also another possible risk; the downside to daily work on the same system day in and day out. Here I enlisted Anatoliy Okhotnikov, Softjourn’s Head of Software Development, again for our discussion on the challenges with dynamic teams. According to Anatoliy, “Consistency is better for a person who works in some fields of technology, but projects must be rotated to bring in new talent and continually improve developer’s skills. People who work for a long time with a single project become stagnant and their efficiency and effectiveness drops as they start to lose interest and get used to a routine.”

I would have to agree that this could be an issue with some projects and certainly with some developers. Some developers like and need change more often, they like to continually be working with different projects it helps them develop different skills. But there are certainly some who like to work with the same system and really get to know it and be an expert in it. If you are able to find that one or two developers who want to stick around for a long time, that may be the way to go, but is that reality and always possible? As well what do you do when they want to leave, which they will want to do at some point? Whether you choose that a dynamic team is right for you, or if you prefer a dedicated team, will depend on which risk is more acceptable to you; the risk of losing all knowledge at one time, or the risk of maybe not having that go to person or persons who immediately know every single detail about your system.

There is another question I would like to explore some time, regarding dynamic teams. Is there an optimum dynamic team size that correlates to the size of the system that is being supported? Or perhaps correlates to some other aspect of the number of new functions to be developed over x time period? But that is a question for another post!

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

23
APR
2012

A Dedicated Software Development Team or maybe a Dynamic Software Development Team?

Comments (1)

No one these days, especially in software development, is unfamiliar with the agile development methodology. As well clients looking for software development services are very familiar with agile, well at least with the word agile. But they may be unfamiliar with how it affects their projects and how it affects what gets delivered to them and when. What they also may not realize is that there are several agile delivery frameworks, and many variations exist with vendors putting their own spin on a particular framework. In this post I wanted to explore what is considered one of the more advanced agile delivery frameworks, the Dynamic Systems Development Methodology. The dynamic method can also be used for other types of projects, not just software development, but here I wanted to focus on software development projects only.

I picked this methodology to talk about because many companies would like to have a dedicated software development team; i.e. have a specific group of developers who only work on their products and who can get to know the company and its people well. Many start-ups and small and medium sized businesses like to work this way, and for many it can work out great. The Dynamic Systems Methodology is an alternative to a dedicated team, which may be more effective for some companies, especially when the dedicated team size would be small.

To help explain the dynamic systems development methodology, I enlisted the aid of Softjourn’s Head of Software Development, Anatoliy Okhotnikov, asking him several questions about this methodology. The discussion of this methodology will be done over a couple of blog posts, starting out with more details on what it is, some of the benefits for a company if they decide to work with this model, and moving in to the challenges.

1. Explain to us your role and duties and responsibilities within Softjourn?

My position is the Head of Softjourn’s Software Development Department. My responsibilities range from establishing team work processes and providing continued education on such topics as secure web development, to analyzing new projects, and researching and architecting technical solutions.

2. You advocate a dynamic team model for certain types of companies. Can you explain how it works?

The Dynamic team model works in the following way: a vendor does not provide just bodies to companies (the dedicated team model), but rather delivers functionality. For example, instead of having a dedicated team of two persons, a company may have a pool of 5 or 10 programmers available to them, who have some familiarity with their product and deliver by functionality. Functionality development, for a particular client, is not assigned to the same two person team all of the time, but rather it is assigned to a pool of developers and then to individuals in that pool based on skill-set needed to develop particular functionality and based on availability.

Companies looking for software development services, may pick up on a key here which is that more developers in the pool have “some” familiarity with the product and project, rather than just the two persons who may be on a dedicated team. The pool of developers share the knowledge about the project during code reviews and demos, by doing pair programming, by rotating team members, etc.
The plus for a company who agrees to work with a dynamic team is two-fold:

- Less interruption if one developer leaves the team. There will be several other programmers available who are familiar with the system and who can work on the functionality of their products; they won’t be losing all of the knowledge.

- The ongoing development and maintenance of any system can take different technical skills. Within a pool of programmers, there will be varying skill-sets, and it will be easier to put the best skill-set on to the right project to complete specific functionality than could be found in a dedicated team of two persons. Odds are that two persons are more likely to have less experience with different computer languages, frameworks and tools, than a pool of 5 to 10 programmers.

Another implication with this model is a smoother team load. If there is a situation where the team needs to speed up and deliver faster, additional resources can be more easily added than with a static team (he reason being of course that “some” familiarity.) With the dynamic model it is also harder to overload a team member which in theory leads to more job satisfaction. The more satisfaction the developers get from their work, the higher the quality of work they are able to produce. With a fixed team, sometimes people may be overloaded and stressed, they start to make mistakes and the quality drops. On the other hand if they are under loaded, they may get bored, lose interest in the project and the quality will drop as well.

Based on the discussion thus far, it seems there are some benefits for working with a dynamic team versus a dedicated team. However, this model is not without its challenges for companies who agree to work with a dynamic team, nor for the vendors who provide this model. These challenges will be discussed in the next post.

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