Practical Scrum-Scrum Team: Way to Produce ...

Practical Scrum-Scrum Team: Way to Produce Successful and Quality Software Ashish Mundra1 and Sanjay Misra2, Chitra A. Dhawale3 1 Barclays, Singapore, 2Covenant University,OTA,Nigeria, 3Amravati University, India [email protected], [email protected], [email protected]

Abstract—Scrum is the most popular agile methodology in software industry. By using scrum practices, several companies have improved their quality and productivity. This paper presents a practical view inside the Scrum practices, specifically, the team size, team structure and description of roles in Scrum teams are explained. The paper is based on our experiences in multiple projects executed in Scrum Agile methodology. Scrum is most suitable for products with team size of 3-9 members. For larger products, Scrum provides a mechanism called Scrum of Scrums. Scrum of Scrums distribute the large work/project into several teams and to control the quality and speed of each team, regular meetings are organized amongst the representatives of each team. We also present the guidelines for work distribution for the Scrum of Scrum (SoS) teams. Keywords—scrum; agile; scrum of scrums; SOS;

I.

INTRODUCTION

Software development is a complex process and becomes more complicated when the requirements changes frequently. In such situation, development methodology that encourage and support flexibility and have a high degree of tolerance for changes in other variables, increases the probability of success[1]of process. Scrum, which provides flexibility, responsiveness, and reliability to the process, is a suitable methodology for software development. It assumes that the analysis, design, and development processes are unpredictable because of changing requirements and business demands [2]. Scrum has started to dominate in software industry in last decade. Several big companies like Fuji-Xerox, Honda, Canon, and Toyota adopted Scrum due to its simplicity, assured productivity and most important is its flexibility. Success story of Toyota who achieved four times the productivity [3]and 12 times the quality of competitors, proves its power and make it as a most popular and strong methods of agile development methodologies. One of the success factors for Scrum is due to its team structure. A Scrum team generally contains 4-10 professionals[2][4]. In fact, Scrum is not magic process but it works because the team works properly and each member follows to each other. Additionally, it is proved that small teams in software development perform much better[5] in comparison to large teams.

In this paper, the attempt is to define a scrum team structure for a co-locatedteam and how the common project IT roles fits within the scrum team. This is a guidance and actual team composition depends on the project. The guidance is based on field experience of several years in software companies working with several scrum projects and some common application of reading various agile / scrum books.In this point of view, the work presented in this paper should be treated as an experience report.

II.

PRACTICAL TEAM STRUCTURE

The three important terms oftenly used in Scrum are 1. Product Backlog 2. The sprint and 3. The scrum team (normally of small size) The product backlog mainly represents the set of requirements to be converted into sprints. The Sprint represents an iteration in which a set of development activities are conducted over a pre-defined period [1]. The beauty of this approach is that, the SCRUM assumes that the analysis, design, and development processes in phase are unpredictable and therefore mostly Scrum opponents do not experience a proper process. However, once the team sets the process, the productivity increases in comparison to other traditional development approaches. Further, the team produces several Sprints, until the product is deemed ready for distribution. In summary, the Scrum team prioritize (planning) the backlog to be taken for developments and then focuses on execution of backlogs, produces sprints with frequent feedback from the product owner and end users. The team in scrum is also formed in a special way and normally consists for small size ranging from 3-9 professional. There are different views for the number of people in a team. Ken[1]suggest to form one or more teams of between three and six people and each is assigned a set of packets (or objects). Cohn [5]concluded that ideal Scrum team size should consist of five to nine individuals. Jeff Sutherland suggests using the team of seven people in Scrum development. The mentioned scientists have suggested these numbers based on their experiences on several Scrum Projects. One point is common in all the above suggestion is that the team size should not be large. In the present work, we are also

presenting our views in the formation of scrum team, their structure and roles. According to our experience on several Scrum projects, the team should be of the size of 5-9 members. The following Table 1defines a Scrum team structure that appears fit in for a development project. In general, the Scrum team consists of five-nine team members and comprises of just three roles: A. Product Owner: Represents the Business B. Scrum Master: The team coach on Scrum practices C. Team Members: The Developers and Testers and Others

much required to start with the project. Later based on scrum maturity of the team, keep it at 100% or less but never below 50%. 4. Product Owner Role: This is most important role, as a Product Owner (and not a scrum master) decides the priority of features to be implemented. The product owner represents the customers and end-users voice. This perspective is important. To repeat, the product owner is business centric role and not development team centric role. Can we have more than 1 Product Owner? – Yes you can, as long as they coordinate and act as one face for developers.

