Tag: Product Backlog

Putting the Federal Government in the Agile Driver’s Seat

The definition of system features and scope in federal Agile and SAFe development efforts is an inherently governmental responsibility.

Recently, I came across a job posting for a Scaled Agile Framework (SAFe) product owner (PO) position with a federal government contracting firm. As someone interested in implementing SAFe within the Federal Government, I reviewed it. I wanted to get a sense for whether the job description adhered to the role as described in SAFe and, perhaps, glean the agency’s level of commitment to implementing the framework. Indeed, the duties described were the same as those prescribed by SAFe, however, my initial excitement at seeing yet another example of SAFe adoption within the Federal Government quickly turned into disappointment. The agency was handing over the definition of features and overall work scope to a contractor. This is a fundamental mistake rooted in traditional federal acquisition biases.

The Lead System Integrator Model

The Federal Government tends to outsource the overwhelming majority of its information technology (IT) and digital systems work to contracting firms. This includes the full life-cycle development and operation & maintenance (O&M) of digital systems as well as most of the program management of those activities. The Department of Defense (DoD) often designates contracting firms as Lead Systems Integrators (LSIs) to manage the integration of large-scale, complex, multi-year, digital systems-of-systems (SoS) implementations. Section 805 of the FY2006 National Defense Authorization Act defines two types of LSIs:

  • LSIs “with system responsibility” – Prime contractors responsible for the technical coordination and managerial execution of a systems development program at the system level. They do not perform technical implementation work at either the system or sub-system levels.
  • LSIs “without system responsibility” – Contractors who perform acquisition functions closely associated with inherently governmental functions.

Federal agencies turned to the LSI model in the late 1990s to compensate for a lack of in-house, technical and project management expertise caused by reductions in force of the federal acquisition workforce (by more than 50 percent between 1994 and 2005) and the rapidly increasing complexity of system solutions. By the mid-2000s, however, issues concerning LSI conflicts of interest (e.g., shaping integrations to promote LSI products), lack of effective governmental oversight over LSIs, lack of government visibility into sub-contractor activities, and the difficulty of replacing entrenched LSIs led to legislative and policy reforms and less affinity for the LSI model within the federal acquisitions community.

Today, many agencies are increasingly assuming the LSI role and instituting modular contracting policies to narrow the scope of large acquisition programs into smaller, more manageable programs and projects that do not necessitate a large LSI role. However, in many parts of the Federal Government, there is still a bias towards limited government involvement in the day-to-day management of contractor activities and capability definition. Typically, this bias exists because of a lack of expertise and/or resources. However, this bias sometimes bleeds into activities that can/are considered inherently governmental. I posit that the product management work performed by SAFe POs and Product Managers (PMs) is inherently governmental.

The Role of Product Owner in Agile

The PO is a member of an Agile software development team. They represent the “face of the customer” who will be using the functionality developed by the team. They bring to the team a deep understanding of customer needs and the business domain/market environment the solution will serve. The PO is primarily responsible for:

  • Defining solution capabilities and features through the development of Agile epics and user stories and their prioritization within the team’s product and iteration backlogs

Backlogs include technical work that supports the development and implementation of new business/mission capabilities and features.   Such technical work mostly revolves around the implementation of physical and software infrastructure (“enablers” in SAFe).  While POs are not expected to understand the technical details, they must be able to take into account the scope of these enablers and collaborate with technical contributors in prioritizing the work.

  • Planning upcoming sprints/iterations
  • Elaborating/amplifying user stories before an iteration, during iteration planning, and during iterations. They provide additional information necessary to implement stories.
  • Supporting user story acceptance testing by participating in the development of user story acceptance criteria and formally accepting user stories when they meet the criteria
  • Participating in team demos and retrospectives

All of these activities are informed by input from project stakeholders, customers, product management, program/project management, and the Agile team itself.

Product Management in SAFe

