Issues And Challenges In Scrum Implementation Information Technology Essay

Purpose of this thesis is to identify challenges and issues in Scrum Implementation and in proposing their solutions. This research thesis will also compare nature of issues facing by experienced and non-experienced Scrum Team. To support highlighted issues, two company’s Scrum experiences will also be concluded in this thesis. Solutions and recommendations will also be provided for highlighted issues. A tool (Excel Format) for sprint will be developed for Sprint and Product Backlog. Objective of this tool is to eliminate issues related to communication and provides statuses of tasks for better sprint management. This research thesis is divided into eight sections. Chapter-1 will provide introduction to thesis paper. This will cover introduction to Agile Development Methodology and then Scrum Framework. Drawback in Scrum Implementation and Objective of this research thesis will also be included. In Chapter-2, related work will be presented in order to provide a brief background of this research thesis. Chapter-3 will cover research methodology adopted for the thesis. In Chapter-4, data collection for this thesis is discussed. Chapter-5, identified issues and their solutions will be discussed. Chapter-6 will show backlogs for sprint management. Chapter-7 concludes this research thesis and finally in Chapter-8, list of references will be provided.

Table of Contents

Acknowledgement 2

Abstract 4

6

Introduction 8

Agile Development 8

Agile Methods 10

Scrum 10

Scrum Lifecycle 11

Scrum Roles 12

Meetings in Scrum 14

Scrum Artifacts 16

Sprint – Scrum Center of Attention 16

Drawback 17

Objective 17

Related Work 19

Proposed Solution 24

Research Methodology 26

Survey Data Collection 28

Identified Issues and Proposed Solutions 30

Backlogs 37

Product Backlog 37

Sprint Backlog 38

Burndown Chart 39

Conclusion 41

References 43

Appendixes 45

Appendix I 45

Appendix II 47

CHAPTER 1

Introduction

Introduction

Agile Development

Agile methodology is the methodology in which things are minimally planned and are done in small increments. There is no long term planning in case of agile methodology. Iterations are short (two to four weeks) which are passed through the complete software life cycle, including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This minimizes the overall risk, and makes requirement changes adaptation for the project easy. Documentation is produced as required by stakeholders. The role of iteration is not to add more functionality but to make a release with minimum bugs at the end of the iteration. To release a product or to add new features, multiple iterations may be required. These iterations result in the minimization of the overall risk, and adaptation of the project becomes easy.

Agile is a philosophical and conceptual term to define the framework of understanding software engineering project. This method is a means of minimizing the risk by developing software in short time boxes, called iterations, each being a miniature software project of its own, and includes all of the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation. While an iteration may not add enough functionality to warrant releasing the product, an agile software project intends to be capable of releasing new software at the end of every iteration.

Agile project team hierarchy is not as strict as in other development strategies. It is usually cross-functional, that is the people in the team have different functional specialties and skills and are responsible for each phase of the project life cycle, and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members can switch roles and they are responsible for adding the tasks that deliver the functionality of iteration and they can switch their roles. The decision of how executions going to take place during iteration are taken by the team members themselves.

The agile methodology prefers face to face communication and therefore the teams are located in a single open office so as to make this communication more feasible. The face to face communication produces less documentation. The communication and collaboration is further eased by the small team size, that is, 5-20 people in one team. In the communication sessions that take place the team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are. In this way the problems are exposed. Larger development efforts may be delivered by multiple teams working toward a common goal or different parts of an effort. This may also require a coordination of priorities across teams.

However, another approach may be that multiple teams work toward one common goal and might have different but important roles to play in the achievement of the final goal. This may also require a coordination of priorities across teams so as to settle the order in which each step should be taken to reach the end point of the project, keeping the most important first.

Each agile team essentially will contain a customer representative. This person is appointed by stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer mid-iteration problem-domain questions. At the end of every iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment and ensuring alignment with customer needs and company goals.

In almost every agile methodology there is a formal meeting or face to face communication session among team members. Customer representative or any stakeholders can also attend this session but as an observer. In this communication sessions that take place the team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are. In this way the problems are exposed.

Agile methods emphasize working software as the primary measure of progress. The face to face communication produces less documentation. In an agile project, documentation and other project artifacts all rank equally with working product. Stakeholders are encouraged to prioritize them with other iteration outcomes based exclusively on business value perceived at the beginning of the iteration.