TABLE 1 SCRUM TEAM STRUCTURE Comments

Roles

Count

Scrum Master

1

Product Owner

1

Developers (a Team member role)

Maximum 6

Tester (a Team member role)

At least 1 per 3 Developers

Comments 100% as pure Scrum master, Or else, At least 50% pure scrum master and 50% can be any other role. Coordinates requirements from n number of end-users / customers and prioritize requirements With more than 6 developers you should consider breaking the project in more streams and do Scrum of Scrum. 100% from starting of project

A. Team Structure Description This section details the Practical Team structure. 1. Max 6 developers Where the magic number 6 comes from? – A team of six developers will mean total 6 developers + 2 testers + 1 scrum master + 1 product owner = 10 persons team. This is just an appropriate size to be fit in a single room or that can be easily managed with information flowing within all. Bigger the team size, it becomes difficult to self-manage and coordinate, information flow becomes too big a task requiring tools or formal processes. Scrum readings also suggests the scrum team size to be from 5 to 9 team members. There are several dedicated articleswhich talks about issues with bigger team sizes. 2. 1 Tester per 3 developers – The magic ratio This is a guidance and depending on need you may have 1 Tester for 4 or more developers too. However, various text suggests that this is the magic de-facto ratio. 3. Scrum master Role Scrum master removes impediments faced by team members, e.g. Coordination with other teams for any dependencies. Another major role of Scrum master is to help team adopt Scrum processes, e.g. Ensure that daily stand-ups are happening properly and regularly, user stories quality is up-to-date, etc. A 100% committed Scrum master is very

5. Tester Role: Scrum or Agile team does analysis, design, development and testing at all times. It’s important to have the tester role involved from the beginning i.e. from Iteration zero. Developers are the ones who writes unit tests, and testers are responsible for writing and executing functional tests (automation is desired and developers help can be sought here). Testers also assists Product Owners to come up with Acceptance tests and running the tests. Testers also performs test planning, and can also generate quality matrices if desired by Sr. Management. Main objective of Testers is not to break the system, and this is important. The objective of testers should be to help developers to prevent the defects. In the following paragraph we are also presenting the roles of other members who are not necessarily part of the scrum team but their roles are very common and important in traditional software development We are explaining them to remove any ambiguity that how their roles are compensated in the Scrum. 6. Project / Team Lead: This is not a defined role in Scrum. Scrum teams are empowered, self-organizing, enabled to take team specific decisions and are self-managing. They do not need a lead. Also a Scrum master is not the Team Lead. Often Team Leads responsibility is to take decision in case of ambiguity which in Scrum is taken collectively by the entire team. In some setups, a Lead is a single point of communication with Customers, whereas in Scrum, all team members directly interact with the customer all the time. Leads are not required to assign tasks, in scrum, the team assigns tasks to themselves. Another responsibility of Lead is for management reporting which can be done by Scrum master or read the Project Manager Role description in this blog. 7. Project Manager Role: This is not a defined role in Scrum. In Scrum projects, you do not need a Project Manager. However, from their experience project managers are of great help. The role of Project Manager should be to prevent team from external disturbances. E.g. To generate reports for Sr. Management, for people management, assist in career growth / aspirations, etc. Moreover Project Manager is aware of this projects impact to organization and other projects within Organization likely to impact this project. This is not often the perspective of Scrum master nor the Product Owner. Project manager, from their

project execution experience, gauge that something is not correct and can point the team of the possible issues. Project Manager however should not interfere with Team estimates or working style or any other aspect of project development. In Scrum, if used, the project manager role is to support and not a role with authority.



1 – Scrum master



1 – Product Owner



Permanent Team Members



4 – Developers (maximum)

8. Architect Role: If you need an architect for entire duration of the project, then, one of the developers should be replaced with an architect (i.e. max 5 developers and 1 architect). If you do not need a full time architect, then consider adding an architect for few iterations or else bring architect as per need. In such partial allocations, keep max 6 developers and add additional architect for required duration. In case of on-need basis inclusion, make sure that you have stories that require architects intervention planned accordingly. Partial allocations are always tricky and involves thrashing but at times may be the only option available.



1 or 2 – Testers (at least)



1 – Database Specialist



1 – UI Designer



Technical Writer – On need basis

