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.