Agile software development methods have gained a good deal of popularity since the last two decades (late 1990s). These methods in comparison to more traditional approaches may offer improved outcomes for software development projects. Survey analysis disclosed that agile methods give improved outcomes from software development projects in many aspects for instance in terms of quality, satisfaction, and productivity, within approximately same cost.

Agile Methods

Many other approaches come under this broad term. Some of the agile software development methods include:

Extreme Programming (XP)

Scrum

Crystal Clear and Other Crystal Methodologies

Feature Driven Development (FDD)

Pragmatic Programming

Dynamic Systems Development Method (DSDM)

Scrum

Scrum is an approach for managing a development process not only for software development. It does not give an account of technical development activities.

Actually Scrum itself is a management method and not an engineering method. However, it is well-matched with any engineering approach that can be applied in monthly iterations. Often, Scrum is combined with XP practices. Scrum replaces and expands the planning game

Scrum’s goal is facilitating the self-organization of the team so that it can adapt to the specifics of the project and their changes over the period of time.

Scrum is also known as “process skeleton”, which comprises sets of practices and roles that are predefined. Scrum is a method that teams can take up promptly for planning and management. Each step has an ample account on planning, designing, building up and test code at the same time of following team progress. The main advantage of scrum is that, it is plain and simple to follow.

Typically the duration of a sprint is two to four weeks and this time length is decided by the team. During the given time period, a team generates shippable product increment in general (for example, working and tested software). The set of specifications that go into a sprint develop from the product “backlog,” which is a preexistent set of high level requirements of work to be done. The backlog items which are involved in the sprint are decided during the sprint planning meeting. In this meeting, the product owner tells the team about his requirements and the items in the product backlog he wants completed. Then the team estimates, how much of the given tasks they can accomplish during the next sprint. During a sprint, no one can change the sprint backlog which implies that the requirements are fixed for that sprint. After the completion of the sprint, the team gives demo on the usage of the software.

Scrum allows the formations of teams that are self-organized by supporting co-location of members and encouraging verbal communication across all team members and moreover disciplines that are involved in the project.

There are a number of implementations of systems for managing the Scrum process ranging from yellow stickers and whiteboards, to software packages. One of Scrum’s leading advantages is that it is very easy to learn and needs little effort to start using.

Scrum Lifecycle

As earlier discussed, the intent of Scrum is to build working components in small iterations, each iteration lasting between two and four weeks. A typical Scrum lifecycle has the following steps:

Write the requirements (and store in the Backlog)

Plan the release (which could span more than one 2-4 week Sprint)

Plan the Sprint

Conduct the Sprint

Analysis

Design

Coding

Testing

Conduct Sprint retrospective

Daily stand-up meetings are held to track team progress and identify barriers.

Fig. 1: Scrum Process – Courtesy of [4]

An important rule in scrum is its recognition that during a project the customers can change their minds and requirements about what they want and need; this change is often called as requirements churn. These unpredicted challenges cannot be easily addressed in a conventional predictive or planned manner. Scrum takes up an empirical approach by agreeing that the problem cannot be completely understood or defined. Instead, focus should be on maximizing the team’s ability to deliver quickly and respond to emerging requirements.

Scrum Roles

There are two categories of roles present in Scrum i.e. “Pig Role” and “Chicken Role”.

Pig Roles

The Pigs are the ones who are dedicated to the project in the Scrum process. Pigs are the ones with “their bacon on the line” and doing all the actual work of the project. There are further three main categorizations of Pig Roles are;

Product Owner

Scrum Master

Team

Product Owner

The Product Owner stands for the voice of the customer. He is the person who represents all customers and at the same time manages the Product Backlog Sets priorities. He is the person who stands for the group of stakeholders. He makes sure that the Scrum Team works with the “right things” from a business point of view. A Product Owner can be a member of the Scrum Team but he cannot be a Scrum Master.

According to original Scrum, Product Owner falls in the category of “pig”. However, if his involvement is not on regular basis then he/she may be considered as a “chicken”. A product owner also selects requirements for a Sprint.

Scrum Master

