Agile Management Tools: Scrum Scope Literature Synthesis

Transcription

1 Agile Management Tools: Scrum Scope Literature Synthesis Alexander Kivaisi Department of Computer Science University of Cape Town May 3, 2010 Abstract: Scrum has grown rapidly within these few years. Many companies have shifted to this simple, adaptive and flexible framework. But with this tremendous growth it is vital to review the agile tools which support this outstanding methodology during project development life time. This paper discusses some current category tools base on their strengths and weaknesses on planning, tracking, usability and other essential features while showing how each tool attempting to resolve problems mutually. It finalize with the summary table of category tools and future recommendation work necessity.

2 1 Introduction Scrum is an agile methodology used in software development process. This iterative framework allows the Scrum master and the scrum team to manage the software projects. It adapts to requirement changing at the same time enables the development team to work without any disruption. Scrum has been existed in the agile software development field for fifteen years now. It has been used in many top organizations in the world such as Yahoo, Google, IBM [8], and many gaming development companies. It is now considered one of the top agile methodology used compare to other, such as Extreme Programming (See figure 1). Due to its simple adaptive framework and organizational focus is the reason why most of the companies out there prefer it [4]. Figure 1: Most Agile Methodologies in use The scrum process consists of many activities (See figure 2). In the earlier stage, the product backlog document is produced which contains the list of prioritized customer requirements. In this time of stage the requirements can change at any time based on the customer needs. The sprint backlog is produced in the next stage, which contains the information about what requirement and how the team is going to implement these requirements for the upcoming sprint. During the sprint stage, there are normally daily meetings which are usefully for checking the status of the project. At the end of the sprint stage, the team delivers the product to the customer. The customer then checks the product backlog to see which items have been completed in the sprint, and discusses with the scrum team and the stakeholders how best to prioritize the product backlog for the next sprint. So if the scrum management community were about to do this manually it will be difficult to them to either manage or tracking each project during the software development life time. Therefore, it is essential at their disposal to have tools that enable them to gather user requirements, planning iterations, tracking progress and producing reports.

3 Figure 2: Shows scrum process more in detail 2 Agile management tools Although, we will concentrate much on current agile management tools but we will also step back discussing some old fashion way of dealing with scrum process. The evaluation of the tools will be based on planning thus how easy and quick to produce the plan quickly; tracking thus how easy and quickly to track and monitor the sprint progression or overall project; and usability thus flexibility to navigate through the system and ability to add, modify and update items. Furthermore, we will see how each tool tries to solve the limitation which appears on other tools. 2.1 Manual Tools Descriptions The old fashion of handling the requirements gathering was done using hand-written documents (See figure 3). This documents which contains the list of prioritized stories was then transformed to sprint backlog. The stories and the estimated time to complete each of them were structured on the table either on the paper or the dashboard to keep track. The table

4 was updated on each successful complete sprint task item with number of hours remaining for each story [7]. Figure 3: Shows document containing stories to be completed during sprint Apart from paper based that supports prioritization of stories, index cards or note cards were also major artifacts that support project planning process. Each new card consists of new task and they were prioritized by sorting the cards [3]. In addition to planning, they were used to come up with user stories or used during sprint reviewing [1]. The sticky notes, task board and the burn down chart are considered to be the most commonly used for tracking iterations during the sprint stage [9] (See figure 4). They are displayed on either the wall or the whiteboard. Each day the chart is updated, and helps to visualize the overall picture of the overall project.

5 Figure 4: Glass windows acts as the dash-board containing sticky notes and burn-down chart Benefits Dubakov et al in [1] and Wang et al in [3] both pointed out that the index cards are flexible. Wang et al added by saying that flexibility of using index cards helps developers plan the project in a convenient manner. In [1] further pointed out that they are easy to use when working in a group as well as useful during the management of sprints. While in [3], explains that how easy they are used among meeting participants for interactions. They added by emphasize that index cards improve the collaboration among all stakeholders while the collaborative environment improves the effectiveness of project planning and help shape the group into a unified and well-communicating team [3]. This is actually true when you are not working in the distributed team; the team only is sited at one place. If teams or members of team are isolated, then it becomes difficult on either to plan or manage Drawbacks It is hard to reuse data when using index cards [1]. They are not safe in a sense of security. There is no mechanism for backing up the cards. If they are lost that s it, you will need to redo all the process of getting requirements again. This leads to addition costs which were not in the plan before. Besides that sharing planning artifacts among spatially-separated environments becomes challenging, and interaction among planning participants are more difficult [3]. Wang el al in [3] noted that making decisions becomes much harder than that in co-located projects meetings. There is less communication within a distributed team than colocated one. Respectively, problems are not reported until they are bigger. Furthermore, they pointed out that misunderstandings are raised and the chance of rework is increase significantly [3]. While in [1] pointed out that although web cams and skype connections are used to broadcast the task board to remote sites, but even that seems like a weak alternative.

