Swimming up the waterfall

As institutions of higher education seek to decrease operational expenditures and reallocate resources to academic programming, information technology projects come under increased scrutiny; although cliché, doing more with less is a reality. At The George Washington University (GW), the Division of IT (DIT) is leveraging agile project management to increase their delivered value to the entire university. Building from their software development life cycle management base, DIT is adding a focus on agile project management to deliver business value to customers faster. In this paper, GW will demonstrate how they tailored their waterfall methodology into a more agile approach, show a comparison between their uses of the waterfall and agile methodologies, and share their challenges and lessons learned.

Traditionally, projects at GW have been managed utilizing a waterfall approach; however, for many years, projects were plagued with issues, including a lack of a common methodology among divisions, the absence of cohesive leadership oversight, a misunderstanding of project roles and responsibilities, finger-pointing on failed projects, and the lack of a universal project management language. In 2009, to help bring unity among university divisions in their project management approach, the Divisions of IT and Finance partnered together to document their waterfall software development methodology, resulting in the Project Management Lifecycle (PMLC). The purpose of GW’s PMLC is to enable standardization of methodology, documentation, terminology, and approval across organizations, while enabling clear ownership and empowerment of project leadership. Key factors of the methodology include a standard set of templates, a common language used among all project team members, and a set of phase gate reviews that serve as a point to monitor the health of projects and make major decisions about the direction for upcoming phases.

A high level example of GW’s PMLC can be found in Exhibit 1 :

Exhibit 1 – An example of GW’s PMLC

In the years since the PMLC has been implemented, it has led to better project planning and implementation across the university. There is standardization in documentation, increased executive approval, and buy-in throughout the process, and opportunities to correct potential misconceptions early in the process. However, while GW has reaped the benefits of the PMLC, there is an increased need for faster delivery, flexibility, and transparency within the methodology. Building on the traditional waterfall PMLC process, DIT recently added a focus on agile project management.

Piloting PMLC-Agile

GW’s Project Management Office (PMO) partnered with the Business Intelligence Services (BIS) team within DIT to pilot an agile development framework, called PMLC-Agile, on their work with the Office of Research Services. In this project, BIS is responsible for extracting data from GW’s financial ERP system, loading it into the university data warehouse, and building a series of dashboards and reports that will aid principal investigators in managing their research grants.

Agile (specifically, Scrum) was chosen for the following reasons:

• There was a perception within the university community that BIS took too long to deliver the dashboards and reports needed to make more informed decisions. The lengthy process of bringing in content into the data warehouse for reporting use was often lost on the customer. By using Scrum, the customer is made aware of the process and kept engaged during the development. They see the team's progress, review the team's work, and provide feedback at the end of every two-week sprint.
• In past projects, scope creep happened often because of the customer's changing requirements. With Scrum, requirements are collected, reviewed, and re-prioritized every two weeks. The team works on the most important features for the customer, delivering business value sooner.
• Risks – such as the complexity of tasks, limited access to source data, lack of resources – are identified and addressed early on. Team retrospectives at the end of every sprint help the team assess how it can improve and adjust appropriately.

Not all BIS projects, however, will use PMLC-Agile. At the beginning of a project, an assessment is made on whether waterfall or Scrum will be used. Examples of their uses are shown in Exhibit 2.

Exhibit 2 – Examples of waterfall and agile (Scrum) uses.

PMLC-Agile follows the Scrum framework illustrated in Exhibit 3. The BIS Scrum team is comprised of a Product Owner, a ScrumMaster, analysts, and developers. While not ideal, the entire BIS team adjusted workloads so that some can participate part-time, while others can perform dual roles. Every Sprint is 10 days long. The team performs all the Scrum rituals: a 5 to 10-minute daily stand up, sprint planning, product backlog grooming, and Retrospective. User acceptance testing is conducted on the ninth day, and a product review is held on the last day of every sprint with the customer.

Exhibit 3 – Example of a Scrum framework (taken from www.scrumalliance.org).

Swimming up the Waterfall

Adding PMLC-Agile as a methodology is important for the PMO. To do this, the PMLC-Agile approach needed to be overlaid within GW’s overall PMLC methodology to ensure that artifacts, tools, and processes that were already in place could be utilized. A high level illustration of how the PMLC-Agile was tailored within the overall PMLC process is shown in Exhibit 4:

