Agile Software Sustainment in a Government Organization

"The Agile Experiment"

25 October 2013

Tina Johnson
Engility



So, what does it mean to be Agile in a government organization? What does it mean to use Scrum in software sustainment? How does this work? Why is it better than Waterfall processes? How does it complement and enhance Capability Maturity Model Integration (CMMI)? This article will answer these questions and more, providing an analysis of current status, proof of success, and the possible future actions that could make a successful Agile software-sustainment government organization.

The strength: A "vehicle"

For any machine, such as a vehicle, to run smoothly, gears must be well oiled, turning, teeth grooves not worn down, synced in time, etc. There is a machine or vehicle in a government software-sustainment organization. Our organization is structured with functional areas (or teams) that each represent a gear consisting of Configuration Management (CM), Quality Assurance (QA), Independent Validation and Verification (IV&V), Training, Information Assurance Vulnerability Alerts (IAVA), Unit Support, and Chief Information Officer (CIO). The other key elements are the software sustainment gears or teams for each software sustainment project. The vehicle (machine) has separate working parts such as gears, belts, nuts, and bolts. These parts work together to make up systems (teams) such as the engine, wheels, and transmission. Alone, these systems cannot accomplish the mission. However when these systems are properly put together and tuned, it becomes a new system and the " . . . whole is different from the sum of its parts."  (Aristotle, Gestalt Theory)

Why adopt Agile?

Agile thinking is not new. In 1986, Takeuchi and Nonaka initiated a new way of building software to deliver frequently; continuously evaluate; and adjust, overcome, improvise -- respond to change within the iron triangle of cost, scope, and time. The Manifesto for Agile Software Development states the basic values of:
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
Going back to the machine, each system team or functional area is just one gear of the machine, needing support from the other functional areas or gears and also supporting those gears in return. Our Agile Projects decided to adapt the Agile thinking and formed a "Beta" Scrum team as a proof of concept because they wanted to stop the bottleneck of stockpiling software problem reports, or artifacts in a repository such as ProjectForge. They wanted to fix the anomalies, provide unit support in a timely manner, and respond to Information Assurance Vulnerability Alerts (IAVAs) in a timely manner. The gears needed to work together both inside and outside the Beta Scrum team.

Lessons learned since January 2013 include being able to conduct work in iterative and incremental time blocks with specific, sizable chunks that were met. In less than four months, more than 97 software resolutions were completed using Scrum in comparison to last year, with a whole of only 20 resolutions using Waterfall processes. This is a 79 percent increase. Requirements and solutions evolved through collaboration and constant communication between the self-organizing, cross-functional teams, the customer/user, program manager (PM), and the product lead/product owner. Daily customer collaboration throughout the time blocks provided transparency, built respect and trust, and increased work quality between the engineers conducting the work and the government product owners/leads. Engineers were able to produce pieces of working software solutions sooner rather than later. Finally, engineers were free to respond quickly to changing needs.

Why practice Scrum?

The Beta Scrum team implemented the Scrum framework, realizing the value of Scrum requiring effort and adjustment by the project team and stakeholders. Project planning occurred effectively with Agile and Scrum. The Scrum practice began with training, a kickoff meeting using a "release planning" meeting format to conduct release planning and to set up the sprint iterations. The assumed product backlog of 880 artifacts was narrowed down to 140 software problems (artifacts) to work in the first release window; these had already been approved by the Configuration Control Board (CCB) and were in Candidate for Release (CFR) status. The artifacts, or user stories, were already assessed and had product resolution estimations. Each sprint had its own folder and we planned out which user stories/artifacts were going to be worked into which sprints.

Service-Oriented Architecture (SOA) and Agile -- A customer-focused approach