As a framework founded on Agile principles and Scrum practices, SAFe includes the PO role but goes further by including the concept of a product management team function across every configuration of the Framework: Full, Portfolio, Large Solution, and Essential SAFe. SAFe POs collaborate with their development teams in defining team backlogs and help formulate and articulate a program vision and program roadmap. The program vision and program roadmap inform/guide the development of program features and team user stories. The program vision and program roadmap are themselves shaped by solution and portfolio-level concerns (depending on the SAFe configuration implemented). POs in SAFe are at the most tactical end of a strategic product management regime.

Breaking the Iron Triangle

The most fundamental way Agile and SAFe achieve agility is by breaking the Iron Triangle. Instead of attempting to fix schedule, budget, and scope upfront, we fix schedule (timebox) and budget while letting scope “float.” However, both Agile and SAFe prevent project/work scope from floating too far because POs are empowered to define, prioritize, and approve scope.  Moreover, in SAFe, POs and PMs across the SAFe hierarchy enforce scope discipline by:

  • Communicating with development teams regularly and often
  • Defining and articulating SAFe Agile requirements (epics, capabilities, features, user stories, and enablers)
  • Prioritizing SAFe Agile requirements
  • Actively participating as the acceptance authorities of developed functionality vis-à-vis SAFe Agile requirements
  • Working with teams to plan sprints/iterations, releases, and program increments (PI) – Breaking up scope across timeboxes

Agile and SAFe promote and enforce transparency at all levels. Decisions are made in the open with the input and concurrence of all pertinent stakeholders. In properly run Agile teams, there are no surprises: teams commit to a known set of work; the work is tested as it is developed and integrated and test results are made known; and release candidates are demonstrated to work at the end of each iteration and PI. Issues and impediments that jeopardize delivery are exposed every day through Scrums, automated testing, and frequent integration.

Breaking the Iron Triangle is a big departure from the way federal acquisitions currently works. Federal program management oversight culture and practices must change so that government program managers and project stakeholders can begin to take a much more active role in the definition of functional requirements alongside Agile teams. This will take changes in acquisition policy and law, training across government acquisition and functional communities, and leadership committed to championing new approaches to old, recurring problems. Progress in this direction is being made (e.g., 18F, Digital Services, the TechFar, Modular Contracting and a slowly growing willingness to acquire Agile services under Time & Materials (T&M) and Level of Effort (LOE) contracts).

Conclusion

Appointing contractors to act as SAFe POs and PMs is an indicator that the SAFe implementation/adoption is subverted (an anti-pattern). It is a throwback to the lack of oversight and control experienced under earlier programs run by LSIs. To ensure that real value is created for every taxpayer dollar spent on federal systems development, the Federal Government must be in the driver’s seat. SAFe enables the creation of an ecosystem where technical and management expertise from the private sector works to fulfill requirements continuously defined and prioritized by government stakeholders. This “just in time” approach to scope and requirements definition is the key to achieving agility, lowering costs, and achieving faster, more frequent releases, while improving quality.



Five Things You Must Understand about Agile Team Velocity

Agile team velocity is an often misunderstood concept that is prone to misapplication. This article sets the record straight.

Agile software development is the way we build software now. The general consensus on management of software development projects is that predictive planning approaches (e.g., Waterfall) are ill suited for the job. However, almost two decades after the release of the Agile Manifesto and the rise of Scrum as the most popular Agile framework, team velocity is still a point of confusion.

Some organizations are under the mistaken idea that they can “buy” Agile-Scrum software development services à la carte based on team velocities. Under this contracting model, service vendors offer prepackaged teams rated at some velocity. Based on that velocity, the organization could then pay for a certain amount of that team’s time to complete predefined tasks. This arrangement treats Scrum teams as plug-and-play units of development capability. This mentality is evidence of a fundamental misunderstanding of Agile and Scrum, of what teams require to be effective, and of the concept of team velocity itself.

What is Team Velocity?

