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!
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.