Service-Oriented Architecture (SOA): This is more than just embracing a "Help Desk" concept. It's a cultural paradigm shift to meet sustainment requirements and support user needs. Think of SOA as the vehicle moving toward a goal with the right amount of gas, oiled parts, and defined goal and direction. SOA provides interoperability and consistency, along with patterns and practices to support sustainment. The Scrum team's goal is to provide software (IAVAs and fixes) to the user in a timely manner. Adopting a services model means supporting the overarching business requirements, technical capabilities, and operations supporting the user by providing improved capabilities and meeting requirements set forth during concept development and emerging during fielding and sustainment. The Information Technology Information Library (ITIL) Foundation Help Desk model enables a program to distribute the individual burdens across capabilities in multiple tiers of components (tier 1-3 help desk, unit support, media replication, and anomaly troubleshooting). Interaction with functional areas (CM, IV&V, Security, Integration), which are the other gears, enables production of the capability supporting the needs of the systems without compromise to capability. SOA describes how the team practices and uses solution patterns to provide numerous resolutions for different versions, saving time and resources and not "reinventing the wheel." Finally, adapting an SOA enables the team to meet specific capacity, performance, and integration requirements.

Agile development: Proof is in the success

After the first sprint began on January 3, 2013, the team realized the Scrum practice value because of the following:
  • Stakeholder vision, participation, buy-in, flexibility, and ownership increased.
  • Roles were defined (product owner - product lead, ScrumMaster, team members).
  • Predefined meetings (sprint planning, daily Scrum, sprint reviews, and sprint retrospectives) decreased overhead time.
  • Freedom to choose work and collaboration improved learning and shared work.
  • Team protection was increased so work was accomplished with fewer distractions.
  • More artifacts were "done" (potentially shippable software, documentation, CMMI evidence artifacts, units supported with media, tier 3 help desk requests resolved).
  • Productivity increased, doubling and even tripling the completed software anomaly resolutions due to consistent priorities (working increments of the final software product).
  • What was promoted and emphasized: Delivery to next team/gear in the machine and eventually the customer in a timely manner; open communication with all involved, whether they were fully committed or partially participating; team self-organization and self-accountability for work completed or not completed within manageable time blocks and manageable work packages; transparency of obstacles and possible solutions.
  • Stakeholder satisfaction increased (determine priorities, see consequences of changed priorities, and view software as it is iteratively developed).
  • Qualit became better overall (defects found sooner and fixed more quickly using test-fix-test before IV&V).
  • The iterative approach led to enhanced CMMI artifact/evidence collection, organization, tracking, and reporting.

Impacts of Scrum on Capability Maturity Model Integration (CMMI)

A common misconception of CMMI within an organization is that the organization must "waste" time developing documents, work products, and artifacts to "meet" the CMMI best-practices model. Product owners, stakeholders, and team members tend to think of CMMI with a negative connotation, feeling that they are being forced to waste time complying with CMMI rather than what is really important, which is delivering an exceptional product and service to the one who matters most, who is the customer. With the implementation of Scrum, the architecture of the CMMI framework just falls into place for the project. The process of Scrum and Agile development requires that constant tracking and reporting measures be put in place as well as incremental planning, monitoring, controlling, and replanning, which are managed and overseen by the ScrumMaster. This seamlessly translates into up-to-date work products required to satisfy CMMI-specific practices and goals. We should not be working to satisfy CMMI processes; our work should result in satisfying CMMI, which is what Scrum and Agile development afford us to do.

Weaknesses/threats/obstacles

There is definitely one thing that practicing Scrum and Agile will do. The obstacles, impediments, and overall organizational deficiencies will become transparent, so much so that these issues will not be ignored and must be resolved. Every two weeks after a review, the team conducts an after-action review called a retrospective, which includes what went well, what didn’t go so well, and possible solutions to the not-going-so-well issues. Within our organization, one common theme keeps surfacing: All the software resolutions that the engineers have done are now bottlenecked by organizational processes, leadership direction, and current policies, and are not released to the user in need. Other impediments include:
  • Policies and processes over people, seeming to be more important than the people they are supposed to support.
  • Value of work conducted is often overlooked.
  • Lack of "flexible" planning, on the tactical, operational, and strategic levels. This leads to lack of vision, communication, trust, commitment, and accountability.
  • Command decisions are made based on improper data and misinterpreted "facts." This, in turn, has caused too many knee-jerk reactions, causing frustration.
  • Aging workforce and not enough flexibility means there is little way to provide back-up expertise with specialized skills if subject matter experts (SMEs) are on vacation.
  • Morale is affected by uncertainty about job positions and about economic stability.
  • Release times are long; too much time goes by before resolutions can be tested and released because of approval processes and policies.
  • Standards are sometimes not well defined, other times too strictly interpreted.
  • Drive-by taskings are still too high in number and are not all captured, impacting the whole team's effort to get done what they need to get done.