6 2.2 Traditional Tools Description A tool which falls under this category is mainly Microsoft Project (MS Project). Behrens et al in [4] shows that it can be used in non agile process such as requirements management, item flow tracking and mostly project management [4]. Apart from that, project management software can schedule a series of events, people and resources (See figure 5). In addition to that it can arrange tasks to meet various deadlines. Some of the features can be mapped to agile team needs and serve without problems. Dubakov et al in [1] gave an example of release and iteration plan maintenance may be done in traditional project management tools without problems. Figure 5: Microsoft Project shows iteration plan Benefits Besides its existence in various companies for long time now, its tracking system tends to offer a better alternative including: ease of use, flexibility and workflow support [4]. Behrens in [4] further pointed out that, tracking of work items and tasks follows a very dynamic but regular workflow. Items get selected for an iteration, they are assigned to or picked by specific team members, are marked in process, and then complete. Other team members can see progress against those items and coordinate iteration activity accordingly.

7 2.2.3 Drawbacks Dubakov et al in [1] pointed out that traditional tools do not support well the required agile practices in general. The product backlog support does not exist in the classic project management tool. You will normally find that main tools used here are spreadsheets. Both the burn down reports and task board are not supported in traditional project management tools as well. 2.3 Spreadsheets Description Most companies have been use spreadsheets such that of Microsoft Excel for producing the quick simple prioritized list of items in the product backlog and sprint backlog. The spreadsheet may contain only five columns: Name, effort, priority, estimate and reference number column to make it easier to find individual stories [1]. It should be updated daily to keep track the stories status. The auto-generate sprint burn down graph can be helpful as well (See figure 5). The major important thing is that it shows the team their actual progress towards their goal and not in terms of how much time has been spent so far, but in terms of how much work remains-what separates the team from their goal [5].

8 Figure 6: Burn-down graph generated from spreadsheet data Benefits Behrens in [4] shows that the spreadsheets are simple and flexible in creating attributes such as priority, estimate, status and others while providing easy sorting and filtering capabilities based on attributes. Dubakov et al in [1] supported the argument by saying that you can slice and dice the data as you see fit. Moreover, in [1] pointed out that not only data reuse was possible but also backup was not a problem anymore due PC backup mechanism provision. So the person dealing with data does not have to worry about backing up, the job is left to administrator of the PC who will set automatically when to do backup. It could be done daily or weekly. The spreadsheet data can be imported to other tools such as ExtremePlanner [10] Drawbacks Although spreadsheets can be done electronically, but many teams still believe it is easier and more effective to do it on paper taped to a wall in their workspace, with updates in pen [5]. Dubakov et al in [1] mention that spreadsheets do not work well with distributed teams as well in large size teams especially for management. The file locking problems stated in [1], is another drawback which hinders both the customer and team members together to have writable rights to the sheet file. Furthermore, [1] stated that the spreadsheets are limited to reporting as well as visibility.

9 2.4 Wiki Description Wiki are mainly used mostly in content management. But there are teams which have adopted to be useful in scrum development management [1]. In [5], they allow any team member to edit or create new pages. These new pages can be used to publish story cards so that software developers and project managers can access them and check their tasks Benefits Behrens in [4] described that wiki can be seen as a display of a self-organizing team, as its structure is completely flexible, just as the typical agile team structure. He additionally explained how wikis showed significantly higher use during release tracking compare with traditional tools (MS Project). In [3] supported the argument of being used as tracking tool since they are considered to be asynchronous platform for agile developers communication. But also in [5], pointed how useful the automated generated burn-down graphs, they were, to visualize the project progress. Besides that, Wang et al in [3] described their usage in story card management. They can be access by software developers and be updated daily. In case of unsolved problems or need of assistance during the development, the software developer can post a question and all other member can view and provide with solutions. Since the time for daily scrum meetings is too short to solve all issues raised, wiki seems to be the solution Drawbacks Dubakov et al in [1] pointed that wikis are not the best way of managing backlogs if you compare with spreadsheets. In order to search for things, you need a good understanding of the wiki system. They further recommended that a good search tool is needed to use the wiki. As for other tools, wikis do not work for distributed teams. 2.5 Web Based Software Description The concept behind web based software is that it uses web forms which act as a carrier to publish agile planning data on the web. It also provides the feature of managing that data by either updating or deleting items in the forms. Most of the web base software tries to mimic some of the manual tools such as index cards and burn down graphs. While other software endeavor to include the almost all development process such as requirements management, planning, tracking, quality assurance and feedback gathering under one platform [1].

