Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

PM Chapter on Agile IT Project Management Methods

4,789 views

Published on

The nations prosperity depends of information technology (IT) software. The nation’s IT software industry depends on the timely delivery of high quality products to eager customers. This industry is slipping further behind in quality and timely delivery every year. The gap continues to grow.

Published in: Technology
  • Be the first to comment

PM Chapter on Agile IT Project Management Methods

  1. 1. In: The Story of Managing Projects: A Global, Cross–Disciplinary Collection of Perspectives, Dr. E. G. Carayannis and Dr. Y. H. Kwak, editors, Greenwood Press / Quorum Books, 2002 AGILE PROJECT MANAGEMENT METHODS Our nations prosperity depends of software. The nation’s software industry depends on the timely delivery of high quality products to eager customers. This industry is slipping further behind in quality and timely delivery every year. The gap continues to grow. One question this book attempts to answer – what approaches to managing information technology projects can be applied to this problem and others encountered by organizations dependent on software for their economic success? You cannot win in today's marketplace using yesterday's processes. — Dr. H. James Harrington Glen B. Alleman Niwot, Colorado 80503 glen.alleman@niwotridge.com
  2. 2. In: The Story of Managing Projects: A Global, Cross–Disciplinary Collection of Perspectives, Dr. E. G. Carayannis and Dr. Y. H. Kwak, editors, Greenwood Press / Quorum Books, 2002 Table of Contents 1 Table of Contents AGILE PROJECT MANAGEMENT METHODS FOR IT PROJECTS................................... 1 Weight Versus Agility................................................................................................................ 2 Some Sobering Facts about IT Projects......................................................................................... 3 The Taxonomy of Methods ..................................................................................................... 4 What Type of Methodology ............................................................................................ 6 Agile Is Not The Same Of Lightweight................................................................................. 7 A Brief History of IT Project Methods.................................................................................. 7 Project Management Framework..................................................................................................... 8 Activities within Framework.................................................................................................... 9 The Methodology Zoo............................................................................................................10 Management Dimensions of Project Management ...........................................................11 The Agile Software Delivery Process.............................................................................................12 Common Problems with All Software Projects .................................................................12 The Problem of Change..........................................................................................................13 Ready For Agility?....................................................................................................................13 The Forces Driving Agility..............................................................................................................14 Practical Agile Project Management..............................................................................................14 Common Threads of These Methods..................................................................................15 Is Agile Yet Another Software Methodology Taxonomy?...............................................16 Project Management Drivers .................................................................................................17 Framework for Agile PM Methods.......................................................................................18 Nine Best Practices ..................................................................................................................19 Management Engagement......................................................................................................20 Applying the Nine Best Practices..........................................................................................21 Agile Project Management Summary............................................................................................24 Values of Agile Project Management ...................................................................................24 Applying Agile Principles in Practice....................................................................................25 Bibliography.......................................................................................................................................28
  3. 3. 2 Agile PM Methods Table of Figures Figure 1 – Factors Affecting Successful And Unsuccessful Projects................................................ 4 Figure 2 – Business Centric Software Process....................................................................................... 5 Figure 3 – Generic Project Management Activities.............................................................................. 7 Figure 4 – Interrelation Between Project Management Activities ..................................................... 9 Figure 5 – A IT Project Management Framework..............................................................................10 Figure 6 – Management Responsibilities Applied to a General Process ........................................11 Figure 7 – National Software Quality Experiment Results ...............................................................13 Figure 8 – Common Aspects Of All Methods ....................................................................................15 Figure 9 – Software Systems Taxonomy...............................................................................................16 Figure 10 – Tensions On The Software Development Project Manager.......................................18 Figure 11 – Nine Best Practice Principles.............................................................................................20 Figure 12 – Nine Best Practices of a Success Software Project........................................................24
  4. 4. Lean PM Methods 1 C h a p t e r X . AGILE PROJECT MANAGEMENT METHODS FOR IT PROJECTS The difference between failure and success is the difference between doing something almost right and doing something right. — Benjamin Franklin Agile project management methodologies used to develop, deploy, or acquire information technology systems have begun to enter the vocabulary of modern organizations. Much in the same way lightweight and agile manufacturing or business management processes have over the past few years. This chapter is about applying Agile methods to an environment that may be more familiar with high ceremony project management methods – methods that might be considered heavy weight in terms of today’s agile vocabulary. High ceremony projects include projects based on formal or semi–formal project management methods, ones like Prince2 [1] , PMI’s PMBOK [2] , or processes based on the Software Engineering Institute’s Capability Maturity Model [3] . These methods are traditionally associated with organizations which operate in software engineering centric business domains. These domains view software activities as an engineering process, rather than a creative process. Organizations that have mature processes usually define their activities in a formal manner, apply these methods with some form of rigor, and monitor the processes and results carefully. These practices have usually been built up over time and come about through past experiences – either good or bad. They usually represent a formal structure of the underlying business process. 1 Projects IN Controlled Environments (PRINCE) is a structured project management method used in the UK. 2 Project Management Body of Knowledge (PMBOK) is an ANSI Standard PMI–99–001–2000 describing the various attributes of a project management method. 3 Capability Maturity Model is a collection of model frameworks for assessing the maturity of a specific practice. Key Practice Areas are used to define the various levels of maturity. CMM now consists of: Software, People, Software Acquisition, Systems Engineering, and Integrated Product Development. This models are supported by a software process assessment standard ISO/IEC 15504.
  5. 5. 2 Agile PM Methods It is common to talk about Agile methods for modern project management processes in the context of a set of lightweight activities used to manage the aspects of software development or acquisition. These are requirements, design, coding, and testing processes based on a minimal set of activities needed to reach the end goal – a working software system. Although some of these agile methods address the management aspects of software projects – people, processes, and technology – they are primarily focused on coding, testing, and software artifact delivery. [4] Applying the concept of agility to the management of software project is a natural step in the evolution of software development. One important question to be asked is how can these minimalist approaches be applied to project management problems? n What project management process simplifications are appropriate in a specific problem domain? n Are all light weight and agile project management processes applicable to all problem domains? These questions and others will be addressed in this chapter. Weight Versus Agility In the information technology project management literature, lightweight is often defined as not heavyweight, which of course is a tautology. As time went on the term lightweight was superceded in the popular press by Agile. Lightweight and Agile are not actually interchangeable words. Lightweight describes the weightiness of the process and its artifacts. The amount of potentially non–value added artifacts produced by a specific process. This weightiness can be attributed to the undesirable consequences of the process – artifacts that don’t provide benefit to the outcome. This weightiness can also be attributed to the mis–application of a specific process. Agility describes the behavior of the participants and their ability to move or adjust. Much like an overweight boat or airplane, the undesirable weight needs to be removed in order to increase the efficiency of the vehicle. This is a standard best practice in many engineering disciplines. One problem with this analogy though is that those who suggest that a specific process of being over weight must first answer the question: 4 Some proponents of these lightweight methods contend delivery of software is the only goal. Although this is an obvious outcome of the programming and integration process, there are many other deliverable artifacts associated with large scale software projects.
  6. 6. Lean PM Methods 3 … if a project management method were properly applied, in the proper domain, to the proper set of problems, with properly trained participants, would it be considered overweight and produce undesirable consequences? The usual answer is no, of course not. If everyone were doing their job properly in the proper engineering, regulatory, and contractual environment, then the results would be accepted by all the participants – this is the definition of a tautology. So the problem of project management methodology selection is compounded by the behaviors of the method as well as the behaviors of the participants in the method. In addition, the appropriateness of the process for a specific problem domain is also an issue. Some Sobering Facts about IT Projects Numerous reports have analyzed why software projects fail. Here’s a summary of the findings, ranked by importance from high to low, summarized from [Connolly 96], [Royce 98], [Standish 95], and [Defense 94]: Before we get too far along in the discussion of Agile processes, it would be good to recap what the data in Figure 1 means. The majority of the items associated with both the success and failure of projects are related to the management of the software process. This includes stakeholder participation, clear requirements from the stakeholders, stabilizing these requirements, managing the fulfillment of these requirements, tracking these requirements, and verifying that the requirements have been fulfilled in some way. One of the tenants of Agile process is that the requirements will become clear as the project evolves. That changes in these requirements can be absorbed by the development team, since they are continually redacting the resulting anyway. This is the challenge in discussing Agile processes — are these process appropriate for the general population of software development projects and products, or are they suited for specialized environments in which the requirements can be discovered during the development process?
  7. 7. 4 Agile PM Methods Successful Projects Challenged Projects User Involvement High Lack of user input Executive sponsorship and support Incomplete requirements Clear statement of the requirements Changing requirements Proper planning Lack of executive sponsorship Realistic stakeholder expectations Technology incompetence Small project milestones Lack of resources Competent staff Unrealistic expectations Stakeholder ownership Unclear objectives Clear vision and objectives Unrealistic time frames Focused staff Low New technologies Figure 1 – Factors Affecting Successful And Unsuccessful Projects The Taxonomy of Methods The definition of a software process is embodied in how a software organization does business, that is, how management and engineering practices are implemented to support software development and its maintenance. This view of software process assumes that an organization has a set of building blocks that defines the general way it does business and that some subset of those building blocks is implemented for each software project. Software Technology Support Center, Hill Air Force Base, Ogden Utah This business–centric definition of the software process assumes there are two basic development categories – project centric and product centric. They are both based on the delivery of some form of value for the stakeholder. However, there are different forces at work in each category. Understanding the difference between them is an important factor in choosing a methodology for the delivery of this value [Nakajima 89]. Project Centric Process Product Centric Process
  8. 8. Lean PM Methods 5 Describe and organize the work Specify and create a product Manage the work of the team in the delivery of the project components Manage the work of the team in the delivery of the product and all it’s associated components. Project Delivery focused Product Lifecycle focused DELIVERABLE VALUE Figure 2 – Business Centric Software Process With these differences in mind, there are sub–tasks that further define project activities: n Requirements elicitation – architectural and design artifacts need to be gathered, reviewed and approved. n Design – artifacts that describe what software is to be produced as well as associated documentation, maintenance, installation, and upgrade processes. n Programming – computer programs that are developed, delivered, and maintained. n Testing – artifacts attesting to the correctness of the code and its compliance with the requirements. No matter what a project management method is called, what the method claims to contribute, and especially no matter what special powers are attributed to the project management methodology, there are a small number of essential attributes that any project management method must posses in order to deliver value to the stakeholders [Blum 94]. n An application domain – in which the problem exists. The generalization of a project management process must take into account the business domain. Applying a specific methodology to the wrong domain can have the same effect as applying the wrong methodology to the right domain. Both result in some type of failure for the project. n A conceptual model – that references a formalism in the domain of interest. These models are descriptive in nature and provide guidelines for making decisions about the problems encountered in the application domain. n A formal model of some kind – establishes the rules for the acceptance and correctness of the methodology. These models are prescriptive in nature and describe the steps, actions, outcomes, and relationships between each of them.
  9. 9. 6 Agile PM Methods n An implementation domain – which provides the means of solving the problems encountered in the application domain using a conceptual or formal model of a method. All this formality is meant to bring light on the fact that any discussion of project management methodology is complex and fraught with confusing and sometimes contradicting terms, concepts and claims. What Type of Methodology A software project management methodology lives within a greater context of a business process improvement process. The concepts of generic project management are usually lost in this modern age of the Internet and Agile process. If we look back to the origins of successful high technology organizations, one primary source is The Management of Innovative Technological Organizations [Ramo 80]. The books author, Simon Ramo, is the R in TRW. The processes in this book are the antithesis of Agile, but the principles are timeless. [5] n Initiate through some official recognition that a project has been formed. n Plan by creating and maintaining a scheme to accomplish the work at hand. n Execute through people and resources. n Control through a means that assures the project objectives are being met. n Close the project through some formal acceptance process. 5 These simple concepts are repeated in nearly every textbook on project or business management. The source fro this list is probably lost. My best source is My Years with General Motors, Alfred P. Sloan Jr., Double Day, 1963. This approach to project methodologies is far from Agile.
  10. 10. Lean PM Methods 7 Figure 3 describes how these steps are related to each other. Any process, Agile or heavyweight, must provide these steps in some form. Initiating Planning Controlling Executing Closing Figure 3 – Generic Project Management Activities Agile Is Not The Same As Lightweight The term Agile does not directly describe the weightiness of a method or its artifacts, but rather describes the ability of the method to deal with the external and internal forces it encounters in the business environment. The methods ability to deal with these forces in an agile manner. This issue will be developed further but for now the reader should remember to differentiate between the weight of a method and its artifacts and the agility of a method to deal with the forces its encounters during its application. A Brief History of IT Project Methods In the 1980’s the development of large business software applications was factory centric. Large volumes of code were generated by equally large volumes of programmers. The consequences of this horde approach have been well documented in [Brooks 95], [Brooks 87]. As early as 1956 the concept of software process entered the lexicon [Bennington 56]. The discussion of software process improvement has a long history, with varied results even to this day. In the last several years, the landscape has changed dramatically on both the supplier and consumer side of the software development business. Time to market
  11. 11. 8 Agile PM Methods pressures, rapidly changing requirements, the Internet, and new and powerful programming languages have placed new forces on the traditional software development organization. One source of modern process improvement started with Royce’s waterfall model, [Royce 70]. From this, an interactive enhancement improved on the original waterfall process [Basili 75]. The mid–1980’s produced several new processes including the spiral model of Boehm, which evolved from a risk management point of view [Agresti 86]. Process programming emerged from formal modeling techniques in the late 80’s [Osterweil 87], [Osterweil 97]. Software process improvements continue to occupy an important place in research as well as the commercial market place [Humphrey 99]. The concept of agility has been discussed in detail for the hardware development domain [Goldman 95]. Similar research and discussion has not taken place in the same manner in the software domain. This leaves a gap in the academic approach to the subject. To date this gap has been filled by anecdotal accounts of Agile processes being applied a variety of development domains, but extensive survey has not been conducted in any formal manner, nor has a scientific analysis of the agile process domain been produced. Project Management Framework According to [SEI 96] a methodology must posses certain attributes in order to meet the requirements is being called a methodology. Figure 5 describes the engineering and development attributes of a methodology as well as the constraints placed on those attributes. An alternative to [SEI 99] is the Software Engineering Body of Knowledge [SWEBOK] that contains yet another set of attributes for development methods to be used by any professional software engineer. For the moment we’ll focus on the SEI’s description of the software project attributes. Figure 4 describes how these attributes could be related in an agile project management method. [Cockburn 99]
  12. 12. Lean PM Methods 9 Milestones Activities Teams Management Processes Management Methods Roles People Skills Work Environment Tools Techniques Products Quality Standards Development Environment Figure 4 – Interrelation Between Project Management Activities Activities within Framework Another view of this project management framework is the activities that must be performed in order to satisfy the deliverables of the project. That is delivery products or projects within the constraints of the project – time, budget, quality, and features. Figure 5 is a summary of some of these activities. Performing these activities in an Agile manner becomes a critical success factor for the project.
  13. 13. 10 Agile PM Methods Figure 5 – A IT Project Management Framework The Methodology Zoo There are numerous project management methodologies in use today. Any list of methods and methodologies must be considered a snapshot of what’s in practice and in the literature today. Each of these methods, and the list grows daily, provides some form of process or steps shown in Figure 3. Such a list is not meant to be of any real use, only to show Engineering Attributes Development Attributes Development Constraints Requirements Describes the stability, completeness, clarity, validity, feasibility, precedent, and scale of the system requirements. Development Processes Including formality, suitability, process control, familiarity, and product control. Resources Including schedule, staff, budget, and facilities. Design Describes the functionality, difficulty, interfaces, performance, testability, physical constraints, and non– functional aspects of the system. Development System Including capacity, suitability, usability, familiarity, reliability, system support, deliverability. Contract(s) Including type of contract, restrictions stated in the contract, and dependencies defined by the contract. Code and Testing Describes the programming artifacts and their testability. Management Processes Including planning, project organization, management experience, and program management. Interfaces Including the customer, associate contractors and subcontractors, corporate management relationships, vendors, and the all–powerful political influences. Integration and Test Describes the environment, product, and system behaviors aspects of the product when it is in use. Management Methods Including monitoring, personnel management, quality assurance, and configuration management. Specialties Describes the various abilities of the system, including maintainability, reliability, safety, security, usability, and other non–functional specifications. Work Environment Including quality attitudes, cooperation, communication, and morale.
  14. 14. Lean PM Methods 11 that the latest set of Agile methods have a long, rich, and possibly sorted history [Corry 96], [Fowler 99], [Bowen 99], [Blum 94], [WIKI 00], [Tausworthe 77], [Tausworthe 79], [Sutherland 00], [Cockburn 00], [Ciapessoni 99], [Boehm 85]. In addition to this list of traditional methods, there is a growing list of process and organizational patterns that describe the software related activities of a development group that are outside the actual programming process [Coplien 95]. These patterns are recorded in the PLoP books [Coplien 95a], [Vlissides 95], [Martin 97], [Harrison 98]. Management Dimensions of Project Management One of the primary gaps in a Agile process is the creation of traceability artifacts from the development method to the management practices found in modern business. Some Agile processes have very little to say about the management function, others have formal interactions with management. Figure 6 describes these management practices in the context of a methodology. Management Responsibility Management Action in Pursuit of this Responsibility Integration The coordination of the elements of the project. Scope Ensuring that all requirements are included, as well as only those requirements are included. No more no less. Time Ensuring timely completion of the project. Cost Ensuring that the project completes within budget. Quality Ensuring the project satisfies the needs for which it was initiated. Personnel Ensuring the effective use of people. Communication Ensuring that the project information is properly conveyed to management, staff, and the stakeholders. Risk Identifying and managing risk. Procurement Acquiring goods and services from external sources in support of the project. Figure 6 – Management Responsibilities Applied to a General Process
  15. 15. 12 Agile PM Methods The Agile Software Delivery Process Agile processes have entered the market as a remake of Lightweight Software Development processes. Agile processes emphasis both the rapid and flexible adaptation to changes in the process, the product, and the development environment [Aoyama 98], [Aoyama 98A]. This is a very general definition and therefore not very useful without some specific context — which will be developed below. Before establishing this context, Agile processes include three major attributes, they are: n Incremental and Evolutionary – allowing adaptation to both internal and external events. n Modular and Lean – allowing components of the process to come and go depending on specific needs if the participants and stakeholders. n Time Based – built on iterative and concurrent work cycles. Common Problems with All Software Projects The National Software Quality Experiment has been conducted each year since 1992 with the following observations that occur from session to session over the years: [6] Common Problem Consequences Software product source code components are not traced to requirements. Software product is not under the control and the verification procedures are imprecise. Changes cannot be managed in a controlled manner. 6 In 1992 the DOD Software Technology Strategy set the objective to reduce software problem rates by a factor of ten by the year 2000. The National Software Quality Experiment is being conducted to benchmark the state of software product quality and to measure progress towards the national objective. The National Software Quality Experiment is a mechanism for obtaining core samples of software product quality. A micro–level national database of product quality is being populated by a continuous stream of samples from industry, government, and military services. This national database provides the means to benchmark and measure progress towards the national software quality objective and contains data from 1992 through 1998. The centerpiece of the experiment is the Software Inspection Lab where data collection procedures, product checklists, and participant behaviors are packaged for operational project use. The uniform application of the experiment and the collection of consistent measurements are guaranteed through rigorous training of each participant. Thousands of participants from dozens of organizations are populating the experiment database with thousands of defects of all types along with pertinent information needed to pinpoint their root causes.
  16. 16. Lean PM Methods 13 Software engineering practices are not applied in a systematic manner. Defect rates are unacceptable Product designs and source are managed in an ad hoc manner The understandability, maintainability, and adaptability of the product is negatively impacted. The construction processes for the product are not clearly defined. Common patterns of the processes are not exploited. Rapidly changing code base has become the norm The code base services the only the short term benefits and mortgages the future where traceable baseline requirements, specifications, and design artifacts are the foundations of success. Figure 7 – National Software Quality Experiment Results The Problem of Change Change takes place throughout the business world, at all levels within an organization or market place. Change by itself is not a problem. The world is always changing. It always has been changing. It always will be changing. Businesses and the processes they use have always had to adapt to a changing world. Often the changes occurring in the past have been incremental. When a radical change took place in the past, the next change event was slow in coming. While there has always been uncertainty in business, it has usually not been significant or sustained for long periods of time. The real problem in today’s world is that change is no longer incremental or linear. Radical nonlinear changes are occurring more frequently. The pace of change is increasing. Major and sustained uncertainty is now commonplace. Ready For Agility? All organizations face the problems that an Agile method can address, but not all companies are ready for the radical ideas needed to become an agile organization. Agility is still an emerging topic and is at a stage where it is not possible to buy an off–the–shelf solution that has been show to behave in the same manner as heavier
  17. 17. 14 Agile PM Methods weight processes. [7] Elements of agility can certainly be found in many processes, but as the saying goes – one swallow does not a make summer. [8] The introduction of an Agile process should only be undertaken by organizations that are not risk adverse. Organizations who need answers and concepts that are fully developed out that result in a solution that can implemented with little risk should stay clear of the Agile Processes. The irony here is – there is no such process that can deliver a fully developed plan that results in a fully developed project or product. Let alone one that can be deployed without risk The Forces Driving Agility Software acquisition and deployment is generally driven by a need to solve a specific problem, to do things better, to modify or improve a business or technical process. The software development process community has two schools of thought regarding the outcome of these efforts: n Things are getting better n Things are getting worse This conflicting set of opinions adds more confusion to an already confusing question of — are we actually improving the outcome of the software development process? A few years ago, methodologies and processes were the domain of academics. The methodology zoo has grown and at the same time become focused on the commercial aspects of selling these methodologies to anxious managers, developers and customers. This selling of methods has overtaken the rational application of these methods of specific problem domains. Practical Agile Project Management The deployment of an Agile project management methodology into an existing organization faces several obstacles: n The legacy project management processes must be displaced in some way to make room for the new process. 7 This of course is not the contention of XP, SCRUM, ASD, and other lightweight, and now agile processes. But these processes have yet to enter the stage where analytical evidence has been gathered to support the contention they produce superior results when compared to their less–lightweight cousins. This is a continuing debate and will not be resolved here. 8 This English proverb can be traced to a Greek proverb. In the ancient world birds were associated with the household gods and their presence was looked upon as fortuitous. Any harm done to them would bode evil for the household.
  18. 18. Lean PM Methods 15 n The gaps in the legacy process must be filled with the new process while maintaining the integrity provided by the legacy process. Common Threads of These Methods In an attempt to simplify the many attributes of the methods a list of common threads could be built, using Figure 5 as a framework. Thread Compliance Requirements Gathering Some method of gathering requirements is needed. This ranges from User Stories, Use Cases, state diagrams, requirements languages and other formal methods Software Development or Procurement Software must be developed (or procured) that meets the requirements. These methods each have some technique to construct the code in a methodological manner. Testing Component and System testing are performed in some structured manner. Personnel Management The management of personnel is provided in some methods, but not all. Project Management No all methods have technique for managing the project in a traditional manner. The non–traditional approaches may be interesting but are of little comfort to management unfamiliar with the metrics of Agile processes. Figure 8 – Common Aspects Of All Methods Software development has been described as a series of discrete activities: (a) analyze the problem and write down the requirements; (b) design the code; (c) write the code; (d) debug the results. This view of software production is not only outdated, it was fraught with problems.
  19. 19. 16 Agile PM Methods Is Agile Yet Another Software Methodology Taxonomy? Before selecting a software development method, some understanding of what type of software is going to be developed may be appropriate [Jones 00]. Software Type Attributes Management Information Systems Software that enterprises use to support their own business and administrative operations. The traditional payroll, sales support, and financial systems are examples Outsourced systems Software projects that are built for a client organization. This could include contracted software development or commercial systems tailored to meet the needs of the organization. Systems software Software that controls a physical device such as a computer or a telephone switch. Embedded systems are part of this group, which includes nearly every modern device that is microprocessor controlled. Commercial software Software applications that are marketed to hundreds or even millions of clients. Word processors, spreadsheets, ERP applications, and Java applets are examples. Military software Software produced for the uniformed services. This includes commercial applications such as payroll and logistics as well as weapon system software. End User Software Small applications written for personal use. This could include spreadsheet programs, database programming, or even actual programming language applications. Web Application and e–Projects Small, medium, and large scale projects with legacy system integration, transaction processing, multimedia delivery, and web browser based user interfaces Figure 9 – Software Systems Taxonomy
  20. 20. Lean PM Methods 17 Today, software creation is viewed as a series of discrete steps, plus a continuous process that guides the software creation process and the relationships between the discrete and the continuous activities is the domain of a software development methodology. [9] Project Management Drivers The popular discussion of methodologies focuses on requirements, design, coding, and testing. The management of a development project is focused on controlling the scope, deliverables, and expectations of the various participants and stakeholders. There are primary business drivers for the stakeholders as well as the participants in the system development. The project manager for a software project or product is pulled in many directions by the participants and stakeholders. Figure 10, shows some of the tensions placed on the project manager. 9 This quote was abstracted from the web page introduction to “A Gentle Introduction to Software Engineering,” March 31, 1999, Software Technology Support Center, Hill Air Force Base, Ogden Utah. This site focuses on software development processes for government and military applications. It is far removed from the current Agile discussions that are being applied to e–commerce applications. However, many of the topics hosted at this site have direct bearing on the current subject, since software engineering is a profession, any analysis or research is the field is useful.
  21. 21. 18 Agile PM Methods Boss Ambitious Goals No Over Runs No Surprises Finance Low Budget Fast Schedule No Surprises Users Lots of functions User friendly Fast Robust No Surprises Subordinates Fast career path Preference for creative work Defer documentation No Surprises Maintainers / Support Staff No Bugs Well Documented No SurprisesProject Manager Figure 10 – Tensions On The Software Development Project Manager How these influences impact the process needs some more development. The point here is there are many attributes of an IT project that don’t involve the development of software. The success factors for the project must ALL be addressed. Framework for Agile PM Methods A framework for deploying agile project management processes provides a descriptive guideline rather than a proscriptive set of rules. This framework approach provides the user a broader set of recommendations than is found in any particular named methodology. This framework is based on two foundations: n The Software Program Managers Network Nine Best Practices – which provides guidelines for project managers using practical suggestions for daily application n Scott Ambler’s Agile Modeling framework – which provides a broad framework for creating agile processes applied to software projects. [Ambler 01]
  22. 22. Lean PM Methods 19 Nine Best Practices The Nine Best Practices constitute a management control system that provides a disciplined set of processes for containing and directing the complexity of a software development project. Figure 11 describes the relationship between these Nine Best Practices and their outcomes. The Best Practices can be classified into the following major categories: n Identify and correct defects and potential problems as early as possible n Plan and estimate all project activities and deliverables n Minimize rework caused by uncontrolled change n Make effective use of the resources The reader’s first reaction to these statements may be aren’t you restating the obvious?. The nine best practices are in fact obvious. The problem comes when it is time to deploy them into the project environment and attempt to reap the rewards. These principles are practiced by all good project managers, whether they are building complex software systems or pouring concrete for the foundation of a building. They are obvious, they are intuitive, and they are simple. So why is it so hard to put them into practice? The source of these best practices is the Software Program Managers Network, www.spmn.com. What is presented here is a restatement of the concepts, tailored for the InSiight project and the culture of Sii. The materials provided by the SPMN and other resources are available on the web. A brief overview of the best practices concept is provided in “Industrial–Strength Management Strategies,” Norm Brown, IEEE Software, July 1996, pp. 94–102.
  23. 23. 20 Agile PM Methods Agreement on Interfaces Risk Management Formal Inspections Metrics Based Schedule and Management Configuration Management Project-wide Visibility of Progress vs. Plan People-Aware Management Accountability Binary Quality Gates at the Inch Pebble Level Defect Tracking Against Quality Targets Identify and Correct Defects Planning and Tracking Minimize rework caused by uncontrolled changes Effective use of personnel resources Figure 11 – Nine Best Practice Principles Management Engagement In order for the Nine Best Practices to be effective management must be engaged in specific ways. This engagement involves: n Commitment – to the practices and the consequences of the practices. This commitment usually comes in the form of a formal endorsement of the process and the deliverables from the process. By officially sanctioning the Best Practices approach top management, the stakeholders, and all the participants agree in public that they are committed to make them work.
  24. 24. Lean PM Methods 21 n Action – to implement the best practices. Having a commitment is easy, making good on the commitment is the hard part. A call to action approach can be used to deploy the Best Practices. The action needed to deploy the Best Practices will be managed just like any other project, with a detailed project plan, well-defined outcomes, and measurable deliverables. n Funding – for the changes that will result from the practices. In order to accrue the benefits of the Best Practices, money must be spent. The actual funding details are not currently known. The total amount will be small compared to the total investment for the complex software project. The return on this investment will be very large – a major contribution to the successful completion of the product. n Follow-up – for the behaviors that result from the practices. Using the Best Practice of Project–Wide Visibility of Progress Versus Plan the deployment of the Best Practices will become a visible project. A project schedule will be posted, progress to plan meetings held, and progress reports published. n Measurement – of the outcomes of the practices. With measurement, management can not take place. This is a Best Practice item that will be used for deploying the Best Practices. Applying the Nine Best Practices The Nine Best Practices constitute a management control system that provides a disciplined set of processes for containing and directing the complexity of a software development project. The Best Practices can be classified into the following major categories: n Identify and correct defects and potential problems as early as possible. n Plan and estimate all project activities and deliverables. n Minimize rework caused by uncontrolled change. n Make effective use of the resources The reader’s first reaction to these statements may be “aren’t you restating the obvious?” The Nine Best Practices are in fact obvious. The problem comes when it is time to deploy them into the project environment and attempt to reap the rewards.
  25. 25. 22 Agile PM Methods These principles are practiced by all good project managers, whether they are building complex software systems or pouring concrete for the foundation of a building. They are obvious, they are intuitive, and they are simple. So why is it so hard to put them into practice? Best Practice Call to Action Formal Risk Management All software development has risk. It is an unavoidable consequence of the design process. The cost of resolving these risks is usually low if addressed early in the project lifecycle. As the project matures, the cost of mitigating the risk increases rapidly. Nearly every developer and project manager has some experience with this effect, but many pay lip service to. Recognizing and acknowledging that risks are present in the project is the first step. In the past, this was not part of the normal project management process. By publicizing the risks, along with the mitigation plan, everyone can participate in the solution process. Effectively managing project risks involves acceptance and decriminalization of the risks and the processes used to discover the risks. In order to address this issue management must make the commitment to address risk as part of the normal development process. Without this commitment, identifying and addressing risks will become a no win process to be avoided at all costs. By making risk management part of the everyday project process, the participants can grow to trust management and vice versa. Only by decriminalizing the discovery and reporting of risks can this trust be built. Agreement on Interfaces The system interfaces must be designed at some level before software analysis and coding. This assumes that the interfaces are identified and their basic functionality is stated. The user interfaces and the external system interfaces must be clearly defined before the system architecture can be partitioned. Without this definition process, the locality of the system' functions cannot be defined. The first approach to interface identification will use the UML notation for class collaboration. Starting at the highest level of the system, the meta–class (or macro–class) components will be defined and connected. It is through those connections that the interface components will be identified. Formal Inspections Use small teams of prepared reviewers with assigned roles. These teams will be responsible for delivery working software that meets the quality criteria. The primary issue here is to define the quality criteria for the deliverables.
  26. 26. Lean PM Methods 23 Best Practice Call to Action Metrics Based Scheduling and Management Plan short duration tasks with measurable outcomes. Review key milestones to determine that progress to plan is being made not only on the long level tasks, but also the high–level integration points. By planning at the inch pebble level, measurable deliverables can be used to build trends and replace the lack of empirical data from previous projects. There are additional benefits for the development team, since this lays the groundwork for the continuous build and smoke test processes that will be needed in the later stages of the project. Binary Quality Gates at the Inch–Pebble Level Ensure that development tracking is based on actual products. Define the deliverables for each task in terms of quality, non–functional requirements as well as the functional requirements. Project–wide Visibility of Progress to Plan Put the schedule, risk management, and all deliverables in a public location for access by all participants. This is more than using some source code control system. The paper schedules are currently on display. The electronic versions are being kept on a server, but this is not enough. A Project Web site will be created for all the materials related to the project. Defect Tracking Against Quality Targets Implement practices to find defects when they occur. Continuous smoke testing of the software will be instituted once the baseline components are stabilized. Configuration Management Use change tracking to formally track the status of shared products, problem reports, cost and schedule base line, test programs, internal and external interfaces, reports used by more than one organization, and all concurrently non–baselined information shared within the project or approved for internal release through the binary quality gates. Make complete use of a source code control system. If there are not sufficient capabilities to manage multiple version of each component, then some other application must be found. This will be a critical success factor for the project, since not only are multiple components being built, they are being built at different sites, by diverse groups.
  27. 27. 24 Agile PM Methods Best Practice Call to Action People–aware Management Accountability Minimize burnout. Help the staff maintain their personal technical competency. Manage the time allocated to each task so that the developer has a high probability of success without heroic efforts. The project must invest in timely training. The subcontracts should be selected that already have the necessary training. Figure 12 – Nine Best Practices of a Success Software Project Agile Project Management Summary Building on the Software Program Managers Nine Best Practices, the well established project management methods of the past, the fundamentals of any project management method, and finally common sense, a framework for Agile Project Management can be built. Values of Agile Project Management Before the principles of Agile Project Management can be defined, a set of underlying values must be stated. It is from these values that the principles are derived. n Communication – starts with the project manager and involves all the stakeholders. The communication of information is constant between a project manager, the contributors and the stakeholder. It is the responsibility of the project manager to ensure that the communication occurs effectively, clearly, and in a timely manner. Since change is a constant process in an Agile project management environment, communication is the means to address change. n Simplicity – defines the approach to discovering the critical success factors of the project. All activities must add measurable value to the project management process in some measurable way. Measuring the value of any activity or produced artifact is the role of the stakeholders and the project manager. By first asking the question “what is the value of this specific task?” is the starting point of simplifying the project management methodology. n Feedback – “optimism is an occupational hazard of software development, feedback is the cure” [Beck 99]. Continuous feedback is a powerful tool for maintaining agility.
  28. 28. Lean PM Methods 25 n Courage – important decisions and changes in direction need to be made with the courage and understanding that change in part of any modern IT project. Dealing with the consequences through further change or discarding the outcome when the decision is proven inadequate requires courage. n Humility – the best project managers acknowledge they don’t know everything. The stakeholders, fellow project participants, and customers all have their our areas of expertise to add value to the project. An effective approach is to assume that everyone involved with your project has equal value and therefore should be treated with respect. Applying Agile Principles in Practice Applying these principles in practice creates the foundation for managing IT projects in an Agile manner. n Assume Simplicity – as the project evolves it should be assumed that the simplest solution is the best solution. Overbuilding the system, or overbuilding any artifact of the project should be avoided. The project manager should have the courage to not perform any task or produce any artifact that is not clearly stated in the requirements as needed for the immediate benefit of the stakeholders. n Embrace Change – since requirements evolve over time. The stakeholder understanding of the requirements will change over time. Project stakeholders themselves may change as the project makes progress. Project stakeholders may change their point of view, which in turn will change the goals and success criteria of the project management effort. n Enabling The Next Effort Is A Secondary Goal – the project can still be considered a failure even when the team delivers a working system to the users. Part of fulfilling the needs of the project stakeholders is to ensure that the system is robust enough to be extended over time. Using Alistair Cockburn concept, “when you are playing the software development game your secondary goal is to setup to play the next game.” The next effort may be the development of a major release of your system or it may simply be the operation and support of the current version of the system. n Incremental Change – in an important concept. The pressure to get it right the first time, can overwhelm even the best project manager. Instead of futilely trying to develop an all encompassing project plan
  29. 29. 26 Agile PM Methods from the start, putting a stake in the ground by developing a small portion of the system, or perhaps a high–level model of a larger portion of the system, and then evolving it over time (or simply discard it when you no longer need it) in an incremental manner. n Maximize Stakeholder Value – the project stakeholders are investing resources — time, money, facilities, and etc. — to have a system deployed that meets their needs. Stakeholders expect that their investment will be applied in the best way manner. They also deserve to have the final say in how those resources are invested. n Manage With A Purpose – create artifacts of the project management process that have stakeholder value. If you cannot identify why and for whom you are creating an artifact then why bother doing the work? Identify a valid purpose for creating an artifact and the audience for that artifact. Based on that purpose and audience, develop it to the point where it is both sufficiently accurate and sufficiently detailed. This principle also applies to a change to an existing artifacts as well. An important consequence of this principle is the need to know the audience for the artifact. Go talk to them and find out what will meet their needs as well as the larger needs of the project. n Multiple Project Views – provide different views of the same process for different audiences. Considering the complexity of any modern software system construction or acquisition process, there is a need for a wide range of presentation formats in order to effectively communicate with the stakeholders, participants, and providers. n Rapid Feedback – the time between an action and the feedback on that action must be minimized. Working closely with the stakeholders, to understand the requirements, to analyze those requirements, and develop a actionable project plan, provides opportunities for rapid feedback. n Working Software Is The Primary Goal of the Project – the goal of any software project is to produce software that meets the needs of your project stakeholders in an effective manner. The primary goal is not to produce extraneous documentation, extraneous management artifacts, or even models of these artifacts. Any activity that does not directly contribute to the goal of producing a working system should be examined. n Travel Light – since every artifact that is created, and then kept, will need to be maintained over it’s life cycle. The effort needed for this
  30. 30. Lean PM Methods 27 maintenance must be balanced with the value of the artifact. Not only must the effort be considered, but the risk that the artifact will create confusion over time if it is not properly maintained must be considered.
  31. 31. 28 Agile PM Methods Bibliography [Agresti 86] “New Paradigms for Software Development,” IEEE CS Press, 1986. [Alleman 01] “Anti Patterns in Project Management: A Book Review,” Glen B. Alleman, http://www.pmforum.org/library/books/antipatters.PDF. [Ambler 01] “Agile Modeling,” Scott Ambler, www.agilemodeling.com. [Aoyama 98] “New Age of Software Development: How Component Based Software Engineering Changes the Way of Software Development,” Mikio Aoyama, 1998 International Workshop on Competent–Based Software Engineering, 1998. [Aoyama 8A] “Agile Software Process and Its Experience,” Mikio Aoyama, International Conference on Software Engineering, 1998. [Basili 75] “Iterative Enhancement: A Practical Technique for Software Improvement,” Victor Basili, IEEE Transactions on Software Engineering, 1(4), December, 1975. [Beck 99] Extreme Programming Explained, Kent Beck, Addison Wesley, 1999. [Bennington 56] “Production of Large Computer Programs,” Bennington, Symposium on Advanced Computer Programs for Digital Computers, sponsored by Office of Naval Research, June 1956. Reprinted in Annals of the History of Computing, October 1983, pp. 350–361. Reprinted at ICSE ’87, Monterey, California, March 30 – April 7, 1987. [Blackbook 97] “A Condensed Guide to Software Acquisition Best Practices,” Software Program Managers Network, 1997. Can be found in HTML format at http://www_ied.belvoir.army.mil/odisc4/docs/blackbook/black book.htm. [Blum 94] “A Taxonomy of Software Development Methods,” Bruce I. Blum, Communications of the ACM, 37(11), November 1994, pp. 82–86.
  32. 32. Lean PM Methods 29 [Bowen 99] “Formal Methods,” Jonathan Bowen, FM’99: World Congress on Formal Methods, http://archive.comlab.ox.ac.uk/formal– methods.html. [Boehm 85] "A Spiral Model of Software Development and Enhancement," B. W. Boehm, from Proceedings of an International Workshop on Software Process and Software Environments, Coto de Caza, Trabuco Canyon, California, March 27–29, 1985. [Brooks 87] “No Silver Bullet: Essence and Accidents of Software Engineering,” Fred Brooks, IEEE Software, 20(4) April 1987, pp. 10–19. [Brooks 95] The Mythical Man–Month, Fred Brooks, Addison Wesley, 1995. [Ciapessoni 99] “From Formal Models To Formally Based Methods: An Industrial Experience,” Emanuele Ciapessoni, Piergiorgio Mirandola, Alberto Coen–Porisini, Dino Mandrioli and Angelo Morzenti, ACM Transactions on Software Engineering and Methodology, 8(1), January 1999, pp. 79–113. [Cockburn 99] “A Methodology per Project,” Alistair Cockburn, Humans and Technology Technical Report, TR 99.04, October 1999. http://www.crystalmethodologies.org/articles/mpp/methodolog yperproject.html [Cockburn 00] “Selecting a Project’s Methodology,” Alistair Cockburn, IEEE Software, July/August 2000, pp. 64–71. [Connolly 96] “The Effects of Extended CASE technology on Group Process and the Management of Cognitive Breakdowns in Systems Analysis Teams,” James R. Connolly, PhD Dissertation, University of Colorado, College of Business and Administartion, 1996. [Coplien 01] “Project Management Pattern Language,” James Coplien, http://i44pc48.info.uni-karlsruhe.de/cgi- bin/OrgPatterns?FrontPage. [Coplien 95] “A Generative Development–Process Pattern,” James Coplien, Pattern Languages of Program Design, Addison Wesley, 1995.
  33. 33. 30 Agile PM Methods [Coplien 95a] Patterns Languages of Program Design, edited by James Coplien and Douglas Schmidt, Addison Wesley, 1995. [Corry 96] “A Taxonomy of Software Design Methodologies,” Michael Corry, http://gwis2.circ.gwu.edu/~mcorry/597final.htm. [Defense 94] Report of the Defense Science Board Task Force on Acquiring Defense Software Commercially, www.stsc.hill.af.mil/crosstalk/1994/dec/defense.asp. [Flower 99] “The New Methodology,” Martin Fowler, www.martinfowler.com/articles/newMethodology.html [Goldman 95] Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer, S. L. Goldman. [Humphrey 99] “Pathways to Process Maturity: The Personal Software Process and Team Software Process,” Watts Humphrey, SEInteractive, 2(2), June 1999, http://interactive.sei.cmu.edu/Features/1999/June/Background /Background.jun99.htm. [Jones 00] Software Assessments, Benchmarks, and Best Practices, Capers Jones, Addison Wesley, 2000. [Martin 97] Patterns Languages of Program Design 3, edited by Robert Martin, Dirk Riehle and Frank Buschmann, Addison Wesley, 1995. [Osterweil 87] “Software Processes are Software Too,” Leon J. Osterweil, Proceedings of the 9th International Conference on Software Engineering (ICSE 1987), pp. 2–13, March 1987, Monterey, CA. [Osterweil 97] “Software Processes Are Software Too, Revisited,” Leon J. Osterweil, Proceedings of the 19th International Conference on Software Engineering (ICSE 1997), pp. 540–548, May 1997, Boston, MA. [Porter 98] “Understanding the Sources of Variation in Software Inspections,” Adam Porter, Harvey Siy, Audris Mockus, and Lawrence Votta, ACM Transactions of Software Engineering and Methodology, 7(1), January 1998, pp. 41–79. [Ramo 80] The Management of Innovative Technological Organizations, Simon Ramo, John Wiley & Sons, 1980.
  34. 34. Lean PM Methods 31 [Royce 70] “Managing the Development of Large Software Systems,” Walker Royce, Proceedings of IEEE WESCON, August 1970. [Royce 98] Software Project Management: A Unified Framework, Walker Royce, Addison Wesley, 1998. [SEI 96] “Software Development Taxonomy,” www.sei.cmu.edu/legacy/kit/taxonomy.html. [Sutherland 00] “SCRUM Hyperactive Software Development Method,” Jeff Sutherland, http://jeffsutherland.com/scrum. [Standish 95] “Chaos,” http://www.standishgroup.com/visitor/chaos.htm. [Tausworthe 79] Standard Development of Computer Software, Robert C. Tausworthe, Prentice Hall, 1977. [Vlissides 95] Patterns Languages of Program Design 2, edited by John Vlissides, James Coplien and Norman Kerth, Addison Wesley, 1995. [WIKI 00] http://www.c2.com/cgi/wiki?CategoryMethodology

×