Agile Team Organization
Projects go wrong all the time. There are, usually, several reasons why a software team will fail on any given project. There are several statistics available suggesting that somewhere in the range of 68% and 80% of all projects fail. Agile processes have tried to mitigate this from happening often with significant success. From my experience, a well organized team is often one of the early steps to take to help avoid making a project turn into a disaster, or in some cases, to recover when a project is approaching disaster.
So, how to go about it. The first thing to understand is how each role plays a part of the team. The team size isn't important for the moment, but there is a minimum size that seems to make sense on all of the successful teams I've been apart of. Here are the roles as I would describe them.
With nods to the Scrum process, we will use this term while attempting to be agnostic of a particular process. So, regardless if you happen to be using Kanban, Crystal, XP, or something else, this particular role frequently shows up. This role is the one responsible for holding the team accountable to the particular process in use, for gathering and reporting team metrics, for removing things which block development, and for managing team conflict. There are perhaps a few other things this role should manage, but in general, this list is sufficient. The person in this role should be very knowledgeable about the process the team is using and be it's champion. This person should have enough management authority to be able to remove blocking items and good communication skills to facilitate discussions with other teams or managers when doing so. However, this person should not be in the chain-of-command for anyone else on the team. We all would like to please our boss, so if our boss is the person in this role, we potentially prioritize our life to makeing sure the boss likes us rather than for the good of the team. The team is more important.
This person is the champion of the project itself. This person represents the Stakeholders, those who are paying for the project, understands clearly the requirements and can articulate them. This role is accountable to the team for making sure requirements are well understood and clearly documented. During team demonstrations with the Stakeholders, this role is responsible for being the team champion and helping the stakeholders understand the value being delivered as described by the demonstration. The person in this role should be able to answer questions from the Stakeholders, understand how requirements are changing and be able to turn that information into requirements for the developers if appropriate. This role is often assisted by a similar role, the Business Analyst, or Requirements Analyst who does most of the actual work of documenting the requirements.
This role is the technical person who will be delivering the requirements in working software in an iterative fashion. This role should be versed in all technologies used by the team and be able to deliver working software using any or all of them.
This role is responsible for making sure the requirements are met. The person in this role is able to clearly articulate where software falls short of meeting a requirement or where a gap exists in the requirements. Perhaps the software as delivered meets all the requirements as written, but during testing it failed in a way not accounted for when the requirements were written.
Team size will largely depend on the size of the project, but generally a minimum number is around five or six members. Of the roles mentioned, Developers usually have the higher number on the team, thus 1 Scrum Master, 1 Product Owner, 2 Developers, 1 Quality Assurance. Team size will grow if the project is larger or when more needs to get done sooner. Keep in mind, adding more team members late will slow down the team temporarily, so starting with four developers is better than adding two later. It is also very important to be as cross-functional as possible. This mostly applies to the Developer and Quality Assurance Role. Sometimes it isn't quite possible due to company organization, but the attempt should be made whenever possible.
Additionally, the Scrum Master and Product Owner should be able to handle the other role in a pinch. If the Scrum Master cannot be at a meeting, the Product Owner should be able to fill that role and vice-versa. If neither can be at a meeting, one of the developers should be able to fill the role.
Consider the teams you have worked with that were successful, and more importantly, those which were highly successful. This blog largely comes from my personal experience with a few highly successful teams I have worked on and is in contrast with other teams not built this way which were not successful. Some were out-right failures. The team failed to work together effectively, the project failed, everyone was mad and everyone lost money. The whole point of agile processes is recognition that this kind of thing happens far too often in our industry. Adapting to change, having clear requirements for at least the next iteration, overcoming exactimates and missed deadlines by adjusting for unknown or unforeseen problems when they arise. Every successful team I have been on has delivered real value, and been much closer to the projected cost estimate (sometimes even coming in under it!) than the teams which expected to be able to live on a Gant chart. While effective team organization is not the panacea for all situations, it is certainly a good place to start when ramping up a project or trying to get one back on track.