Exhibit 4 – PMLC-Agile tailored to the PMLC process.

It is important to note that PMLC-Agile continues to follow the same overall phases of PMLC — Idea, Proposal, Planning/Analysis, Design, Development, Testing, Deployment, and Closing. The main difference, however, is that PMLC-Agile is iterative and incremental. Every two weeks, the team goes through Planning/Analysis, Design, Development, Testing, Deployment activities, but using Scrum artifacts.

Following is a side-by-side comparison of the artifacts used by PMLC and PMLC-Agile:

Lessons Learned

As the PMO and BIS teams began to use PMLC-Agile, a number of lessons learned were noted.

• Customer feedback is consistently received throughout the length of product development, helping to ensure expectations are being met.
• Scrum is a great tool for managing different work styles. It facilitates conversations to readily address issues that prevent the team from achieving their goals. It also leads to impediments being uncovered earlier and addressed quickly rather than allowing them to affect the project.
• PMLC-Agile is not a one-size-fits-all. It was important to take best practices from Scrum and the PMLC and form a tailored, PMLC-Agile methodology.
• While critical to the agile framework, users may not participate readily at first. By showing them value through product increments, users began to participate more frequently and provide feedback that allowed the team to fine-tune the product to their needs.
• In the earlier Sprints, the team would over-commit themselves on work pulled from the Product Backlog. This resulted in stressed team members or missed user story points. However, once the team gained experience and a better understanding of their velocity, more effective estimation was able to take place.
• Constant education and transparency are important. By allowing others to participate as “silent listeners” in daily standups and review the board, other teams in the organization gained a more thorough understanding of Scrum.
• The first use of PMLC-Agile worked well because BIS is a self-contained team. While BIS could not have provided users what they needed without the help of subject matter experts and other DIT teams, a huge part of the work was done using BIS resources.

Challenges in implementing PMLC-Agile throughout the university

There are a number of challenges that the university will face if PMLC-Agile is to be used and adopted as an alternative to PMLC.

• PMLC-Agile represents a significant cultural shift for the university. Typically, DIT teams do not have the luxury of focusing on one project at a time. DIT staff members usually work on several projects simultaneously, while managing day-to-day operational tasks. In the case of BIS team members, operational work has higher priority over the work being done in PMLC-Agile. This presents a risk when technical glitches occur within the data warehouse environment, creating an impediment and a possibility that the team cannot complete the features that the team agreed to work on within the Sprint.
• There is a need for increased awareness, education, and executive support for PMLC-Agile to succeed. Because projects involve staff from different siloed divisions, it becomes critical that senior management throughout the university provides support so that staff can participate on Scrum teams.
• The PMO is often provided dates by senior executives as to when they expect to see a product, leading the PMO to manage expectations as to what can be delivered by this date. An understanding of the iterative and incremental nature of PMLC-Agile is required because with Agile, the highest priority features are delivered first. Dates can serve as mileposts, but what is delivered by a certain date is dictated by how the product owner prioritizes features in the backlog.
• Customers will need to participate more fully in PMLC-Agile. Providing feedback as the product is being developed is necessary to ensure that the Scrum team is delivering what was prioritized and requested.
• Processes throughout DIT will need to be tailored to fit PMLC-Agile. For example, one of the most significant processes that needed to be adjusted was the security impact and assessment process. Because every Sprint runs for only two weeks, the process needed to be broken up into smaller chunks to avoid affecting the overall timeline.
• The physical location of staff is a challenge to contend with. Being a multi-campus university, meetings such as the daily stand-up and Sprint Planning will have to be done virtually.

Despite these challenges, the PMO continues to make the utilization of PMLC-Agile a priority. They are working on tailoring their templates to fit agile approaches and training key staff members to become Certified Scrum Masters (CSMs) and Certified Product Owners (CPOs). They are also developing a community of practice around agile within DIT and the university through brown bag sessions and presentations to key office areas. The teams look to evolve and watch for coordination points among Scrum teams, leverage dedicated project teams, and identify future projects that can utilize PMLC-Agile.

In conclusion, although new to DIT, the PMLC-Agile approach will be utilized in more projects in different customer areas when it is appropriate and needed. Although higher education environments are traditionally slow to change, GW has been able to make progress in getting the university to adopt this new approach. It will become critical to build upon this momentum and leverage the work that has been done, which will lead to additional project success stories.