The concept of team velocity is not officially part of the Scrum framework. It is a best practice for estimating Development Team throughput. More specifically, it is the rate at which the Development Team, in collaboration with the other members of the Scrum Team (i.e., the Product Owner and ScrumMaster), delivers discrete items of functionality that are finished, tested, and accepted during an iteration/Sprint. The Scrum Team documents requirements for those items as User Stories and tracks and orders User Stories in the Product Backlog.

Rather than simply counting the number of completed stories at the end of a Sprint, the Scrum Team determines its velocity by adding together story points from every story completed during the Sprint. Story points form the basis for determining team velocity. Calculating team velocity allows Development Teams to estimate the amount of capability (value) they can deliver at a sustainable pace during a Sprint.

Σ Story Points of Completed User Stories During a Sprint = Velocity

It is important to view team velocity results as data points along a trend, rather than as definitive stand-alone measures.  In other words, to understand how much value a Development Team is capable of delivering, we need to look at velocity results from the previous two or three Sprints to get a sense of whether the latest result is part of a trend or an anomaly.  Such anomalies often indicate issues requiring attention.

Like the concept of team velocity, story points are not part of the Scrum framework. The Development Team assigns story points to Product Backlog items (i.e., Epics and User Stories). Story points are heuristically-determined, numerical proxies representing the combination of perceived or estimated:

  • User Story complexity, risk, and uncertainty
  • Level of effort required to complete the User Story

This combination is often referred to as the “bigness” or “size” of a User Story. The Development Team estimates User Story points by “sizing” User Stories relative to each other. More complex User Stories typically require more time and effort to complete, thus earning more story points than less complex stories.

Story point estimation is not restricted to specific timeframes or meetings. It is part of a continual refinement of Product Backlog items by the Scrum Team that includes:

  • Adding, updating, or deleting items
  • Decomposing items into smaller items
  • Adding details and estimating story points
  • Ordering/prioritizing items

Five Key Team Velocity Concepts:

1.  Only the Development Team estimates story points with input from the Product Owner and other relevant stakeholders. They are not determined by a chief engineer or some other senior authority as an estimation exercise prior to the establishment of Development Teams and the appointment of Product Owners.

2.  Team velocity is specific to the team.  Velocity cannot be used as a point of comparison between teams.  Team X is not necessarily faster or able to attain a higher throughput than Team Y because they earned a higher number of story points during a Sprint.  The story points upon which team velocity is based are specific to the relative sizing performed by the team on their particular backlog of User Stories.

3.  A team’s velocity is the end result of many factors, including:
  • Individual team member productivity across the team
  • Team cohesion, collaboration, and effectiveness
  • Team skill set and experience mix
  • Level of programmatic support (i.e., the factors that fall under the purview of program management)
  • Empowerment and level of engagement of Product Owners
  • The team’s familiarity with the business domain, technology mix, and enterprise architecture
  • The amount of automation leveraged in building, testing, and deploying code

Thus, the makeup of the Scrum Teams and the environment or ecosystem within which they operate determine velocity.  Team velocity is ultimately a proxy for the overall health of the software development program and organization.  When team velocity stagnates or drops, the search for potential causes must be systemic as opposed to a hunt for individual culpability.

4.  It is normal for team velocity to fluctuate.  What should concern us are large fluctuations or downward trends in velocity.  Changes in personnel, technology, organizational structure, etc. will affect development teams in different ways and to varying degrees.

5. Improving team velocity is not the goal!  Improving team capabilities, practices, tools, and program support improves team velocity.  Focusing on improving velocity results in attempts to game the system rather than systemic improvement.

Conclusion

Scrum Development Teams are composed of people. People are not machines calibrated to deliver a predetermined rate of output. Teams need time and stability to gel into highly effective teams. Helicoptering Scrum Teams, even experienced ones, in and out of tasks significantly degrades velocity except perhaps for the most mundane and menial tasks (In which case, why employ Agile/Scrum at all?). Decades of reducing people to resources allocated across Gantt charts has led many to also think of Scrum Teams as abstract productivity units. Scrum requires much more of us.