9. Business Analysts Role: This is not a defined role in Scrum. However, just like you need an architect for technical inputs, you may need a Business Analyst for requirements gathering / analysis. A business analyst should never act as a layer between Team and the Product Owner. A business analyst can assist the product owner to form user stories or run acceptance tests and can help developers with understanding business requirements. Organizations that are incapable of identifying a Product Owner, or organizations working in an offshore scenario, assumes a Business Analyst as a Product Owner. In such cases, a Business Analyst should act as a real Product Owner, the one who prioritizes the requirements and takes Business perspective and not developers view. Business Analyst is a specialized skillset and is not a substitute for a Product Owner and organizations who fail to employ a Product owner are at a very high risk of developing a product which no one needs. 10. UI Designer / Technical Writer / Database Specialist: Cross functional team does not mean that a developer is expected to be the UI designer or a technical writer. These are specialized roles. You need one, when you need one. Allocation of these specialized roles should be considered in the similar fashion as mentioned for Architect Role in this paper. Having said this, when you have a specialist working in team, have the knowledge shared to all team members such that in absence of the expert, team members can pick up the work. Pairing or explicit sessions can help here. When required, the team members will help Specialists to accomplish tasks. A team of generalists is the preferred approach in Scrum teams than Silos of Specialists. B. Example Team Structure/Demonstration of the Scrum team Based on the discussion in the previous section we are presenting an example: Let’s say you need a full time UI Designer and a full time Database Specialist and a Technical Writer on need basis then your team structure will be

The role of each member of the team is explained in the previous section.

III.

SCRUM of SCRUMS

Scrum works best when the team size is small and colocated. So far we mentioned of a co-located scrum team structure and how common IT roles maps to the Scrum team. There will be times when the product will be too large for small scrum teams to work on. This is where you break your product functionally to smaller streams and have different coordinating teams working on it. For example,Scrum is a preferable software development framework in Global software development[6]. Several projects developed on one site in GSD environment may be large and in that case, they should be divided and allotted to several Scrum teams. Scrum of Scrum (SOS) is multiple scrum teams working and coordinating on the same product or towards the same goal. The word ‘same’ is key here as if the products are different you need different scrum teams altogether and no coordination is required. You can also use SOS if the product team is at several locations and each location has fully functional Scrum teams. This makes product execution across multiple locations manageable.Assignment of task to the teams is also an important task in software development and it is more important once the software development is globally distributed[7].In this following paragraphs section, we are suggesting the guidelines for product work distribution amongstSoS teams. These guidelines are suggested based on our experience of working in SoS teams/working environment. A. Guidelines for Product work distribution among Scrum of Scrum teams  No two teams should work on same user story. 

Strive to allot user stories by features. So, if in Iteration 1, a team was working on user stories of Feature 1, try and assign this feature to the same team in next iterations also. With multiple scrum teams you need to do some more planning. Here, you are just assigning features, the individual tasks are still up to the Scrum team to work on.



For ease of planning, Estimation scale has to be same for each user story. To achieve uniformity in scale, it’s recommended to have few initial user

stories estimated with all teams or representatives of all teams. 

Release planning will be done as is done in normal scrum where prioritized user stories will be divided to Iterations considering combined velocity of all Scrum teams.



Iteration planning will involve dividing user stories among Scrum teams in proportion of their velocity. Note that velocity will be different for each team.



Iteration length for each team should be same. This eases planning and coordination.



For dependencies, coordination is of utmost importance and Scrum of Scrum meetings is a good mechanism to share progress.

B. Scrum of Scrum Meetings Scrum of Scrum teams coordinates via a meeting in which one representative from each team participates. The meeting time is 15 to 30 min. and frequency of this meeting can be daily (if more coordination is required due to dependency) or sporadic with minimum once in a week. Scrum of Scrums usually should be conducted during following occasions: 

Just after daily stand-up meetings to update other SOS participants about the progress made between last meeting and now and what is planned to achieve before next meeting. Any dependencies among teams is also discussed. Any impediments are brought forward, but resolution is discussed outside this meeting.



Just after Release Planning meeting: With an aim to identify any dependencies on user stories that will be accomplished by coordinating scrum teams.



Just after the Sprint Planning meeting: To make all teams aware of their Sprint goals and understand deliverables and dependencies.

C. The Scrum of Scrums Team Structure In case of Scrum of Scrums, in addition to the description of roles mentioned above, here are some additional points to consider: 

Product Owner Role: The scrum of scrums should share the same Product Owner(s) or the Product Owner of each team should coordinate to represent one face to all the teams. They maintain the same Product backlog so that you always deliver the top most priority feature in a coordinated way.



Scrum master Role: Each team has their own Scrum master. The scrum master participates in all regular meetings and also participate in the SOS coordination meeting. However, it’s not required that only Scrum master

participates in SOS meetings, it can be anyone from the team. 