Scrum is aided by a Scrum Master. The primary job of the Scrum Master is to remove obstructions to the ability of the team to deliver the sprint goal and thus responsible to make sure a smooth execution of the scrum process. He is the one who is responsible for managing all the processes, normally in place of a project manager. As the team is self-organizing, Scrum Masters doesn’t play the role as that of a leader but he acts as a buffer between the team and any distracting influences. For this, he acts as a teacher and coach and not as a manager. The Scrum Master makes sure that the Scrum process is used as planned and also acts as the enforcer of rules. The most crucial part of the role of Scrum Master is to protect the team and maintain their focus on the tasks in hand. The role of a Scrum Master targets both Team and Product Owner accountable for removing organizational hindrances. Moreover, Master and Team together are in charge for product delivery.

Team

The team is responsible for the delivery of the product. A team typically has 5-9 members and acts as a cross-functional group. The team does all the actual work like analysis, designing, testing, implementation and technical communication, etc. The developers are analyzed as a self-organizing group of technical and process experts. It is also noteworthy that the role is of team and not of a developer.

Larger projects can use multiple teams for their completion.

At times, the Scrum Master also acts as a Product Owner or Team member too depending on the situation. This also generates conflict but that is resolvable.

Chicken Roles

These are not component of the actual Scrum process, but must be taken into account. Chickens are the one for whom the software is being built.

Stakeholders (customers, vendors)

Stakeholders are only directly involved in the process during the sprint reviews. These are the one who enable the project and for whom the project will produce the agreed-upon profit, which justify creation of the project.

Managers

Managers are the people who set up the environment for the product development organizations.

Meetings in Scrum

Daily Scrum

During the sprint, a project status meeting occurs on daily basis. It is called a “daily scrum”, or “the daily standup”. The specific agenda of these meetings are:

The meeting starts exactly on time.

All are welcome, but only “pigs” got the right to speak.

The meeting is restricted to 15 minutes

The meeting should be conducted at the same location and same time daily

During the meeting, every team member answers three questions, these are:

What is your progress since yesterday?

What is your today’s plan?

Is there any problems hindering you from achieving your goal?

Scrum of Scrums

Scrum of Scrums also occurs on daily basis, each day normally after the daily scrum.

These meetings permit groups of teams to talk about their work, specially focusing on areas of overlapping and integration.

An elected person from each team attends these meetings.

The guidelines remain the same as of the Daily Scrum including the following four questions:

What has your team done since the last meeting?

What will your team do before the next meeting?

Is there anything obstructing your team progress?

Are you about to put something in another team’s way?

Sprint Planning Meeting

A “Sprint Planning Meeting” is conducted at the beginning of the sprint cycle (every 7-30 days). This meeting purpose is to:

Identify what is to be completed

Prepare the Sprint Backlog that gives an account of the time it will take to do that work, with the whole team

Identify and communicate how much of the work is likely to be done during the current sprint

Eight hour limit

Two meetings are held at the end of a sprint cycle, these are called the “Sprint Review Meeting” and the “Sprint Retrospective”

Sprint Review Meeting

Analyze the work that was done and not done.

Present the completed work to the stakeholders in the form of a demo.

Incomplete work cannot be demonstrated

Four hour time limit

Sprint Retrospective

All team members reflect on the past sprint

Make continuous process developments

Two main questions are asked in the sprint retrospective: What worked well during the sprint? What improvements can be made in the next sprint?

Three hour time limit

Scrum Artifacts

Product Backlog

It is a high-level document for the whole project. It includes backlog items like broad descriptions of all necessary specifications, wish-list items, etc. prioritized by business value. It answers the “What” that will be built. It is open and can be edited by anyone and contains rough estimates of both business value and development effort. Those estimates enables the Product Owner to determine the timeline and, to a limited extent, priority.

The Product Owner possesses and owns the product backlog. Business value is set by the Product Owner while the development effort is set by the Team.

Sprint Backlog

This document contains the information regarding the implement the features for the upcoming sprint by the team. Features are broken down into small tasks for feasibility. These tasks are normally estimated between four and sixteen hours of work.

With all these details the whole team understands exactly what is to be done, and anyone can potentially take up a task from the list. Tasks on the sprint backlog are not assigned. They are in fact signed up for by the team members as desired, according to the set priority and the team member expertise.