Opportunities/way ahead

Not all obstacles can be resolved at this time. Nevertheless, like everything else, one must start somewhere. A ScrumMaster must remove obstacles and protect the team from requirements creep during the sprint time block. That being said, the number-one obstacle the organization (both government and vendors at all levels) can attack is to conduct Agile and Scrum training and include all areas in Scrum. The next action to follow up with is to practice Scrum across the whole organization. Create a Scrum of Scrums. This would ensure that each team lead, or ScrumMaster, participates and shares to foster communication across the teams. Another opportunity is to change the flow of sustainment Software Problem Reports (SPRs) and issues and incorporate a validity assessment that would include:
  • Issue reproduced -- Checks to see if the software problem can be reproduced
  • Requirement mapping -- Checks to see if the software problem maps to a requirement in the Capabilities Production Document (CPD)
  • CCB approval -- Stakeholders either approve or disapprove the validity and vote to start work on resolutions; the CCB also focuses on applying due consideration to every change request concerning functional requirements
  • Resolution -- Resolve the software problems upon CCB approval
  • Engineering Review Board (ERB) -- Provides technology leadership to deliver business value and anticipate change to meet the current and long-term needs of the project
This organization must first agree to complete buy-in and then needs to develop and use Continuous Integration (CI) practices:
  • A Scrum team integrates its work at high frequency, usually at least daily, leading to multiple integrations per day.
  • An automated build, including automated testing, provides engineers the ability to verify each integration to detect integration errors as quickly as possible, resulting in an automated and self-testing build.
  • The entire life cycle is automated, starting from checking out the source code (as in a digital library) to distributing the build artifacts.
  • All unit tests are run before checking the code into the repository to ensure system ability.
  • Merging code frequently helps avoid integration issues.
Other opportunities learned that will be applied in the future with the Scrum teams include:
  • Provide value-added in tasks completed, not just cost/burn (working software with customer feedback).
  • Communicate and embrace transparency throughout the organization.
  • Provide training and backups, interns for younger workforce opportunities.
  • Hold 9- to 12-week release cycles for a product that is constantly growing and meeting new needs.
  • Lengthen the sprints to 3 weeks to allow teams to focus on work with a good battle rhythm, and include time for internal test-fix-test before passing on to next team/gear.
  • Continue sprint reviews to keep the teams appropriately focused.
  • Continue to ensure that the product owners are engaged and participate in daily stand-ups.
  • Conduct regular user engagements to continuously refine customer priorities and visions with usability that meets the needs of the end user.
  • Provide two separate but identical system environments to allow different work streams to have dedicated work environments. One should be dedicated for development to ensure that work continues during testing periods. One should be dedicated to integration/quality assurance to get ahead of the testing because Agile does not allow for an elongated test cycle.
  • All functional areas and sustainment systems adapt true Scrum framework and practices, as well as get government buy-in to fix the last bottleneck obstacle of getting working software out the door sooner rather than later.
Finally, the sustainment systems and functional areas will be greatly impeded and not meet the users' requirements unless this entity addresses its organizational obstacles. The government software sustainment organization will remain stagnated with no efficient or timely way of getting resolutions out the door to users who need them to continue real-world missions if transformation to an Agile organization as a whole does not occur in the near term.

On a positive note, if Agile is embraced, the machine will run much more smoothly, be more productive, and provide a new resolve to government software sustainment organizations as a whole.

Article Rating

Current rating: 5 (1 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.