Review the below case study and answer the question:

Agile (A): Understanding Implementation Risks In the past decade, many information technology (IT) companies have changed their systems development lifecycle methodology to a more flexible framework approach, such as agile and Scrum. The basis for these flexible frameworks was the Agile Manifesto, introduced in February 2001, which had four values:

Individuals and actions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan The primary players in the framework included a Scrum Mastera product owner who represented the customer and the development team. The framework allowed for evolving scope and changes to be made while keeping the customer involved during the entire project. Work was broken down into sprints of two to four weeks, in which the team performed the tasks needed to be completed.

Without the formality of a rigid methodology, the need for very detailed upfront planning and expensive and often unnecessary documentation, projects could be aligned quickly to the customer's business model rather than the contractor's business model. Alignment of the framework to the way that the customer does business, combined with continuous and open communication with the customer, often was seen as the primary driver of project success, an increase in customer satisfaction, the creation of the desired business value the customer wanted, and repeat business.

The increase in the success rate of IT projects did not go unnoticed in other industries. But several questions needed to be addressed before these flexible methodologies could be applied to other types of projects and adopted in other industries.

Will flexible methodologies work on large, complex projects? What if the work cannot be broken down into small sprints? What if the customer or business owner will not commit resources to the project? What if the customer does not want continuous communication over the life cycle of the project? What if the customer wants detailed upfront planning? What if the customer says that no scope changes will be authorized after project goahead? What if the customer will not allow for tradeoffs on time, cost, and scope? What if the customer uses a rigid methodology that may be inflexible? What if your methodology cannot be aligned to the customer's methodology? What if during competitive bidding, the customer either does not recognize or understand the agile/Scrum approach or does not want it used on the project? What if the customer wants you to use its methodology on the project? What if you are one of several contractors on a project and you all must work together but each contractor has a different methodology? Can the use of a flexible methodology or framework prevent you from bidding on some contracts? Can your company maintain more than one methodology throughout the company based on the type of project being undertaken? REMCO'S CHALLENGE The executive staff at Remco Corporation was quite pleased with the oneday training program they attended on the benefits of using agile and Scrum on some of their projects. Remco provided products and services to both public and private sector clients, almost all of it through competitive bidding. IT was not required for any of the products and services Remco provided. Agile and Scrum had proven to be successful on internal IT projects, but there were some concerns as to whether the same approach could be used on nonITrelated projects for clients. There was also some concern as to whether clients would buy into the agile and Scrum approach.

Remco recognized the growth and acceptance of agile and Scrum as well as the fact that it might eventually impact its core business rather than just internal IT. At the request of Remco's IT organization, a oneday training program was conducted just for the senior levels of management to introduce them to the benefits of using agile and Scrum and how their techniques could be applied elsewhere in the organization. The executives left the seminar feeling good about what they heard, but there was still some concern as to how this would be implemented across possibly the entire organization and what the risks were. There was also some concern as to how their clients might react and the impact this could have on how Remco does business.

THE NEED FOR FLEXIBILITY Remco was like most other companies when it first recognized the need for project management for its products and services. Because executives were afraid that project managers would begin making decisions that were reserved for the executive levels of management, a rigid project management methodology was developed based on eight lifecycle phases:

Preliminary planning Detail planning Prototype development Prototype testing Production Final testing and validation Installation Contractual closure The methodology provided executives with standardization and control over how work would take place. It also created an abundance of paperwork.

As project management matured, executives gained more trust in project managers. Project managers were given the freedom to use only those parts of the standard methodology that were necessary. As an example, if the methodology required that a risk management plan be developed, the project manager could decide that the plan was unnecessary since this project was a very low risk. Project managers now had some degree of freedom, and the rigid methodology was slowly becoming a flexible methodology that could be easily adapted to a customer's business model.

Even with this added flexibility, there were still limits as to how much freedom would be placed in the hands of the project team. As shown in Figure I, the amount of overlap between Remco's methodology, the typical client's methodology, and the agile methodology was small. Remco realized that, if it used an agile project management approach, the overlap could increase significantly and lead to more business. But again, there are risks, and more trust would need to be given to the project teams.

FIGURE I Overlapping of methodologies

THE IMPORTANCE OF VALUE Remco's project management community had spent quite a bit of time trying to convince senior management that the success of a project cannot be measured solely by meeting the triple constraint of time, cost, and scope. Rather, they argued that the true definition of success is when business value is created for the client, hopefully within the imposed constraints, and the client recognizes the value. Effective clientcontractor communication, as identified in the Agile Manifesto, could make this happen.

The course reinforced the project managers' belief that measuring and understanding project value was important. Agile and Scrum was shown to be some of the best techniques to use when the value of the project's deliverables was of critical importance to the customers, whether they are internal or external customers.

Remco's project management experience was heavily based on the traditional waterfall approach where each phase of a project must be completed before the next phase begins. This creates a problem with measuring value as shown in Figure II. With the traditional waterfall approach, value is measured primarily at the end of the project. From a risk perspective, there exists a great deal of risk with this approach because there is no guarantee that the desired value will be there at the end of the project when value is measured, and there may have been no early warning indicators as to whether the desired value would be achieved.

With an agile approach, value is created in small increments as the project progresses, and the risk of not meeting the final business value desired is greatly reduced. This incremental approach also reduces the amount of time needed at the end of the project for testing and validation. When used on fastchanging projects, agile and Scrum methodologies often are considered to have builtin risk management functions. Though other methods of risk mitigation are still necessary, this additional benefit of risk mitigation was one of the driving forces for convincing executives to consider changing to an agile approach for managing projects. Agile and Scrum were seen as excellent ways to overcome the traditional risks of schedule slippages, cost overruns, and scope creep.