The sprint backlog is the property of the Team and the team sets the estimations.

Burn Down Chart

It is a chart that is displayed publicly to show the remaining work in the sprint backlog. The burn down chart is updated on daily basis and gives a simple view of the sprint progress. It also gives a quick account of reference. There are also other types of burn down, for instance the Release Burn down Chart which depicts the amount of work left to accomplish the target commitment for a Product Release (normally spanning through multiple iterations) .the other one is Alternative Release Burn down Chart, which basically serves for the same, but clearly shows scope changes to Release Content, by resetting the baseline.

Sprint – Scrum Center of Attention

During a Sprint, requirements are set in advance but the process it not. Daily scrum may adapt anything as needed or required.

Drawback

Numerous works have been done to cover all aspects of Scrum framework but still there are open research areas which need to be covered. In every agile development methodology, we are taking here Scrum Framework for research; there are some limitations with respect to nature of work [5]. Some issues are highlighted in [5] such as training, management, involvement, access to external resources, corporate or organization size and [9] for distributed area, sub contraction, developing large and complex systems, but still there are open areas where no significant research work has been done. According to [2], following areas of limitations in agile processes: distributed environments, building reusable artifacts, large teams, and developing safety-critical software.

Objective

Agile methods have been projected as a means for early and speedy production of working software. Supporters of agile processes argue that the source code is the most crucial deliverable and that it should take preference over analysis, design, and documentation. On the contrary, critics refer to the notion of “corporate memory loss” which could be caused if there is little emphasis on producing good design models and documents, especially in case of large complex software based on empirical analysis, experience reports, and researching the agile manifesto[2].

Objective of this thesis is to minimize the issues and challenges of Scrum in Software Development and propose solutions to some of them.

CHAPTER 2

Related Work

Related Work

In this section, related work will be presented in order to provide a brief background of this research thesis.

Jeffrey A. Livermore (2008): Author’s research was based on identifying factors related to agile software development methodologies implementation. The research showed that there are a number of factors under management’s control that effects execution of an agile Software Development Methodology. The factors that affect the sound execution of an agile SDM are training on the methodology, active management involvement and support, access to external resources, and company size. While, successful execution is not hampered by applying a complete methodology implementation strategy and development team collocation. At the same time using models and templates, developing software whether for Internet or intranet usage doesn’t affect successful implementation too. These factors were identified from online survey result conducted by author.

Artem Marchenko, Pekka Abrahamsson (2008): This is a case study performed by author on a Scrum Team having size of 20 members. Scrum Team was working on simultaneous multi-project R&D environment. In this research paper author examined Multi-Project Environment and determined challenges emerge in adoption of Scrum. Author’s research question, (How can Scrum be used in a multi-team and multi-project environment and what challenges, if any, emerge from the empirical qualitative evidence?), was answered by empirical evidence obtained from empirical observations results for challenges in the adoption process of Scrum Author highlighted 10 challenges and contends that these results carry great significance for other industrial teams. Highlighted issues are listed below

Overemphasis on the Scrum process and practices

Scrum Master ignoring the process

Lack of clear management, expectations and actions

High rate of bug fixing and maintenance

Fitting Scrum and short iterations into research intensive teamwork

Over specialism undermining collaboration

Over individualism

Committing to too much

Difficulty in tracking progress and in using the results of the tracking

Management interfering too much

Juyun Cho (2008): In this research thesis, author differentiates between traditional software development methods and agile software development methods. Author then define characteristics of Scrum framework and then finally mentioned issues and challenges discovered through a case study of a company which has employed Scrum for many projects.

The paper also introduced the roles, ceremonies, and artifacts of Scrum, which is considered one of the most famous agile software development methods in the industry. Moreover, the paper also shows the five issues and challenges including documentation, communication, user involvement, working environment, and Scrum ceremonies, found through an in-depth case study in a software company which develops small- and mid-size web-based applications. If all the five issues and challenges are taken into consideration and resolved before launching the project, organizations will face low difficulty level in creating high-quality software products using Scrum.

Steve Berczuk (2007): Author stated that in agile development methodology, communication is the main reason for successful agile implementation where teams are distributed. Distribution reduces communication bandwidth but the rule of agile methods serve to increase communication and feedback hence distribution causes non-compliance with agile methodology.