Developer and Tester Roles: These roles are not shared among the teams. Each team has their own dedicated Developers and Testers.



Specialized Roles (UI Designer / DB Specialist / Technical Writer / Business Analyst etc.): You might consider sharing them. Dedicated resources are always the best as resource sharing causes thrashing and context switching is a costly affair. D. A Lean Approach to Scrum - Product Coordination Team Lean methodology suggests an alternate to Scrum of Scrums team. The Product Coordination team (PCT) has representatives from each team just as in SOS. As per Lean,SOS tends to be biased towards their own teams and do not think of larger picture of Product Coordination. PCT picks the work from Product Backlog and in an unbiased way places it in each teams Sprint backlog and coordinate the delivery. It’s essentially SOS team without affinity to their own teams. PCT by its name brings a different perspective. A SOS team should work on this perspective for the greater good of product development. IV.

DISCUSSION

In a survey [5] of 491 projects, consisting of team size of 1-20 people, completed between 2003–2005 that delivered between 35,000 and 95,000 new or modified lines of source code, when the productivity of the individuals were analysed from the projects it was found that the best performance of individuals was found from those team, which consists of 1-5 people and it was also observed that smaller teams complete projects with less total effort. The authors has further analysed and explained that for a project, the most cost-effective strategy is the smallest team and is acceptable up to nine or few more people. Our recommendation for the team size is also based of several successful Scrum projects where one of the authors is involved. The number of team members, which is nine in our recommendations, is closely related to the results of other researchers [5][8]. Jeff Sutherland who is the one of founders of Scrum suggests using the team of seven plus minus two (i.e. 5-9)[8].He also argued that team sizes over 7 result in significantly lower productivity and therefore any team over 7 in size should be split up into multiple SCRUMs. We have also suggested that team size should not more than nine and this can be varied according to the characteristics of the project. In fact, Scrum is a flexible methodology and it works based on the circumstances and the situation of the project. This is the reason that number of team size cannot be fixed exactly. However, for the upper limit of the team size, majority of the experts are not in favour of more than 9-10 members in a Scrum team, which is in line with our observations. V. CONCLUSION The present work proposed the team structure and description of the roles of each team members in Scrum and

SoS. Furthermore, the guidelines for distributions of work amongst the SOS teams are also proposed. Hope this paper helps to understand how a scrum team is structured and how it can be scaled for large products. Consider this as a guidance which you will most likely refine based on the specific project needs. Scrum software development is proved very effective practices in global software development environment. It reduces several major challenges of GSD like communication, coordination, and control problems [9]. SoS scales the Scrum to the large projects which is normally the case for GSD software projects. By considering this, we aim to analyse the practical aspect of GSD projects with SoS practices, as a future work. Further, we also aim to investigate that amongst Kanban and Scrum [10] or SoS, which one is more practical approach in GSD environment.

Acknowledgment One of the authors Ashish Mundra acknowledge to all team members with whom he worked to gain the experience in several Agile projects and put it down in this paper. References:

[1] S. Ken, "Scrum development process," in Proceedings of the Workshop on Business Object Design and Implementation at the 10th Annual Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA'95), 1995. [2] L. Rising and N. S. Janoff, "The Scrum software development process for small teams," IEEE Software,,

pp. 17(4), 26-32, 2000. [3] J. Sutherland, V. Anton, B. Jack and P. Nikolai, "Distributed scrum: Agile project management with outsourced development teams," in 40th Annual Hawaii International Conference on System Sciences(HICSS), 2007. [4] H. Kniberg, Scrum and XP from the Trenches, InfoQ Enterprise Software Development Series, 2007. [5] M. Cohn, "Team Structure," in Succeeding with Agile: Software Development Using Scrum, Addison-Wesley Professional, 2009, pp. 177-199. [6] E. Hossain, A. B. Muhammad and y. P. Hye, "Using scrum in global software development: a systematic literature review," in Fourth IEEE International Conference on Global Software Engineering, 2009. [7] A. Lamersdorf, M. Jürgen and R. Dieter, "A decision model for supporting task allocation processes in global software development," in Product-Focused Software Process Improvement, 2009. [8] J. Sutherland, The scrum papers: Nuts, bolts, and origins of an agile process, Cambridge: scruminc.com, 2012. [9] H. Holmström, F. Brian, J. Å. Pär and Ó. C. Eoin, "Agile practices reduce distance in global software development," Information Systems Management, vol. 23, no. 3, pp. 7-18, 2006. [10] H. Kniberg, Kanban and Scrum-making the most of both, Lulu. com, 2010