How Scrum Adoption Can Curb Government IT Waste

First let’s qualify… the government IT waste I am referring to is the waste which occurs in the waterfall development methodologies used by so many government application development shops. Government applications teams don’t always purposefully choose a waterfall model, sometimes it is all they know and other times it is prescribed in various organizational procedures and policies. In Florida the state has inadvertently prescribed a waterfall methodology under Florida Administrative Code 60DD-7. Thankfully, it appears this issue may be addressed in the coming year by our new State CIO.

The PMP Effect

Another common driver behind execution of a waterfall software development processes is dogmatic execution of the PMBOK by a project manager. The Project Management Body of Knowledge (PMBOK) is the recognized standard of project execution by those project managers certified under PMI as Project Management Professionals (PMP’s). The PMBOK itself does not prescribe a waterfall methodology (or any other development methodology) for systems development; instead the PMBOK prescribes common processes and behaviors for the project manager to follow during the life cycle of the project. The project could be anything from a barn raising to a mission to Mars.

The problem arises when a PMP with limited software development experience takes the reigns of a software development project. Without a keen understanding of the development process, the project manager may fall back on the organizational structure offered by the PMBOK. Since the five process groups in the PMBOK (Initiating, Planning, Executing, Controlling and Monitoring, and Closing) lend themselves to “hand-off” from one process to the next, the project manager’s behavior takes on the qualities of a waterfall and as a result the team’s development processes begins to act as a waterfall.

Basics of a Scrum project