Agile processes rely on feedback and communication to continue working and they often perform best with co-located teams for the same reason. At time, agile makes sense because of project requirements and a distributed team makes sense because of resource constraints. A distributed team can be dynamic and fun to work on if the team takes an active role in overcoming the hurdles that arise due to distribution.

It is difficult to do agile with distributed teams because distribution can decrease communication bandwidth. Co-located teams that do not have sufficient communication can also fail with agile methods.

But the rules of agile methods provide to high level of communication and feedback. Any team is best served by following the rules of the agile method with very few adjustments. Distribution increases the harm that non-compliance can cause. A team can be successful and overcome obstacles if it feels like it owns the process and the tools.

Aniket Mahanti (2006): This survey thesis accounts on the main challenges faced by the enterprises in implementing agile practices. Gathering information from the literature issues like framework for agile organizational change and adoption strategies are analyzed (or scrutinized). Inputs from the industry shows that most organizations are best fitted in implementing a combination of traditional and agile methods.

Extensive implementation of agile practices by the software industry has inhibited a number of challenges. The recognition of dynamics of organizational change helps in the successful execution of new methodologies. The question of agile practices crossing the chasm is open.

If the academic world considers this methodology to be helpful and introduces relevant courses at the university-level then it can be said that the upcoming generation of software professionals may show more acceptance to the concept of agility. It may take years to implement it and it is quite possible that during this other promising and advanced technologies may come up and surpass the agility paradigm.

The author pinpoints 4 issues in paper which identify from his survey. These are:

Limited support for distributed environments

Limited support for building reusable artifacts

Limited support for development involving large teams

Limited support for developing safety-critical software

Andrew Begel, Nachiappan Nagappan (2006): This thesis accounts on the results of an empirical study, which was taken at Microsoft. The aim of that study was to learn about agile development and how it is perceived by the people in development, testing, and management. It was observed that one-third of them were using agile methodologies to varying degrees and most of them found it quite helpful due to improved communication between team members, quick releases and the increased flexibility of Agile designs.

On the other side, developers are anxious about scaling Agile to larger projects (more than 20-30 members). Excessive meetings add too much overhead on developers and hence results in difficulty in adoption of Agile Software Development methods.

Barry Boehm, Richard Turner (2005): Boehm and Turner’s discussions with traditional developers and managers relating to agile software development practices almost always comprised two somewhat conflicting ideas. They discovered that on small, stand-alone projects, agile practices are less heavy and more adjustable with the software industry’s rapidly increasing needs for quick development and dealing with continuous change.

Outi Salo (2004): In this thesis empirical results are presented where team conducted Post-Iteration-Workshop after the completion of two XP (Extreme Programming) projects to improve and optimize working methods. After all process iterations for the enhancement and optimized working methods, a “post-iteration workshops were conducted out by project teams. These two empirical results from two XP (Extreme Programming) projects is being reported in this paper.

The paper supplies an account of both qualitative and quantitative data from the total of eight post-iteration workshops. Therefore, it helps in the estimation and contrasts the findings of the two projects.

The result depicts both merits and demerits of the findings. Simultaneously it gives the variation of negative findings and improvement process actions towards the end of both projects. The data collected after post-iteration workshops showed level of confidence and learning by project teams

CHAPTER 3

Proposed Solution

Proposed Solution

Main idea of this thesis is to identify unidentified challenges and issues in Scrum implementation and devise techniques to tackle those issues. However this thesis will also propose solutions to issues and challenges mentioned in [9] such as documentation, communication, user involvement, working environment, scrum ceremonies and client involvement [5]. For problems related to sprint management, a tool/pattern is devised for Sprint and Product Backlog. Objective of this tool is to eliminate issues related to communication and sprint management. This tool also helps in meeting sprint objectives and in case of any failure it will show where and why team fails.

This research thesis covers formal sessions with two organizations to highlight and compare nature of issues they faced in scrum implementation in development. These two organizations are “Bentley Systems Pakistan” and “Digital Prodigy Limited”. Former has more than 3 years and later has 9 months experience in implementation of scrum framework. This experience gap will allow comparing nature of issues facing by experienced and non-experienced Scrum Team.

