Agile Team Organization

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.

Concepts

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.

Scrum Master

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.

Product Owner

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.

Developer

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. 

Quality Assurance

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. 

Organization

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. 

With a cross-functional team, however, there should be no expectation that any single role can do all roles exceptionally well. A developer is one because that is what they do well, a person in that role should be able to do the role of a Quality Assurance person, but perhaps not as well as the person whose primary role is Quality Assurance. Of the developers, if one is a UX developer and one is a backend developer, the backend developer might be able to wrangle CSS and Javascript, but perhaps not as quickly or as well as the UX developer. It is important to avoid having silos on a team, so encourage the team to take on any necessary work to avoid that. It is also important for the team as a whole to understand that quality of delivery and testing the project is not soley up to the person in the Quality Assurance role.

Conclusion

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.