FIGURE II Creation of business value

CUSTOMER INVOLVEMENT For decades, project management training programs for public and private sectors recommended that customers should be kept as far away from the project as possible to avoid customer meddling. For this reason, most customers took a somewhat passive role because active involvement in the project could limit career advancement opportunities if the project were to fail.

Remco has some client involvement in projects for the private sector but virtually no involvement from publicsector government agencies. Publicsector organizations wanted to see extensive planning documentation as part of the competitive bidding process, an occasional status report during the life cycle of the project, and then the final deliverables. Any and all problems during the execution of the project were the responsibility of Remco for resolution with little or no client input.

Remco understood that one size does not fit all and that agile and Scrum might not be applicable to larger projects, where the traditional approach to project management using the waterfall methodology may be better. There would need to be an understanding as to when the waterfall approach was better than agile.

For agile and Scrum to work on some smaller projects, there would have to be total commitment from the customer and their management team throughout the life of the project. This would be difficult for organizations unfamiliar with agile and Scrum because it requires the customer to commit a dedicated resource for the life of the project. If the customer does not recognize the benefits of this, then it may be perceived as an additional expense incurred by awarding Remco the contract. This could have a serious impact on competitive bidding and procurement activities and make it difficult or impossible for Remco to win government contracts.

SCOPE CHANGES With traditional project management, accompanied by welldefined requirements and a detailed project plan, scope changes were handled through the use of a change control board (CCB). It was anticipated that, with the amount of time and money spent initiating and planning the project, scope changes would be at a minimum. Unfortunately, this was not the case with most projects, especially large and complex ones. When scope change requests were initiated, it became a costly and timeconsuming endeavor for the CCB to meet and write reports for each change request, even if the change request was not approved.

With agile and Scrum, accompanied by active customer involvement, frequent and cheap scope changes could be made, especially for projects with evolving requirements. The changes could be made in a timely manner without a serious impact on downstream work and with the ability to still provide the client with the desired business value.

STATUS REPORTING All projects, whether agile or waterfall, go through the Project Management Institute's domain areas of initiation, planning, execution, monitoring and control, and closure. But the amount of time and effort expended in each domain area, and how frequently some parts can be repeated, can change. To make matters worse, government agencies often mandate standardized reporting documents that must be completed. Many of these are similar to Gantt charts and other scheduling techniques that take time to complete. Customers may not be pleased if they are told that the status now appears on a Scrum board along with stories.

Government agencies tend to use standardized contracting models; and stating in a proposal that the contractor will be using an agile or Scrum approach may violate their procurement policies and make Remco nonresponsive to the proposal statement of work.

MEETINGS One of the concerns that Remco's executives had was the number of meetings needed for agile and Scrum and the number of participants in attendance. The time spent in meetings by the product owner and the Scrum Master, and in many cases the team itself, was seen as potentially unproductive hours that were increasing the overhead to the project. With the waterfall approach, meetings almost always resulted in numerous action items that often required months and additional meetings to resolve. In agile and Scrum, action items were kept to a minimum and were resolved quickly because the people on the team had the authority to make decisions and implement change. This also made it easier to create business value deliverables in a timely manner. There are also techniques available to minimize the time spent in meetings, such as creating an agenda and providing guidelines for how the meetings will be run.

Agile and Scrum work with selfgoverned teams made up of people with different backgrounds, beliefs, and work habits. Without a definitive leader in these meetings, there exists the opportunity for conflicts and poor decision-making. Without effective training whereby each team understands that they are working together toward a common goal, chaos can reign. People must believe that group decisions made by the team are better than the individual decisions typical of the waterfall approach. Decision-making becomes easier when people have not only technical competence but also an understanding of the entire project. Effective meetings inform team members early on that certain constraints may not be met, thus allowing them sufficient time to react. This requirement for more information may require significantly more metrics than are used in waterfall approaches. Sometimes executives may be invited to attend these meetings, especially if they have information surrounding enterprise environmental factors that may have an impact on the project.

PROJECT HEADCOUNT In the waterfall approach, an exorbitant amount of time is spent in planning with the belief that a fully detailed plan must be prepared at project initiation and will be followed exactly and that a minimum number of resources will be required during project execution. Risk and unpredictability are then handled by continuous and costly detailed replanning and numerous meetings involving people who may understand very little about the project, thus requiring a catchup time.

In the waterfall approach, especially during competitive bidding, the client may ask for backup or supporting data as to why project personnel are needed full time rather than part time. Some government agencies argue that too many fulltime people is an overmanagement cost on the project.

With agile and Scrum teams, the scope of the project evolves as the project progresses, and planning is done continuously in small intervals. The success of this approach is based on the use of fulltime people who are under no pressure from other projects competing for their services. The people on the project are often rotated through various project assignments; therefore, project knowledge is not in the hands of just a few. The team therefore can be selfdirected, with the knowledge and authority to make most decisions with little input from external resources (unless, of course, critical issues arise). The result is rapid feedback of information, a capturing of best practices and lessons learned, and rapid decision making. Collaborative decision-making involving stakeholders with diverse backgrounds is a strength of the agile approach. Once again, such an approach could be a procurement detriment if the client does not have a knowledge of agile and/or Scrum during competitive bidding activities.

Remco now seemed aware of many of the critical issues and had to decide about converting over to an agile approach. It would not be easy.

Questions:

1. Given the issues that Remco is facing, where should they begin?

2. What should Remco do if the customers will not commit resources to agile or scrum projects?

3. How should you handle the process where one employee will not follow the agile process?

4. Why do companies feel a hybrid process is needed?

5. Compare and Contract the process difference between decomposing requirements in Agile processes and Waterfall