10 2.5.2 Benefits The web based software solves the problem of distributed teams and large teams which were not supported on most the previous tools. Through these tools such as Rally, VersionOne and ScrumWorks, it becomes easy to share data among distributed agile developers [3]. Figure 7: Rally Web form based software Web based software for instance Rally (See figure 7), tends to offer more structure agile planning data than wiki pages. Besides that, it is also a good tracking tool through the use of generated burn down chart which help project managers and scrum team to understand the progress of their projects [3]. While Rally [2] and VersionOne[6] are considered to be more user friendly. The drag and drop features which let the user to drag stories and features to iteration makes them more flexible and easy to use. The right to access shared resources as long as you are in the same authorized group is not a problem anymore. If you compare with spreadsheets files where denial of accessibility to a sheet file may appear very often, with user management system it is quite easy to group together certain users with the same authority Drawbacks Since the web based forms tools are only for asynchronous usage, Wang et al in [3] stated that synchronous agile planning, particularly the project planning meetings are not supported. The team members still, rely on index cards and the dashboard to plan because of flexibility. Although the tool so called Distributed Agile Planner (See figure 8) tend to solve this problem, but it has been observed that participants in the meeting do not seem to be involve in the planning process compare to traditional agile planning process [3]. Dubakov et al in [1] pointed that some of the commercial web based tools are quite expensive. This may actually tend to limit users accessibility to good features which are offered commercially but not in open source distributions tools.

11 Figure 8: Distributed Agile Planner with Telepointers and Digital Cards 3 Conclusion We have seen how each tool tends to offer different features which suite the users needs. Some tools are limited to the size of the team and others are limited to either separation of teams or teams members. You may also find the tool which only offers features on either one or more stages of development process thus either requirement gathering or during iteration process but not all of them. (See Table 1) There are organizations that prefer multi-tools thus each development process stage has its own tool. But the problem still remains on flexibility of transferring data consistently between one tool and another. Some teams prefer the web based agile tools which offers integration among development process but even that some tools seem cumbersome while other partially provide the essential features. As it was pointed in [3], until now most of the agile tools do not well support synchronous interactions, thus implies the necessity to the scrum planning meetings in upcoming future.

12 Features Manual Tools Traditional Tools Spreadsheets Wiki Web-Based Software Requirements S N-S P-S P-S S Gathering Planning Easy Difficult Medium Difficult Easy Tracking N-S S S S S Reporting N-S P-S P-S P-S S Reuse Data N-S P-S S S S Crossfunctional N-S N-S N-S N-S S Team Backup N-S P-S P-S P-S S Sharing Medium Medium Hard Medium Easy Resources Technical Assistance N-S N-S N-S S S N-S: Not Supported P-S: Partially Supported S: Fully Supported Table 1: Summary of Agile tools supportive features Although there is still a need for new tools which may fully provide all together the important features for requirement gathering, planning, tracking and producing reports but I still think, selection of a tool to use depending on type and size of the scrum team also has to be considered before starting the project. Both small and large scrum teams projects require different features and different functionalities requirements, similarly to distributed teams and non-distributed teams.

13 4 References [1] M.Dubakov and P.Stevens, Agile Tools: The Good, the Bad and the Ugly, TargetProcess, Inc., [2] Arjan C. Schokking, Project Planning and Tracking System: A comparative analysis, Philips Research Report, March 23, [3] X. Wang, F. Maurer, R. Morgan and J. Oliveira, Tools for Supporting Distributed Agile Project Planning, review paper, Calgary, Alberta, Canada. [4] P. Behrens, Agile Project Management: Tooling Survey Results, Trail Ridge Consulting Report, December, [5] J. Sutherland and K. Schawaber, The Scrum Papers: Nults, Bolts, and Origin of Agile Process, PatientKeeper, Inc., Newton, MA October [6] C. Hedin and S.O Birgisson, Introducing the Agile Requirements Abstraction Model Requirements Engineering in a Scrum Environment, Master Thesis, Lund University, Tactel AB, October [7] A. Srirangarajan, The Scrum Process for Independent Programmers, Master Thesis, Auburn University, Alabama, May [8] The Scrum Community Subteam, A Practical Guide to Distributed Scrum. Available: April [9] H. Kniberg, Scrum and XP from the Trenches: how we do Scrum, Crisp. Available: April [10] Last access: April 2010.