Scrum Team Guidelines: Team Centred Development Part I – 3 components onlyon Mar 01, 2012 in Software Development Process by Lawrence Owusu
After a recent scrum training course, I saw how simple and yet powerful the scrum rules are. As Ken Schwaber and Jeff Sutherland noted in the scrum team guidelines, scrum teams have to be self-organizing and cross-functional.
A scrum team must only consist of only three components, the scrum master, the development team and the product owner. There should not be any project managers or business analyst titles in the team. The team is supposed to be self-organising and hence the traditional role of project managers where team members are “managed” does not fit in a scrum team.
At this point, you might be wondering, how can a team without say a business analyst or a project manager, deliver successful projects? Surely most project managers & business analysts perform some important roles in a team, who performs their current roles if they are not in the team?
Simply put, most of these roles are already roles that either the product owner, scrum master or the team must be playing according to the scrum rules. Also, there are some roles played by product owners and business analyst that must not be played at all in a scrum team.
For example, a business analyst will typically meet the client, gather requirements and try to understand the needs of the customer. He/she will then relay this information to the team. Ideally, this initial meeting where the requirements of the client are discussed should be attended by the scrum team and the client. The scrum master can facilitate the meeting, but the team can get the opportunity to interact with the client and understand what exactly the client wants. By the end of this meeting/workshop, everyone on the team has a clear idea of the big picture. They would have had the opportunity to ask question and most importantly, be able to relate to and understand the requirements of the client. In this scenario, the business analyst becomes a bottleneck. It is always better to have the team relate and understand the client than for one person to do this and try to relay what he/she thinks the client needs to the people who are actually going to develop the system. This bottleneck needs to be removed.