Scrum is a project management and development methodology structured to enable the most efficient and effective software (or other product) development process. The best description of Scrum is the description below from the Scrum Alliance website (http://www.scrumalliance.org/pages/what_is_scrum).

“Scrum is made up of three roles, three ceremonies, and three artifacts.

Three roles: the Product Owner, who is responsible for the business value of the project; the Scrum Master, who ensures that the team is functional and productive; and the self-organized team. Read more about Scrum roles.

Three ceremonies: the sprint planning meeting, daily scrum meetings, and sprint review meetings. Read more about Scrum ceremonies.

Three artifacts for prioritizing and tracking tasks: the product backlog, the sprint backlog, and a burn down chart. Read more about Scrum artifacts.“

Scrum is an Agile development methodology and therefore takes great pains to clear out unnecessary team processes which do not contribute directly to the development of the end product or diminish the ability of the team to accomodate change.

Scrum and PMBOK Comparisons

Product Owner (Scrum) vs. Project Sponsor (PMBOK)

The Product Owner in Scrum differs from the PMBOK Project Sponsor in that the Product Owner represents all facets of the business (funding, requirements/defining functionality,  and priorities) where the Project Sponsor may only provide funding and delegate one or more Subject Matter Experts to define the system functions and priorities. This separation of the sponsor from acting as the key subject matter expert is usually where “scope creep” occurs; in these team structures the subject matter experts are too distant from the cost/value proposition. In Scrum, the Product Owner knows how much can be spent and then decides what functions and requirements will give him or her the most bang for the buck.

Scrum Master (Scrum) vs. Project Manager (PMBOK)

The Scrum Master is to all intents and purposes the project manager; however the Scrum Master does NOT set the work breakdown structure (WBS) or assign resources to tasks as might be common for a PMBOK project manger. The Scrum Master tracks start up and completion of tasks; but the order of tasks and who will complete them is determined by the team doing the work.

Commitment to a Sprint (Scrum) vs. Commitment to a full specification

In PMBOK projects (and waterfalls) the team is asked to commit to the full specification up front (prior to execution) in the form of a project scope and one or more requirements specifications developed during the project planning processes. In Scrum a high-level specification (or ”wish list”) is held in the Product Backlog and this document or list describes all of the desired functionality of the system in order of importance.

In contrast to the PMBOK and waterfall, the Scrum team never commits to delivery of the full Product Backlog but instead commits to deliver an agreed upon number of functions from the top of the priority list within the next 30 days. This 30-day “mini-project” is called a Sprint and ends with the delivery of a fully operable system containing only those functions and requirements committed to at the beginning of the 30-day Sprint.

If after reviewing the system the Product Owner wishes to continue and do another 30-days of development he/she can start another Sprint or can decide to keep what was produced so far and end the project. This approach is made effective in Scrum as the agreed upon goal of a Sprint is to deliver working software at the end of a 30-day period. Through the full life cycle of developing the system, the team works through multiple Sprints until the product is either good enough for the Product Owner or the Product Owner is out of funding.

PMBOK Scope Management (“Scope Creep Defense”) vs. The Entire Scrum Process

In the PMBOK, scope creep is managed using a series of agreements between the project manager, project sponsor, and other project stakeholders. These agreements take the form of various plans (Scope Management Plan, Change Management Plan, etc.). The goal of Scope Management is for the project manager to ensure the list of tasks to be completed (scope) does not out grow the alloted time and budget available for the project. If the project sponsor wishes to add tasks then it becomes necessary to re-negotiate the alloted time and budget or remove other tasks from the scope to make room for the new tasks.

In Scrum the development team has never committed to delivering the full Product Backlog in a specific time frame or at a specific cost; therefore the Product Owner is free to re-prioritize, add, or remove items in the backlog at any time – with the exception of those items already committed to by the team for the current 30-day Sprint. By allowing the customer to re-evaluate the scope every 30 days (after each Sprint) and make changes, the Scrum process accounts for Scope and Change Management throughout the process. Any team who has developed software accepts the reality that changes to the scope are inevitable and the Scrum process operates accordingly, while the PMBOK seems to treat change as a process exception which will addressed only if a change occurs and then only if it is allowed.

So PMBOK is Bad and Scrum is Good?

No, the PMBOK is not bad at all Scrum is certainly not a silver bullet to replace the PMBOK. Both project methodologies are equally effective tools. As a project manager you could get most anything done using just the PMBOK, but as a software project manager you need both a formal tool (PMBOK) as well as an Agile tool (Scrum). If you only have one approach to managing projects you will inevitable get stuck at some point and fail to deliver “on time and on budget” - it is simply a matter of time.

As a government software project manager you will one day come across a project where time and value are of the essence. Maybe it will be a race to implement Legislative mandated changes by a specific date or possible a proof of concept needed ASAP to secure grant funding. In this case the process of executing the project will be greatly overshadowed by the need for a quality deliverable (the software) in record time. The initial inclination will be to ditch the PMBOK and go “wild west” but that could be a deadly move if the wrong cowboy is chosen.

In contrast, there are those projects where Scrum just doesn’t provide the level of formal control needed for the job; particularly projects where multiple organizations have an investment in the project – even if they do not have a direct stake in the product being delivered. An example in government could be a grant funded project or any of the many projects funded by a legislative budget request. In these instances, a requirement from the project investors that a PMI certified project manager will follow the PMBOK when executing the project can have a similar effect as requiring the officers of a public institution to certify their internal controls under Sarbanes-Oxley; albeit without the related criminal implications. The reality being that when multiple investors have money invested into a project those investors want some level of oversight applied to the project process. These investors want to see that their money is being managed correctly and that risks to losing their investment are being adequately monitored. In some government projects, all project related meetings may be opened to the public and must be coordinated with advanced notice to the public. The formalized structure of the PMBOK is uniquely suited to these types of projects needs.

Hey, You Said We Would Curb Government Waste! (was this a bait and switch?)

Fair enough. If you run a government IT shop or government PMO – or have any impact on the operations of said shop – here’s where you start:

1. Send one or more of your development team leaders or project managers to Scrum Master Certification training. This is the fastest way to get them up to speed on an Agile methodology with the least amount of trial and error. Scrum is a natural behavior for software development teams so most people who have participated on a software development team will immediately see the benefits.
2. Remove any Agile roadblocks. You may have internal project management procedures, processes, or standards that inadvertently prohibit Agile behaviors or methodologies. You don’t need to immediately re-write all of your PM processes to include Scrum but you will need to give your new Scrum Masters a “pass” to get around certain areas of the current processes that may inhibit their success.
3. Clear off some wall space and meeting areas! Scrum teams need space for team member congregation and even more wall space for sticky notes, whiteboards, etc. There are Scrum management tools which can be used but some of the best teams may stay relatively low-tech since the focus is on the product being developed and not the by-products of the project management process.
4. Review your current project portfolio and if you have projects where project funding is completely internal (general revenue, etc.) then you should execute an Agile methodology (preferably Scrum) for those projects. Since the actual work will likely grow to fill the available time for the project (Parkinson’s Law), a formalized project timeline might prevent the customer from recognizing when he or she could stop project spending early because the most important goals have been achieved. If you are able to see an opportunity for early release when it occurs you will be able to reallocate that operating budget elsewhere.

The savings in Scrum comes directly from item #4. Remember the 30-day Sprint concept in Scrum; in a 6 month project the customer has five chances to call the system “good enough” and stop the spending. Since to goal of each Sprint is to deliver working software the customer receives “version 1.0″ of the system after the first 30-days and gets to decide what “version 2.0″ should do better or if another version is even needed.

The rebuttal to the above is usually that any project plan could execute the development across multiple phases (iterative development cycles). While this is true, a formalized 6-month timeline assumes up front that exactly five iterations of the system will be required to meet the goals and assumes that the customer knows all of the goals in the beginning and will not change his/her mind.

Advertisement