CHAPTER 4

Research Methodology

Research Methodology

Several approaches are used to conduct any research such as Quantitative, Qualitative or Mixed approach. Mixed Approach is used to identify and highlight Issues and Challenges of Scrum Implementation with the help of existing work and from experiences of two companies by survey.

Questions in the survey are drawn from self Scrum Implementation experience. Survey instrument was reviewed peers for readability and then by other Scrum experts for content validity. Survey was distributed to different Scrum experts for more than two weeks.

For this research thesis, data were collected from two sources i.e. survey and face to face interview with 20 employees from two companies including project managers, scrum masters, development team and quality assurance team.

CHAPTER 5

Survey Data Collection

Survey Data Collection

There were 35 individuals who received an invitation to participate in the survey. Out of them there were 20 responses which were received hence making return rate of 57.14%. Survey included 23 questions and no incentive was offered to any individual to complete and submit.

Individual experiences ranged from 1 year to 15 years. All of the interviews were audio taped, write out and then coded. Surveys data were stored in database and later performed data mining on them. In the process of data analysis grounded theories were used to derive constructs from collected raw data. Data were also passed through data mining process to find out relations between different constructs.

Survey questionnaire covered questions from Development, Testing and Release Process. All individuals belong to team which has adopted Scrum Framework. All roles related to software development such as project managers, scrum masters, development team and quality assurance team are the individuals who responded to survey.

Questionnaire is attached in Appendix I and their compiled answers are attached in Appendix II.

CHAPTER 6

Identified Issues & Proposed Solutions

Identified Issues and Proposed Solutions

Several issues have been identified from survey results and from interview session. These issues were directly affecting proper Scrum Implementation. These issues are related to management, development and release process and are listed below.

Quality Items Pileup

Module Integration Issues

Quality of Code

Disruption in Team Work:

Mature vs. Immature Scrum:

Sprint Duration:

Lack of Scrum Training:

Release Process

Backlog Management

No technical practices

Multiple teams

Metrics

Risk Management

Documentation

Too Idealistic

Quality Items Pileup: Due to agility of work in Scrum, teams are bound to present something in short duration of time (either you scoped it properly or not). That is why they sometimes ignore quality of software and create a pileup of quality related items. This is the biggest issue of Scrum framework or any Agile Methodology.

Without proper consideration on those left quality related items, teams can never make software quality better.

Module Integration Issues: Due to short period of internal release during a sprint, module integration testing cannot be performed properly all the times as it requires a lot of time for testing and quality assurance. This also creates some issues. Like when you open a wheel of a car, you know that it wouldn’t affect the performance of your engine. But that doesn’t hold true in case of software. Any small update may have big impact on whole system.

Always give extra time to last internal release for testing and understand that it’s not a car, its software. For critical or large modules integration and quality assurance, a full dedicated sprint is more preferable than doing in any other way.

Quality of Code: Due to agility of scrum, teams have short-term deadlines. If any developer is missing his deadline then he will obviously put extra hours to cope up with it. This creates an issue of Quality of Code. One cannot always right correct and quality code all the time especially when he is working under pressure and putting extra hours to complete the task.

Re-scoping for those tasks can solve this issue very easily. After proper re-scoping, tasks can be divided into sub tasks. To show progress on task, some sub sections can be done in current sprint and rest of the sections can easily move to next sprint. However those sections will be considered as lag and should be finished in next sprint.

Disruption in Team Work: When team moves from traditional SDLC towards Agility, like scrum, their managers are not able to easily digest independency of scrum, especially self organization. From Survey results, it has been noted that Product Owner and Scrum Master interfere in team work by asking statuses like they do asks in traditional SDLC.

Fig. 2: Disruption in Work during Sprint

This is against self organization and self motivation which scrum talks. If team is not mature, then make team mature first and then start scrum. Proper training and scrutinize process can play important role in team maturity.

Mature vs. Immature Scrum: This has been also proved from results that Mature Scrum has relatively less issues than Immature Scrum. But the difference is very slight. This is because Digital Prodigy Limited (DPL) is trying to follow scrum religiously. Fig. 3 is clearly showing no. of issues facing both companies.

Fig. 3: Issues by Company

