Introducing the agile software development methodology to companies or even to individual projects sometimes proves difficult. You might think it would be easy in a small company as there are less minds to change but it is often easier in a large company.
In this article, I will share my experience of how and why to restructure your development resources for small or large software development departments. It’s written from a point of view of the person responsible for organising the resources and projects at a company and introducing agile teams to take on the work.
Getting Started
If you don’t already have it, the first thing that you will need is management buy-in. Tell them what agile is, how it will work and the benefits you will gain. I’ll not cover that here as that is not the purpose of this article. Management buy-in is important to get the understanding filtered down to the people that you will be working which could be clients, contractors or other internal departments.
Clients need to understand how you will work with them and most are happy to do so as it gives them early visibility of the product and a say in its direction as it evolves. However, the sales team that deal with the client relationship (especially early on when winning the business) we need to understand the agile process and be able to communicate this with confidence. External contractors tend to work whatever way you want. Internal departments might need some persuasion as they will have their own processes that you might be disrupting.
When setting up an agile team for a project you need all members to work closely together as communication is key. They will meet regularly to resolve issues and plan out what each member will do next. That team will live and breathe the assigned project until it is completed.
Small single team
Unfortunately, if you only have a small development department, that means everyone being tied up on a single project. You will probably have a team of eight but if it’s smaller, you may have to double up on roles. Let’s say you have one backend developer who doubles up as a DBA. One front end developer who doubles up as a designer. A development lead that pitches in all over and doubles up as the project manager. Finally, a business analyst who doubles up as a quality assurance tester.
Just in case you are wondering what the test ratio should be. I’ve found that most teams work well with one Quality Assurance tester to 3 software developers. In the doubling up example, the dev lead and two developers are each 50% so equalling 1.5 full time developers and that means the BA/QA needs to spend 50% of their time on testing and 50% on analysis.
The small team (whatever the size) can receive the vision and work using an agile methodology until that vision is realised. However, if something new comes in, the team will have to wholly switch to the new project or try to juggle two projects at the same time. One team with two simultaneous projects is not impossible but needs very careful management to make sure that time is managed appropriately.
Time-boxing
Time-boxing might help here where you set an allocated amount of time to a task during a set period and switch to the next at the end of the period regardless of task completion. In this case, the project manger will need to really be on top of things. If it is only two projects one in the morning and one in the afternoon can work.
If there are more projects and you start getting to hourly time boxes then your production will suffer. Developers tend not like to be forced into time-boxing as most want to finish what they are working on but if you have a small team and multiple projects you need to enforce that discipline. Only don’t do it too often as people that are treated like robots will not have any passion for the product they are working on. If you have many competing requests of equal importance in a singular product development team, it is probably better to devote a day to each before repeating the cycle.
Issues with single small teams
One problem with a single small team is there is no redundancy built in. So, if one-person leaves, has an accident, is sick or just needs a vacation then it all falls down until they return or get replaced. Replacing is not so straight forward as the new team member needs to get up to speed with the project.
Another issue with single small teams is that there are no career prospects for the team members. As they grow in confidence, ambitious software developers will seek out new challenges and quite often look to bigger teams, companies, departments to get exposure to more. It’s not usually jumping ship for another small team but if a company is happy being treated as a stepping stone or even encourages it, that is fine. Expecting career stagnation is not.
Agile project coordination
However, in larger departments you can build some redundancy across teams but it is more difficult to build in career prospects if each team works as a single unit. That is where agile project coordination comes to life. Team members belong to functional teams and are managed as such. Functionally managed teams (based on a particular discipline) will provide the resources to multiple agile project teams.
So, rather than say 5 teams each with a manager/project manager and each made up of developers, design, analysts and QA you have the management teams based on discipline and use resources from these on your agile projects for a set duration.
Functional managed teams
Functional managed teams are better for the team members as their leaders will be able to set realistic achievement goals and be able to train them where they fall short. Not only that but they can provide help in a sometimes isolated and stressful situation (the team member has someone they can turn to that really understands).
The actual product development is done within virtual teams that are pulled together to meet the project objectives. The team leaders can also play a role in the virtual project teams as shown in the illustration below for five teams made up of resources from separate functional teams shown in the illustration above.
Mixing it up
There will come a time when team members become bored or the project is not satisfying their needs. They might be getting paid for doing the work but money is not everything especially to software developers. They want new challenges and if they are not going to get it at your company, they will look outside.
So, after say three to six months, mix it up. The PM should probably remain on the project but switch out some members to make it more interesting and to share the knowledge in case of absence.
Benefits of functional teams
Doing it that way, the people in the functional teams will get career opportunities. For example, a QA tester in a project-based management team, has no chance of a significant promotion. Whereas in a functional team where everyone is a QA, they can learn from each other, show mentoring and leadership skills and get promotion that will be significant amongst their peers.
Of course, knowledge sharing is another benefit of switching people in teams at a time that suits you as a project coordinator rather than have it forced upon you by sudden absence. You can have the person that is joining the team slowly inducted. If you don’t have the resource capacity then have the person vacating the position available to the person joining the team in the early days.
Other benefits
Having functional teams has a training benefit. The team manager can make sure that all team members are adequately trained as new methods or new products are available to help them do their job more efficiently. You hardly ever get the appropriate training to help your career if your manager belongs to another functional discipline.
It also makes the job more interesting and gives team members something to look forward to. There are plenty of boring projects as well as plenty of interesting ones. If you get stuck on a boring one but know it is only for three to six months then you are less inclined to look elsewhere.
Finally, mixing it up should make team members focus on documenting what they have done naturally. This is especially so if they are having to answer questions when they have left that project because they didn’t document appropriately as they went along. All new team members should be reminded of the importance of good documentation and what it would be like to like to inherit a project from a lazy documenter.