Agile - Agile Software Project Management Methodologies

Economy Informatics, 1-4/2005 27Agile Software Project Management Methodologies Prof. Constanţa-Nicoleta BODEA, PhD Economic Informatics Department, Academy of Economic Studies, Bucharest Successfully project planning, coordinating and controlling in order to deal effectively with projects sponsors, customers, unexpected risks and changing scope are difficult tasks even for the most experienced project managers. Different surveys indicated that about half of the software projects were considered total failures and only a few of them were successful. The tight deadlines, volatile requirements and emerging technologies are the main reasons for this lake of performance. This agile project environment requires an agile project manage-ment. The paper presents the main characteristics of the agile software project management approaches such as: MSF for Agile Software Development, Extreme Programming, Scrum, Crystal, Feature Driven Development, DSDM. Keywords: software development, project management methodology, agile project manage-ment, XP, MSF for Agile Software Development. Software project management meth-able and more efficient. We can consider a odologies 1 methodology containing ten basic elements: Methodologies impose a disciplined process techniques, tools, deliverables, teams, roles, upon software development with the aim of skills, activities standards, quality measures making software development more predict-and project values [1]. ActivitiesMilestonesPlanningTeam Values TestingQuality ProcessesTeamsRegression tests Project manager Object model Analyst MBWAProject plan Designer Use casesUse cases Tester DeliverableCRC cardsTechniquesRolesJAD facilitationEnvy/Dev.Microsoft Project Java programmingSTPUML/ C++ ModelingMS ProjectOMTPersonality StandardsToolsSkills Fig. 1. Components of a project management methodology A specific methodology is needed depending mized quality. A larger methodology (with on the project size (number of people being more control elements) is needed when more coordinated), the criticality of the systems people are involved. Communication load being created and the priorities of the project. raises as the number of people involved in-For any point in the size/criticality space, a creases. Since methodology is a matter of scope of concerns to address is selected coordinating the people and managing the (which project roles, activities, deliverables, communication, its size must also rise, as the and standards to cover) and optimization cri-number of roles and deliverables types in-teria are selected. Methodologies therefore crease [2]. differ by the size, criticality, scope and opti-Considering the project deliverables critical- 28Economy Informatics, 1-4/2005 ity the following four zones we can identify: problem than a large team. It does mean • Loss of comfort means that with a system there may be an area of overlap, where a failure, people will have to go and do more small team with a light methodology can work by hand, or call each other and repair a solve the same problem as a larger team with miscommunication. Examples might include a heavier methodology (figure 2). purchase support systems and corporate in-2. The Agile Approach frastructure programs. The agile approach started in 1994 with some • Loss of discretionary moneys zone if the trials of semi-formal agile methodologies, loss of money or related valuables is merely such as RAD, DSDM, XP, Crystal, Scrum. uncomfortable These methodologies are based on agile • Loss of irreplaceable moneys zone if the methods. Agile methods are adaptive rather loss of moneys or related valuables has effect than predictive. Engineering methods tend to corresponding to going bankrupt. try to plan out a large part of the software • Loss of life zone if people are likely to die process in great detail for a long span of from a system malfunction. time, this works well until things change. So For a project with higher criticality more their nature is to resist change. The agile visible correctness (greater density) is re-methods, however, are waiting for change. quired. Density means more precision in the Agile methods are people-oriented rather artifacts, with tighter reviews and less toler-than process-oriented. The goal of engineer-ance. ing methods is to define a process that will work well whoever happens to be using it. Agile methods assert that no process will ever make up the skill of the development team, so the role of a process is to support the development team in their work. The declaration of principles and values in the agile approach is known as the Agile Software Development Manifesto, launched in 2001, after a two day workshop at Snow-bird Utah (figure 3). A non-profit organiza- tion the Agile Alliance was set up to promote Fig. 2. Methodology weight and problem knowledge and discussion of all the agile size methods. "Weight is cost": a relatively small increase Applying these principles creates the founda-in methodology size or specific density adds tion for managing IT projects in an agile ap-a relatively large amount to the cost of the proach. The basic characteristics of this ap-project. With fewer people, less methodology proach are the following: is needed; with less methodology, the people • Assume simplicity. As the project evolves work more efficiently. Working more effi-it should be assumed that the simplest solu-ciently, they can successfully address a larger tion is the best solution. Overbuilding the problem. When more people are put onto a system or any artifact of the project must be project, they need a heavier methodology to avoided. coordinate their work. The heavier method-• Embrace change. Since The stakeholder ology lowers their productivity, so more peo-understanding of the requirements will ple are needed on the project. Since method-change over time. Project stakeholders them-ology size grows slower than project size, selves may change as the project makes pro-eventually they get to a point where they can gress. Project stakeholders may change their solve the problem and manage the coordina-point of view, which in turn will change the tion activities. This does not mean that a goals and success criteria of the project man-small team can necessarily solve a larger agement effort. Economy Informatics, 1-4/2005 29• Incremental change – the pressure to get it time. Or simply discard it when you no right the first time can overwhelm the best longer need it in an incremental manner. project manager. Instead of futilely trying to • Maximize stakeholder value. The project develop an all encompassing project plan stakeholders are investing resources (time, from the start, put a stake in the ground by money, facilities) to have a system deployed developing a small portion of the system, or that meets their needs. Stakeholders expect even a high–level model of a larger portion that their investment to be applied in the best of the system, and evolves this portion over way. “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: : Individuals and interactions over Processes and Tools. : Working software over Comprehensive documentation. : Customer collaboration over Contract negotiation. : Responding to change over Following a plan. That is, while there is value in the items on the right, we value the items on the left more.” Fig. 3. Agile Software Development Manifesto • Manage with a purpose Identify a valid the project stakeholders. The goal is not to purpose for creating the artifact and the audi-produce extraneous documentation, man-ence for that artifact. This principle also ap-agement artifacts or models of these artifacts. plies to a change to existing artifacts. 3. Some Agile Software Project Manage-• Rapid feedback. The time between an ac- ment Methodologies tion and the feedback on that action must be The agile approach focuses on: talent & skill minimized. Work closely with the stake-(fewer better people), proximity (direct and holders, to understand the requirements, to face-to-face communication), less paper, analyze those requirements, and develop an more tacit / verbal communication, just-in-actionable plan, which provides numerous time requirements and design, frequent De-opportunities for feedback. livery (incremental development), reflection, • Working software is the primary goal of quality in work. So, the people are very close the project. The goal of any software project related to the agile methodologies (figure 4). is to produce software that meets the needs of ActivitiesMilestonesPersonalityPlanningTeam ValuesTestingQuality ProcessesTeamsPeopleRegression testsProject managerObject model AnalystMBWAProject plan DesignerUse casesUse cases TesterDeliverableCRC cardssTechniquesRolesJAD facilitationEnvy/Dev. Microsoft Project Java programmingSTP UML/ C++ ModelingMS Project OMT Standards ToolsSkills Fig. 4. Components of an agile project management methodology 30Economy Informatics, 1-4/2005 3.1 Extreme Programming (XP) method-jects require different kinds of methodolo-ology gies. The Crystals share a human orientation The roots of XP lie in the Smalltalk commu-with XP, but this people-centeredness is done nity, in the close collaboration of Kent Beck in a different way. Alistair considers that and Ward Cunningham in the late 1980's. people find it hard to follow a disciplined Both of them refined their practices on nu-process, thus rather than follow XP's high merous projects during the early 90's, extend-discipline; Alistair explores the least disci-ing their ideas of a software development ap-plined methodology that could still succeed, proach that was both adaptive and people-consciously trading off productivity for ease oriented. The crucial step from informal of execution. He thus considers that although practice to a methodology occurred in the Crystal is less productive than XP, more spring of 1996. Kent was asked to review the people will be able to follow it. progress of the C3 payroll project for Chrys-Alistair also puts a lot of weight in end of it-ler. The project was being carried out in eration reviews, thus encouraging the process Smalltalk by a contracting company and was to be self-improving. His assertion is that it-in trouble. Due to the low quality of the code erative development is there to find problems base, Kent recommended throwing out the early, and then to enable people to correct entire code base and starting from scratch. them. This places more emphasis on people The project then restarted under his leader-monitoring their process and tuning it as they ship. XP begins with four values: Communi-develop. cation, Feedback, Simplicity, and Courage. It 3.3 Scrum then builds up to a dozen practices which XP Scrum has been around for a while in object-projects should follow. Many of these prac-oriented circles. It focuses on the fact that de-tices are old, tried and tested techniques, yet fined and repeatable processes only work for often forgotten by many, including most tackling defined and repeatable problems planned processes. As well as resurrecting with defined and repeatable people in defined these techniques, XP weaves them into a and repeatable environments. synergistic whole where each one is rein-Scrum divides a project into iterations (which forced by the others. It is a strong emphasis they call sprints) of 30 days. Before you be-on testing. While all processes mention test-gin a sprint you define the functionality re-ing, most do so with a pretty low emphasis. quired for that sprint and then leave the team However XP puts testing at the foundation of to deliver it. The point is to stabilize the re-development, with every programmer writing quirements during the sprint. tests as they write their production code. The However management does not disengage tests are integrated into a continuous integra-during the sprint. Every day the team holds a tion and build process which yields a highly short (fifteen minute) meeting, called a stable platform for future development. scrum, where the team runs through what it On this platform XP builds an evolutionary will do in the next day. In particular they sur-design process that relies on refactoring a face to the management blocks: impediments simple base system with every iteration. All to progress that are getting in the way that design is centered on the current iteration management needs to resolve. They also re-with no design done for anticipated future port on what's been done so management needs. The result is a design process that is gets a daily update of where the project is. disciplined, yet startling, combining disci-Scrum literature focuses mainly on the itera-pline with adaptivity in a way that arguably tive planning and tracking process. It's very makes it the most well developed of all the close to the other agile in many respects and adaptive methodologies. should work well with the coding practices 3.2 Crystal methodologies from XP. Alistair developed this family of methodolo-3.4 MSF for Agile Software Development gies considering that different kinds of pro-MSF provides a customized and scalable set Economy Informatics, 1-4/2005 31of software development guidelines for ap-• Source check-in policies plication development improvement ([5]). • Role clusters and security groups MSF incorporates both agile and formal ap-• Document templates (Excel and Word) proaches, and then allows the user to select • Microsoft Project templates the most suitable path. MSF's flexible • Reports framework can be adapted to meet the needs • Project portal /SharePoint site template of any project, regardless of size or complex-MSF uses methodology templates to define ity. the process that individual projects follow. The MSF philosophy holds that there is no There is no universal process that works for single structure or process that optimally ap-all organizations, or even all projects within plies to the requirements and environments an organization. To address this, MSF pro-for all projects. MSF provides this guidance vides a flexible toolset that works with both without imposing prescriptive detail and al-agile and formal processes. Microsoft's lows the user to customize the content pro-Global Solution Integrator partners provide vided. MSF components can be applied indi-their own product consumable methodology vidually or collectively to improve success templates; or, you can create your own. Proc-rates for the many types of projects. MSF ess extensibility allows customization of guidance focuses on managing the "people work item types, check-in policies, custom and process." Because the needs and prac-reports and project management templates. tices of software development teams are con- stantly evolving, the materials gathered into Conclusions MSF are continually changing and expanding Getting projects faster is a universal desire of to keep pace. Additionally, MSF interacts management. The reality of project manage-with Microsoft Operations Framework ment is that we never really have the time to (MOF) to provide a smooth transition to the create perfect plans, to analyze all the op-operational environment, which is a require-tions. Agile approach provides some methods ment for long-term project success. for project management to become more ef-With MSF, process is not just documenta-fective. These methods need to be taken and tion. It also manifests itself as actual tool be-customized to the unique business environ-havior changes. When you chose the process ment of the project. at project inception, you are also choosing the workflow and work products, which then References drive how the system behaves. Support for 1. Alistair C. A Methodology Per Project, the software development life cycle process (arc@acm.org), Humans and Technology. (SDLC) is built-in, which makes for seamless 2. Harrison, N., Coplien, J, "Patterns of pro-workflow support. By integrating process ductive software organizations", Bell Labs into the tools team members use on a daily Technical Journal, summer, 1996. basis, MSF lowers the barrier to adopting 3. Jeffries, R., Beck, K., Extreme Program-process and enables the automatic collection ming, http://armaties.com/extreme.html. of cross-functional project metrics without 4. Fowler M, The New Methodology, Martin the overhead associated with manual report-Fowler.com ing. 5. Microsoft, Visual Studio 2005 Team Sys-The following elements of MSF are custom-tem: Microsoft Solutions Framework, 2004, izable: www.Microsoft.com . • Process Guidance 6. http://crystalmethodologies.org/ • Iteration structure • Entry criteria and exit criteria views • Work item type definitions and rules (ac-tivities and work products) • Work item queries