At this point, it is very important to mention that Bentley Systems which has over three years of experience in Scrum doesn’t have basic level issues, because their processes and Teams are mature enough to support Scrum.

Sprint Duration: Sprint duration plays an important role in effectiveness of Scrum. Product Owner/Scrum Master has to wisely select sprint duration to get maximum benefits of Scrum.

Fig. 4: Issues by Sprint Duration

Fig. 4 clearly highlights the no. of issues having at different sprint duration.

It is very important to set sprint duration to the rate at which requirements change and the rate at which the team can deliver functionality. Adding more work than the team cannot do makes difficult to make commitments and to measure progress and velocity of team, and new “high-priority” work can disrupt flow.

Lack of Scrum Training: Results also revealed that 50% team members didn’t received any formal training of scrum or they don’t know completely how scrum process works. They got informal scrum knowledge either from their other team fellows or from their scrum master.

Fig. 5: Lack of Scrum Training

Teams having proper training of scrum process are better than the teams having no or informal training. They are better in self organization and self empowerment. Through proper training of teams, they can better know how scrum process works and what the team rights are.

Release Process: One of the major issues is release process or the deployment process. Scrum introduces agility in work and due to agility; sprint deployment is the major concern for every team.

Teams have more deployments than before because their work is now divided into sprints. They have to be very careful for deployment. Release Management process can surely help in this case. Release Management also requires such policies which best suits to Scrum. Better policies and their enforcement in team can resolve this issue very easily.

Backlog Management: Scrum provides insufficient guidance regarding the structure of the backlog. There are scrum management tools available in market but they are either too complex or too simple which often doesn’t meet team requirements. Complex tools in market are expensive. Teams who just adapted scrum framework are not willing to buy such expensive tool because Scrum is implemented in experimental mode.

Problem to this solution is presented in Chapter-7.

No technical practices: Scrum shows good capability of project management, but there is no best technical practice available. Best practices needs to be adopted from other agile methods like Extreme Programming for good implementation of Scrum. Technical practices like Test-Driven Development, Continuous Integration, Pair Programming, Acceptance Testing and Refactoring should be added in Scrum Process.

Multiple teams: From the survey it has been noticed that working with multiple teams is not easy as it is in traditional SDLC methods because scrum doesn’t have strong advices on it. Although scrum talks about “Scrum of Scrums” but this technique doesn’t work well when the teams are specially distributed. In fact agile itself is virtually silent on this issue. When working in distributed environment, Scrum Masters require lot of work and coordination among all the teams. This is not a failing of scrum but a lack of strong process when working with multiple teams.

Metrics: Scrum uses Burn Down charts and Velocity to measure metrics. These metrics are not enough to show right picture unless the Scrum Master or Product Manager sits down and analyzes the burn down chart for its peaks. These metrics are often ignored and not analyzed. Burn Down chart is good to show overall status of the status i.e. how much hours have been spent or how much hours have been left. Although burn down chart shows number of hours spent in a particular day but not enough to provide in depth detail of that particular day.

As far as velocity is concerned, it is defined as number of tasks/story points completed. There are cases when in one sprint velocity is high and on the very next sprint it is low. This is because it can never be used to identify low or high velocity in a project.

Risk Management: There is no plan or strategy in scrum to handle risks. It’s an important factor for any project and hence work is required in this area in Scrum.

Documentation: Agile believes in no documentation so Scrum also does; however this phenomenon is still not successful in real environment where things come in and out through email or any other source which is quite difficult to track.

Change should be tractable from Scrum Backlog. If any change comes, it should be relate to its related task.

Too Idealistic: Scrum assumes teams are of same self managing. As per rules of Scrum, Scrum master job is to remove all impediments for his team and product owner job is to provide the requirements in stories which will help to build or complete the project incrementally. However in practical this scenario is not valid. It is not possible to make your team self organized and self empowered all the time.

CHAPTER 7

Backlogs

Backlogs

In this section, Product Backlog and Sprint Backlog are presented.

Product Backlog

This is a template for Product Backlog management. Anyone can add requirements in this section. It includes backlog items like broad descriptions of all necessary specifications, wish-list items, etc. prioritized by business value. It answers the “What” that will be built. It is open and only Product Owner can edit this backlog. It may also contain rough estimates of both business value and development effort.

