In traditional, waterfall organisations, a development team follows the organisation hierarchy. The development team can be split into smaller sub teams and each of those teams can have their own leader, but ultimately the hierarchy still exists. Developers usually stay in that sub team for most of their time in the organisation and they know exactly who their line manger is and who is responsible for their reviews and can act accordingly. The organisational structure is rigid and embedded into the process of the team and organisation.
In more agile teams, the organisational structure is less rigid meaning that developers do not need to stay in a single sub team for their time at the company. They can be organised (or organise themselves in more advanced agile cultures) into teams based on skills. New developers are hired with a view to how they can benefit the wider team and not towards the skills needed for a sub team in a waterfall environment. Even though there are less restrictions on people moving between teams, it is not always guaranteed. It can happen when required, e.g. when a new member of staff is hired and the skillsets need to be spread evenly. This can evolve further.
Can agile teams be formed around projects?
Simply, yes. This is actually how projects work at Facebook. When a developer joins the company, they can request what team they want to join when their ‘boot camp’ is over. Each developer has a desk and that desk is on wheels. Their office is completely open plan. When a team’s project is finished, the developers simply break up as a unit and wheel their desks to form the next team for the next project.
I’ve talked to a few people about this fluid team structure. All responses seem to follow the questions:
- If a developer continually moves around, who is the manager responsible for the developers review?
At school, I was part of a form group and I had a form tutor. This was the class I was part of each morning between 0900 and 0910 and where registration would be taken. I didn’t study all my subjects with that class or that tutor. Each teacher had their own area of expertise. I moved around when I needed to go to a class. The same can happen in the workplace. In an agile team there should not be any need to micromanage members of the team. Just because you don’t sit beside your line manager doesn’t mean they cannot manage you. They need to form a trusting and communicative relationship with each other – characteristics of an agile team. This will allow the manager to know exactly how the developer is progressing and any obstacles in their way.
- What happens if a project ends up with all the weakest developers in a development department?
If you are happy to hire weak developers then I suggest a look at your hiring process may be a useful thing to do. If a developer is not hired because they have the correct attitude, skillset and cultural fit for your team or you are happy to hire the ‘best of a bad bunch’ then you may have bigger issues than worrying about the formation of sub teams.
To summarise, you don’t need to keep developers locked to a team or a line manager. A trusting and communicative environment should always allow the team to focus on what they were hired for, the delivery of software. After all, if you are not here to care about the quality and standard of your work, then you should really think about changing career and stop wasting your employers money.