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 client‐contractor 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 fast‐changing projects, agile and Scrum methodologies often are considered to have built‐in 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 public‐sector government agencies. Public‐sector 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 well‐defined 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 time‐consuming 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 self‐governed 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 catch‐up 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 full‐time people is an over management 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 full‐time 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 self‐directed, 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 know 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
Given the issues in the case that Remco is facing, where should Remco begin?
What should Remco do if the customers will not commit resources to Agile or Scrum projects?
How should Remco handle employee career development when employees realize that there are no formal positions on agile/Scrum projects and titles may be meaningless? What if employees feel that being assigned to an agile/Scrum team is not a career advancement opportunity?
How harmful might it be to an agile team if workers with critical skills are either reassigned to higher‐priority projects or are asked to work on more than one project at a time?
How should you handle a situation where one employee will not follow the agile approach?
In meetings when there is no leader, how do you resolve personality issues that result in constant conflicts?
Can an agile methodology adapt to change faster than a waterfall methodology?
Will the concept of self‐organized teams require Remco to treat conversion as a cultural challenge?
Can part of the company use agile and another part of the company use waterfall?