Fig. 6: Template – Product Backlog

In Figure No. 6, a sample product backlog has been presented. It is also known as request manager where anyone can add requirements but it will only be approved by Product Owner. First column is Id which is the unique id of any item for product backlog. Its reference will be used in Sprint Backlog for tracking of any sprint item. Next column is Timestamp, which is the date and time when the request was added in Product Backlog. Next to the Timestamp is Project which will be used for categorization of multi-projects. As a single team can work on several sub-projects hence it is necessary to add such categorization. After that Owner column will tell about the person who owned this requirement. Owner of the item can be anyone but it will be for stakeholders. This means item should be for stakeholders of the project. Next to owner is Type which will clearly tell about nature of the task. There can be more categories of Type column but typically it will be either “Change” or “Defect”. Status column depicts about the status of the current task. When task will be added first in Product Backlog, it will be in Pending Status; later on it can be any of the following statuses i.e. “Pending”, “Under Progress”, “Completed” and “Deployed”. Severity column will tell about the priority of the item. It can be Urgent, High, Low and None. If an item is having None severity then it will be up to Product Owner when he selects it for Sprint.

Sprint Backlog

This document contains the information regarding the implement the features for the upcoming sprint by the team. Features are broken down into small tasks for feasibility. These tasks are normally estimated between four and sixteen hours of work.

With all these details the whole team understands exactly what is to be done, and anyone can potentially take up a task from the list. Tasks on the sprint backlog are not assigned. They are in fact signed up for by the team members as desired, according to the set priority and the team member expertise.

The sprint backlog is the property of the Team and the team sets the estimations.

Fig. 7: Template – Sprint Backlog

In figure 7, Id is the Sprint Backlog Id and this must be unique for each Sprint. Next to Id is Request Manager column. It will have Product Backlog Id. Description and Details will contain information about task. It can be same Description of Product Backlog. Resources column will tell about resources working on any item. Any resource can pick task from Sprint Backlog but he/she must inform Scrum Master before starting work on it. Tasks may have anyone from these statuses “Under Progress”, “To Verify” and “Done”. “Under Progress” means team member has started work on this item, “To Verify” status will show that task has been completed from dev side and it has been forwarded to QC for verification. After verification from QC, task may have “Under Progress” status; if QC founds any issue in it or it will has “Done” status if functional and non-functional requirements have been completed. All tasks will be broken into 5 sections i.e. Dev, Unit Testing, QC, Bug Fixing and Deployment. During sprint planning every dev member is bound to give Dev and Unit Testing hours. QC will give their time of verification for a task and Release Manager (if there is any release process) will give his time for deployment. Bug fixing hours will be accumulated once the task moves to “Done” state.

Columns which are highlighted in red color are sprint days which basically show sprint progress for each resource against each segment. Hours will gradually decline as resource will work on the task and then it will reach to zero which will show the task has been finished for a particular section. From this section Scrum Master or Product Manager can critically analyze any resource or any task. Data can be grouped by resource and then can analyze for bug hours and scoped hours. Resource can also be analyze by Unit Testing and Bugs hours.

Burndown Chart

It is a chart that is displayed publicly to show the remaining work in the sprint backlog. The burn down chart is updated on daily basis and gives a simple view of the sprint progress. It also gives a quick account of reference. There are also other types of burn down, for instance the Release Burn down Chart which depicts the amount of work left to accomplish the target commitment for a Product Release (normally spanning through multiple iterations) .the other one is Alternative Release Burn down Chart, which basically serves for the same, but clearly shows scope changes to Release Content, by resetting the baseline.

Fig. 8: Template – Burndown Chart

This burndown chart can easily be made from data of Sprint Backlog i.e. (Total Hours)/(Day Worked Each Day)

CHAPTER 8

Conclusion

Conclusion

This research thesis determined that there are several factors which impacts on Scrum Implementation. Most of the issues are related to management such as quality work pileup, release process, scrum maturity in company, formal training, management interference and sprint duration are all directly related issues to management. These issues or challenges are extracted from Survey, Interviews and self experience in Scrum Implementation. Training on Scrum Framework can significantly impact on the implementation of Scrum.

CHAPTER 9

References