Introduction
As I started for the first time at a big multinational company I just felt myself totally lost. It took long month to figure out who is doing what, what does that roles mean and why are things done as they are done. Later on whenever I changed to a new company I met with totally new team structures and development models. The goal of this post is not to go into details, just to have a first overview, so that if you are starting at your first job you won’t be so lost as I was.
I also need to mention that most of the companies are using some special version or some kind of mixture of the following models.
Last but not least I need to remark that the team structure and a development model is not strongly pending on each other.
The classical development models and team structures
Waterfall and V-model
**In the old times there was no real structure of the software development. A small teams of developers just sat down and developed something without a well-defined process. Later on around the 80’s as the bigger companies and bigger software projects came the work needed to become more structured. That’s how the first development processes were born.
At the beginning the waterfall model was the most typical. That means, first the requirements needed to be set up, right at the beginning of the project. Once the all requirements have been clarified a software design has been set up and once the design was done it has been implemented. Later came the step of validation and the software was down.
The next step after Waterfall model was the so-called V-model. The V-model put more effort into validation. The left side of the so-called V is requirements, architecture/design and implementation, just like in case of waterfall. On the right side there are the different levels of testing: unit test and integration testing against the software design and system testing against the requirements.
These were the most common development models for decades. The V-Model is nowaday still used for example in automotive business.**
Functional teams
**If there are a lot of people working at a company they need to be structurized somehow. The first idea is the split them based on functional area, like: team of requirement engineers, team of software architects, team of software developers, integration team and test team. Or even more detailed, like separate developers into frontend and backend developers. And then each functional team does only tasks which are belonging to their responsibility. So that if a new project is coming all teams will work on that, but only with a small part.
As an advantage there will be a really good knowledge base in each functional area. On the other hand there is no one who has project specific knowledge, who has a good overview of the project. The communication between the different functional teams can be also difficult.
It is also not always effective, since there can be periods when there’s a lot of development task, but still nothing to test. In other periods much more testing is needed than developers. But in case of functional teams there is no real flexibility.**
Project teams
An alternative of functional teams is to have project teams. Each project team is responsible for one project. Inside the project team there can be dedicated responsibilities, like: developer, tester, architect etc. But they are concentrating always only on one project. Usually as the project is starting the team is set up only slowly, at the end of the projects the people will be moved into other project teams. A big advantage is that the all developers have a good overview of the project, it can be especially useful if there’s a lot of project specific knowledge. On the other hand the technical area based knowledge is not centralized, so it can get lost easily. It is also often the case that the teams are concentrating only on project goals and no one takes care about building up a team based knowledge based.
Matrix structure
The matrix structure is a mixture of project and functional teams. There are functional teams, lead by teams leaders, but every member of the functional teams are assigned always to a project. The projects are lead by project leaders. The team leaders are responsible to set up the team based knowledge (by trainings, hiring new members etc.) and the project leaders are responsible for the success of the projects. One disadvantage is its inflexibility.
Agile project development
Main idea of agile development
**As we have seen the classical way of development is really well-structured and professional, but really often too inflexible: there’s no way to change employees between functional area, it is complicated to change the requirements of the software, it is also reacting too slow on the changes.
So the developers started to search for new development methods which are trying to avoid the above mentioned issues.
There are several different solutions like extreme programming, lean, kanban or scrum, but there are things which are common. Agile development is usually working with cross-functional teams. That means the same team (often the same team member) is able to overtake the communication with the customer, the development and the testing, teams are not separated based on functional areas. Additionally the development is usually done in shorter cycles.**
SCRUM, Kanban and LeSS
**The most popular agile methodology is called SCRUM. SCRUM works in sprints. One sprint is usually two weeks long. Before the start of a sprint the team (usually has a size of 7 +/- 2) is planning the sprint together with the product owner. They are setting up the tasks (user stories) for the upcoming sprint by shifting them to the sprint backlog. The team is checking the status every day on the daily stand up. And I still did not mention several scrum elements, like refinement, where the team can give positive and negative feedbacks about the previous sprint and set up some actions for further development. Or the refinement where the team tries to understand the user stories better and also estimates their size. There are several good books about scrum, if your company is using scrum you should read one of such books.
The big advantage of scrum is that if the requirements are changing it can be considered in the upcoming sprint, so it can be changed within several weeks.
There’s an other agile methodology called Kanban. In this case the work is executed based on a so called Kanban board. The Kanban board has three columns: To do, In progress and Done. If a new task is coming to the team it will be added to the To do column. Once someone is starting to work on that it will be moved to the In progressed column. Once it’s done it will be moved to the done column. To focus more on the tasks the number of tasks in To do column can be limited. The Kanban table is popular, that it is used at other agile methodologies as well.
I also need to mention LeSS, which stands for Large Scaled Scrum, which is basically an adaptation of Scrum for big projects.**
Cross-functional teams
In agile development environment cross functional teams are typical. That means there are no dedicated role for testers, frontend/backend developers, architects etc., but each team member can take over any kind of tasks. That means it can be that in one sprint you are implementing tests and in the upcoming sprint you are working with backend development. In the cross functional teams a closer cooperation by doing pair or mob programming (programming in team) is also typical. This way of working makes your team much more flexible, because it can use its full capacity for any kind of tasks.
Summary
As I already mentioned this topic is really complex, I could write a series of books about this topic, but currently I tried to give really just an overview and make it possible to understand the difference between traditional and agile development.
Top comments (0)