Category: Program Management

Why So Many Developers are Fed Up with Agile (Pt. 1)

The Never-Ending Agile Grind

Agile has become the way we build software.  Across industries, government institutions, and non-profits, it is the default software development approach.  Debates over whether Agile should supplant traditional project management approaches to software development (i.e., Waterfall) have long been passé.  The focus now is on accelerating the product development lifecycle through DevOps.

However, all is not well in “Agileland”.  Many organizations are not enjoying the benefits promised by the Agile gurus.  Many software developers are fed up with Agile.  If Agile is so great, why are so many people, especially developers, souring on it?  The bottom line upfront (BLUF) is that what passes for Agile in many places is anything but Agile.

This article is the first of a four-part series that describes the most common pain points experienced by software developers and other technical contributors engaged in Agile software development, the root causes, and potential solutions.  The pain points covered in the series are:

  • The Never-Ending Agile Grind – Developers often feel overwhelmed by the constant pressure to produce under tight deadlines.
  • Greater Visibility & Oversight with Less Control – The “radical transparency” of Agile approaches, such as Scrum and Kanban, is often exploited by management as an opportunity to micromanage development teams.
  • Top-Down Driven Agile – Technical contributors often have little say in how their organizations or sponsors implement Agile, leading to the imposition of unnecessary, ineffective, and, often, counterproductive practices on development teams.
  • Changing Expectations for Developers – Developers are moving away from functioning as “order takers” focused almost exclusively on coding to collaborating with product owners/managers, sponsors and stakeholders, and customers and end users to define, verify, and validate what they develop.  Many technical contributors find this level of direct collaboration difficult to manage alongside their growing list of technical responsibilities.

The Never-Ending Agile Grind

Software development is a demanding intellectual activity.  It requires study, perseverance, and focus.  The work requires time to think and experiment.  Some degree of failure is necessary as long as it yields valuable insights and teams use those insights to continually improve the product and how they work.

The experience of too many developers on Agile teams, however, is working in “feature factory” environments and “death march” projects.  They feel pressured and rushed to deliver code to the point of sacrificing quality.

Sprints become Sisyphean ordeals where overburdened teams are under constant pressure to deliver working code as quickly as possible while also maintaining the existing code base and contributing DevOps pipeline automation components.  The end of one Sprint leads to the beginning of another in a seemingly never-ending loop of stress that eventually leads to burnout. 

Teams are not afforded time to think through and experiment with alternative approaches, leading them to commit to suboptimal approaches that will likely take longer to implement and maintain than more elegant approaches they could have conceived given sufficient time.

“Feature factory” teams are denied time “on the clock” to learn and experiment with new technologies, design patterns, and architectural approaches.  As a result, implementations based on those approaches are often half-baked, filled with technical debt, under-performant, and difficult to maintain.  The benefits expected from adopting new technological approaches are not realized.  Meanwhile system complexity explodes exponentially.

Management consistently chooses delivery of new functionality over addressing technical debt.  This short-sided preference leads to increasingly brittle systems that force developers to expend increasing amounts of energy and focus on fixing bugs and babysitting systems.

Overtime, developers start to feel like robotic coding units who get paid to crank out code.  A mentality of “getting it done on time no matter what” becomes culture.  Any vestige of work/life balance is thrown out the window as the backlog of features grows and the system or product becomes ever more unmanageable.

The Causes

The Agile Manifesto for Software Development and the 12 Principles of Agile describe the characteristics of Agile software development.  Software development approaches that adhere to the values of the Manifesto and the 12 principles are considered Agile.  Approaches that deviate from any of the values or principles are not.  One Agile principle “feature factory” teams violate is principle number #8:

Agile processes promote sustainable development.  The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

http://agilemanifesto.org/principles.html

Why do so many software development organizations and their sponsors ignore this principle?  Many blame the increasing pace of business competition or mission threats for this single-minded focus on production and speed.  While pressure from increased competition is a contributing factor, I posit that the root cause is cultural.  Many (if not most) of these organizations take a project management approach to software development.  Agile, in general, and Scrum in particular, have a product management orientation.

Traditional project management, rooted partly in Taylorism, focuses on managing resources, schedule, and budget.  People are a category of resources managed by managers.  Traditional project management places a very high value on maximizing resource utilization to achieve greater efficiencies.  People are the most important (and expensive) resources to maximize.  In the drive to do more with less and meet tight (often arbitrary) deadlines, management often loses sight of the link between team welfare and morale and superior performance.

Product management focuses on managing the product and how the product is made and delivered.  Through Agile, management shifts its focus from micromanaging developers to collaborating with them in continually improving product offerings as well as the development and delivery of those offerings.  Ensuring development teams are not overwhelmed becomes a major concern since it has such a large bearing on product quality, timeliness, cost, etc.

Another cultural factor that leads to “feature factory” cultures is confusion over the role of planning in Agile.  A popular misconception is that there is no planning in Agile software development.  This misunderstanding leads to underemphasizing requirements definition, analysis, and design which, in turn, leads to badly conceived and executed software implementations.

Agile teams plan constantly.  The difference between Agile planning and planning in Waterfall projects is that Agile planning is adaptive while traditional project planning is predictive.  In other words, rather than attempting to plan the entire project upfront, Agile plans change based on current circumstances and new information and insights.

The Software Development Lifecycle (SDLC)

Just like development teams in Waterfall projects, Agile teams perform all the activities encompassed by each of the phases of the Software Development Lifecycle (SDLC).  The difference is that the “Agile SDLC” (DevOps) does not segregate those activities into discrete scheduled phases arranged one after the other for the entire system or solution.  Instead, every feature/deliverable an Agile development team delivers is the product of its own “mini” SDLC.  The resulting system or solution is the sum of all integrated features.

Potential Solutions

So, what are some concrete steps software development organizations and their sponsors can take to avoid overwhelming and burning out technical contributors?

The first step is understanding and internalizing that Agile development teams are self-organized.  They collectively manage their own work, determine technical approaches, develop their own estimates, report their progress, and help define the functionality they build.  Team self-organization is a core tenant of Agile supported by three of the 12 Principles of Agile:

Principle #11:  The best architectures, requirements, and designs emerge from self-organizing teams.

Principle #5:  Build projects around motivated individuals.  Give them the environment and support they need and trust them to get the job done.

Principle #12:  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

http://agilemanifesto.org/principles.html

This contrasts with traditional project management practice, in which management is responsible for defining what to build, breaking down and assigning work, developing plans and schedules, and reporting progress.

Align the Work to Team Capacity

Agile teams break down their work with an eye towards delivering valuable functionality within short timeframes.  They can only achieve this if they align the amount of work they commit to with the team’s ability to get it done.  In other words, break down solution scope into slices of capability (features) that can be accomplished within agreed timeframes.  By ordering/prioritizing features along the lines of business or mission value, Agile releases deliver the most valuable features/capabilities first.

Agile teams commit to additional work as they complete existing work.  Rather than having work pushed on Agile teams, Agile teams pull work when they are ready to do it.  Software development teams that do not have control over the amount of work they commit to are not Agile teams. 

Allocate Time for Specific Tasks during Sprints

One way to ensure that Agile teams address technical debt, and other necessary tasks outside the scope of developing new features, is to allocate some percentage of their time to those activities.  For example, during Sprint planning, a Scrum Team may allocate some percentage of the next Sprint to addressing technical debt.  They could do the same for backlog refinement and DevOps automation work.

Establish Innovation & Planning Sprints

The Scaled Agile Framework (SAFe) includes Innovation and Planning (I&P) iterations (Sprints).  I&P iterations occur at the end of each Program Increment (PI), which lasts eight to twelve-weeks.  Each PI includes two to six iterations depending on the length of each iteration (two to four weeks).  Agile teams do not have to adopt SAFe to experiment with I&P iterations or Sprints.

I&P iterations provide teams time to work important tasks, such as the ones below, without significantly disrupting the flow/cadence of development and release of new functionality:

  • Explore new and innovative approaches (e.g., experiment with new technologies; evaluate products, tools, and services)
  • Work on technical infrastructure, tooling, and other impediments to delivery
  • Engage in continuous learning and improvement
  • Cross train in new skills
  • Engage in longer-term planning (e.g., product roadmap discussions, architecture design)

Conclusion

It is common knowledge that productivity, quality, and innovation suffer when workers are stressed and burned out.  However, too often responsibility for coping with stressful work environments is placed solely on the shoulders of individual employees/contributors while management sticks to outdated ideas about maximizing efficiency.

Agile, implemented in the spirit of Agile, opens the door to sustainable progress and achievement.  Again, development teams that do not control the amount of work they commit to delivering are not Agile teams.  Such teams risk being pressured into over-promising while under-delivering.

In the next article of this series, I’ll discuss how the greater visibility into team activities and progress afforded by Agile is often used to against the development teams themselves.  Just like this article I will also discuss root causes for the dysfunction and suggest solutions.



Three Reasons Business Analysts Need Product Owner Skills

Product ownership skills are key to increasing your marketability and versatility

Note: This article follows the capitalization of Scrum terms followed in Scrum.org’s Scrum Guide.

In a world that prizes specialization, business analysts (BAs) are expanding the profession.  As organizational complexity grows and the pace of change quickens, businesses, non-profits, and government organizations are transforming themselves to better meet those challenges.  The quest for business agility is compelling organizations to abandon traditional project management approaches to information systems development in favor of Agile.  To remain effective and marketable, BAs are adding Agile practices and techniques to their skillsets.

For many BAs, their understanding of Agile is limited to the mechanics of a particular Agile approach, such as Scrum.  Often, their first formal introduction to Agile is some form of Scrum Master training. 

Scrum Master training is taught primarily from the perspective of supporting the work done by software development teams through application of Agile principles and Scrum practices.  Scrum Master training alone does not do enough to address the knowledge and skills most important to BAs supporting Agile projects: how to bridge the work of Agile teams with sponsor, stakeholder, customer, and end-user needs.  Those skills are at the core of Scrum product ownership.

Beyond the fact that Agile has become the preferred way of structuring software development projects across a growing number of organizations, this article discusses three reasons why Scrum product ownership is an essential skillset for any BA.

Reason #1:  Business Analysis Aligns with Product Ownership

Of the three roles identified by the Scrum framework (Scrum Master, Product Owner, and the Development Team) the Product Owner (PO) is responsible for ensuring that the work performed by the Development Team delivers valuable business or mission capability, cost effectively, and in time to be valuable.  As such, the PO and BA roles share many responsibilities.

The International Institute of Business Analysts (IIBA) considers the PO job title to be one of many that fall under the BA umbrella:

Business Analyst Job Titles
Business Analyst overlaps with many job titles, including Product Owner

A comparison of job responsibilities for both roles further highlights how closely related they are:

Business Analyst vs. Product Owner Roles
Business Analyst vs. Product Owner Responsibilities

Reason #2:  Scrum’s Product Management Orientation

A major difference between Scrum and traditional IT project management is Scrum’s product management/development orientation.  Scrum’s terminology is indicative of this product management bias with terms like Product Owner and Product Backlog.  From the perspective of Scrum, software solutions are products.  While the focus of traditional project management is on managing people, schedules, and activities, Agile in general and Scrum in particular focus on managing the product. 

A good way to illustrate the differences between product management vs. project management mindsets is to compare the core functions performed by product managers and project managers.  While their work often overlaps, their primary responsibilities compare as follows:

Product Management vs. Project Management
Product Management vs. Project Management

A product management approach to developing software solutions changes how we define software solutions.  For example, in traditional software projects, functional requirements are decomposed and written in ways that decouple planned functionality from expected business or mission outcomes.  They are written from the perspective of the system (e.g., “The system shall…”).  In Scrum, requirements, typically written as user stories, are written from the perspective of the user and clearly link desired outcomes with planned capabilities:

As <a user or role> I want <some capability> so that <desired outcome>

This user-centric approach to requirements supports Agile’s iterative and incremental definition, development, and delivery of software solutions.  Customer centricity is a key component of Scrum’s product management approach.  That approach aligns well with the goal of business analysis: enabling organizational change by defining business needs and recommending solutions that deliver value to stakeholders.

Reason #3:  No Formal Role for Traditional BAs on Scrum Teams

As I stated earlier, Scrum identifies three roles: Scrum Master, Product Owner, and the Development Team.  While all three roles collaborate to form a cohesive “Scrum Team”, they each have specific responsibilities.  The responsibilities that most closely align with those of a BA belong to the PO.

However, there is one very big difference between the PO role and that of a BA.  The PO is ultimately responsible for the success or failure of the product.  As such, the PO is empowered to make decisions about the direction of the product vision.  In other words, the PO decides what the product will ultimately be, how it will function from a business or mission perspective, and what business or mission capabilities it will include.

To be clear, the PO does not make decisions about how to develop the product. That is the responsibility of the Development Team.

The PO does not make product decisions in a vacuum or by behaving like a traditional project manager.  Instead, the PO works alongside the Development Team in defining the “product” based on input from an actively engaged stakeholder community (i.e., sponsors, stakeholders, customers, and end-users).

For their part, Development Team members collectively manage their own work, determine technical approaches, develop their own estimates, report their progress, and help define the functionality they build.  This contrasts with traditional project management practice, in which management is responsible for defining what to build, breaking down and assigning work, developing plans and schedules, and reporting progress.  Scrum Development Teams are self-organized.

This means that Scrum Team developers develop their own requirements, primarily through collaboration with the PO, but also as they collaborate directly with technical and business/mission-facing members of the product’s stakeholder community.  The old saw about developers not caring about business requirements and being fixated on implementing technology does not apply to Scrum teams.  Developers are expected to be user-centric too and to think in terms of improving the product, not just delivering software components.

So, if there is no formal role for BAs in Scrum, how should they participate and contribute?  There are three BA participation options:  1) As a Scrum Team member; 2) As a proxy to the PO; 3) As the PO.

Business Analyst as Scrum Team Member

The first option would include the BA as a member of the Scrum Team.  The BA would then work with the team to refine the Product Backlog.  The issue here is that the entire Scrum Team participates in backlog refinement. Therefore, the BA would need to contribute through additional duties such as facilitating stakeholder requirements elicitation, creating technical documentation, or explaining business requirements to testers.  Some BAs may consider this a less than desirable fit since their attention would be diverted, to some degree, towards activities outside their traditional role.

Business Analyst as Proxy to the Product Owner

This is the least desirable of the three options and should be avoided.  In this option, the BA is a “go between” for the Scrum Development Team and the PO.  Since the BA is not empowered to make decisions about the product, he/she must gain approval from the PO.  This turns the BA into a time bottleneck and deprives the Development Team and the PO of the close interaction required to make the Scrum Team work as intended.  Eventually the Development Team may learn to discount the input the BA provides since it may be overruled by the PO at any time.

Business Analyst as the Product Owner

This is the best option of the three.  As I discussed earlier, the PO role carries more responsibility and a larger scope than the typical BA role, however, it also shares many responsibilities.  While not every BA will necessarily be willing or able to make the transition, it is definitely a workable option.

Conclusion

BAs typically work in or consult for mid-to-large-sized organizations, where the size and complexity of software solutions warrants employment of BAs.  While a growing number of these organizations are shifting or have shifted towards Agile, many have not or are slow to shift. As a result, many BAs possess experience and skillsets aligned with a traditional project management rather than with Scrum’s product management approach to IT solutions development.

As a BA, acquiring Scrum product ownership skills can only help your career by making you more marketable and versatile.  Regardless of the type of projects you contribute to, the analytical and leadership skills you will gain will help you become a more effective BA.



Delivering Solutions Faster through Agile

It’s not about working longer and harder.

Many organizational leaders think of Agile as a way to speed up software development, and nothing more. They approach Agile with a traditional project management emphasis on improving efficiency. In doing so, they unwittingly corrupt Agile practices to the point of undermining the very agility they are trying to achieve. One of the most obvious signs of this are high-pressure work environments where people work harder and longer to complete unrealistic amounts of work against arbitrary deadlines.

People can work at an accelerated pace for only so long before becoming fatigued, physically and mentally.  As time wears on and stress builds, morale and quality suffer.  The results are inefficient and ineffective development teams, low quality software; and unhappy sponsors, stakeholders, customers, and end users.

Ultimately, these corrupted Agile projects fail, leaving burned out teams and failed projects in their wake.

Speed is One Characteristic of Agility

At Agile Cheetah, we see speed as one of three characteristics of agility: Speed, Control, and Flexibility. We call this formulation “The Agility Triad”.

The Agility Triad’s Three Constraints

The Agility Triad is not a concept of either Agile or Scrum.  It is a construct we developed to organize discussions concerning:

  • What agility means from the perspective of technical projects in general and software development projects specifically
  • Concepts, techniques, and practices from the fields of Lean process management, organizational behavior, product management, and project management that support or impact agility

The triad’s constraints are mutually dependent.  In other words, more or less of any one constraint influences the other two.  For example, accelerating the pace of software delivery requires some degree of control and flexibility.  Overemphasizing control slows software development and decreases flexibility.  Underemphasizing control can turn flexibility into chaos, robbing software development teams of both planning and process stability, thereby slowing progress.

In this article, we focus on the speed constraint of the Agility Triad.

Accelerating the Pace Agilely

From an Agile perspective, developing software solutions faster is not about   working harder and faster. Agile teams plan and execute work in ways that make working at a sustainable pace the norm. 

Our definition of speed includes two considerations:  the timeframe within which we deliver functionality and ensuring that whatever we release is potentially-releasable.

  • By timeframe, we mean how long does it take to release functionality that addresses customer or end user requirements or needs (i.e., diminishing lead time and cycle time)
  • By potentially-releasable, we mean that the software functionality is ready for deployment and use, by customers and end users, should a relevant release authority decide to release it

Diminishing Lead Time and Cycle Time

Agile software development teams develop more software functionality faster by focusing on diminishing what Lean terms lead time and cycle time.

Lead Time and Cycle Time

Lead time is the time from when a customer orders a product to when the customer receives it.  Cycle time is the time between gaining authorization to produce an order and completion of a deliverable product.  When speaking about software development, we replace the word product with functionality, feature, capability, component, etc.

Thinking in terms of lead time and cycle time brings to light ways to improve how we develop software and the software solutions themselves.  This work is ongoing for as long as the solution exists.  It is a “Continuous Improvement” mindset.

Development teams are not solely responsible for diminishing lead time and cycle times.  Since teams depend on their sponsor organizations for support, sponsor organizations must adopt a continuous improvement mindset as well.  For example, slow customer order approval and product delivery processes add to lead time.  Not having necessary production resources in place adds to cycle time, and by extension, lead time.  The more lead time and cycle time look the same, the better.

Agile teams diminish lead time and cycle time by:

  • Minimizing waste from software development processes
  • Managing technical scope (increasing flow)
  • Striving for high quality through technical excellence

Minimizing Waste

The Lean Enterprise Institute defines Lean as a set of management practices that maximize customer value while minimizing waste.  Lean takes a continuous improvement approach to eliminating waste.  While it is not possible to eliminate all instances of waste, Lean teams take every opportunity to identify and remove wasteful practices.  Waste does not always result from unnecessary or deficient process inputs, outputs, and activities.  Sometimes waste is too much of what is needed, like excess product inventory for example.

Lean identifies seven sources of waste (TIMWOOD):

Lean’s Seven Sources of Waste

Managing Technical Scope

Treating project scope as variable, while keeping cost and schedule fixed (i.e., “Breaking the Iron Triangle”) accelerates software development and releases.  Agile teams define project scope as increments of functionality developed and released throughout a project.  Rather than defining the entire solution at the beginning, the solution takes shape over the course of development.

Agile development is iterative and incremental.  Agile teams break up project scope into batches of functionality to produce (e.g., features, components).  By keeping batches small, teams process each batch faster, thus accelerating the overall throughput of completed work (flow).  Each new batch of functionality works with the aggregate of all previously released batches.  That aggregate of functionality is the evolving solution.  The bonus is that, as long as released functionality provides real business or mission value, users can use the solution as it “emerges” rather than awaiting release of the entire solution.

Quality through Technical Excellence

High-quality software is faster and cheaper to produce and maintain than low quality software.  Development teams spend less time fixing and refactoring well architected, properly designed, well-written, thoroughly tested code.  Quality software is easier to deploy, configure, and upgrade, shrinking the amount of time development teams spend on operations and maintenance (O&M).  The common theme is saving time.  Software development teams have more time to spend developing new functionality and improving how they work, which translates into faster and more frequent releases.

Software development teams achieve high technical quality by striving for technical excellence.  Like eliminating wasteful process activities, technical excellence is a pursuit rather than an achievement.  Technical excellence entails:

  • Adopting technical practices and techniques that improve software development (e.g., DevOps, Test Driven Development (TDD), Feature Driven Development (FDD))
  • Committing to ongoing technical professional development
  • Working effectively as part of cohesive technical teams

Conclusion

While increasing the pace and frequency of software development and delivery are key tenets of Agile’s value proposition, we must do so sustainably. This requires a shift in management thinking from a traditional project management emphasis on managing people and tasks to empowering teams. In an Agile context, empowering teams includes: ensuring they have the right skills; equipping them with the right tools; and giving them enough latitude to define and manage their own work while establishing clear business/mission intent and boundaries. In other words, speed comes from continually improving teams and the solutions they deliver.



Looking for an “Agilish” approach to Agile? (pt. 3)

When Agilish is the Only Choice

This is the third and final part of a three-part blog series about:

  • The U.S. Federal Government’s practice of implementing hybrid-Agile/”Agilish” software development projects
  • The perils of Agilish projects
  • How we can make Agilish projects more Agile

“Agilish” software development projects, also known as “hybrid-Agile”, “Scrumfall”, or “Agilefall” projects, attempt to gain the speed and flexibility of Agile while enforcing traditional project management or “Waterfall” project controls. In Agilish projects, development teams engage in Agile “process mechanics” while other project stakeholders and contributors continue working under a Waterfall program construct. This mismatch in project approaches leads to what I call, “the worst of both worlds“:

  • Application of predictive planning and project controls (e.g., Earned Value Management (EVM)) that sap the agility out of Agile while;
  • Lacking detailed program baseline data necessary to measure project progress and apply project controls a la Waterfall

In part one of this blog series, I explained what Agilish projects are and why we should avoid them. In part two, I discussed the reasons why government Agile initiatives tend to move away from Agile principles and towards becoming primarily Waterfall projects with Agile practices added (Agilish). In this article, I discuss how to make Agilish projects more Agile when contractual and acquisition rules make an Agilish project management approach the only choice.

As I stated in the two previous articles, my perspective comes from years of working Agile projects for U.S. Federal Government clients. While many of the references are specific to that environment, equivalents exist at all levels of government, as well as in many private organizations, worldwide.

When Agilish is the Only Choice

In Agilish projects, software developers and other technical contributors are the only people “doing” Agile while everyone else continues working as before.  U.S. Federal Government acquisitions and contracting culture make it practically impossible to “do Agile by the book.”  The question is not whether federal software system projects will be Agilish.  The question is to what degree can we make those projects approximate Agile?

We have two choices:

  • “Tailor” Agile to fit within existing
    Waterfall-centric programmatic processes
  • Change programmatic processes to be more Agile

The first choice is the default for most Agilish projects.  It typically results in failed Agile implementations corrupted by traditional project management biases.  The second choice is harder but more likely to yield success.  It requires acquisitions, contracting, and project management professionals to understand how modern software development practices affect their work and to leverage recent Agile-friendly changes in federal acquisitions regulations and policies.

Break the “Iron Triangle”

Firm-fixed-price contracts can work with Agile as long as we allow scope to “float”.  In other words, keep budget and event milestones fixed while closely managing project scope.  Rather than attempting to define a large number of detailed requirements, define a much smaller set of coarse-grained requirements to flesh out, decompose, and prioritize during development.  Some degree of requirements ambiguity is necessary to achieve the Agile-style flexibility.  This is the idea behind managing a Product Backlog in Scrum.

Keeping the specter of “scope creep” at bay requires two things:

  • Empowered Product Managers and Product Owners
  • Adopting a Minimum Viable Product (MVP) approach
    to defining, developing, and fielding software systems

Formalize Product Management/Ownership

The concept of managing software systems as products is a foreign
concept for government program and project managers.  The U.S. Federal Government treats software
systems development as a management activity for project managers to lead while
Agile takes a product management
approach to software development.

I detail the difference between project management and product management in another blog article.  The main takeaway is that project management focuses on managing people, schedules, and activities while product management focuses on managing the product and its creation. 

In the U.S. Federal Government’s acquisition model, program management offices (PMOs) manage contracts rather than software products/solutions. Requirements definition and solution approaches are left largely for vendors/contractors to figure out from initial sets of requirements developed by a different set of contractors. Developing solutions through active and ongoing engagement between the PMO, other government stakeholders, and vendors goes against how most federal acquisitions and contracting organizations are structured.

In Scrum, Product Owners are ultimately responsible for defining the solutions Scrum Teams develop.  The Product Owner serves as the “Voice of the Customer”, synthesizing the various needs, wants, and perspectives of product stakeholders (both mission and technical) and customers into a coherent and cohesive product vision. Development teams depend on the Product Owner for direction and guidance concerning mission needs so they can define and build valuable software functionality.

This work of defining solutions cannot be outsourced wholesale to vendors in an Agile effort. Ascertaining mission needs and determining how solutions will address them are inherently governmental activities. PMOs must formalize the Product Owner role as part of how they do business. This is a move away from outsourcing the lead systems integrator (LSI) role to vendors and towards assuming a government-as-integrator role. Under this model, government collaborates with vendors as part of the team as opposed to assuming a distant customer stance.

Product Owners need to be government employees empowered to make decisions regarding solution scope and mission-facing functionality and be accountable for solution alignment with mission needs and requirements. Product ownership is a full-time job, not an extra duty for project managers. Government personnel who assume product management/owner positions must receive training, coaching, and support.

Adopt an MVP Approach

The only way to know if a solution is valuable is to put it
in the hands of customers and end users. 
The key to doing so agilely is by releasing increments of valuable
functionality (something people can use to get real work done) iteratively
while ensuring the entire system delivers real mission value as it evolves.  One way to accomplish this is to start with an
MVP.

An MVP is a hypothesis of the minimum functionality required
to provide mission value.  The first MVP
is an initial version of the solution. 
It is “viable” meaning that it is not a crude prototype but is instead a
stable, releasable capability.  MVPs go
through a cyclical process of definition, development, release, usage
monitoring, and adjudication.

The MVP Cycle

MVP adjudication is a process step where we decide whether to add, modify, or remove functionality based on lessons learned from monitoring usage and performance data and from customer/end-user feedback.  We may find that the current solution approach is not viable or will not satisfy requirements and decide to change the approach or abandon the MVP altogether; also referred to as pivoting away from the current solution path.  Each iteration through the MVP cycle results in a new version of the MVP that delivers additional value.  The MVP eventually matures into a solution that maximizes value.

The MVP cycle is an empirical process model that supports adaptive planning.  The combination of empowered product ownership with an MVP-based development approach allows projects to control scope, while keeping within budget and schedule constraints and without engaging in heavyweight, agility-stifling, predictive planning.

Avoid EVM, Use MVPs Instead

Earned Value Management (EVM) is used to determine whether a project is on target to finish (i.e., deliver all planned functionality/scope), within a predetermined schedule and budget. The logic being that the sooner negative cost and schedule variances are discovered, the greater the likelihood the project can be managed back to plan. However, Agile is an empirical practice in which we monitor progress, make decisions, and take action based on what teams have released throughout the project. EVM is a definitive method in which project management predicts progress and works to prevent deviations from established plans. This fundamental lack of philosophical alignment between Agile and EVM prompts the question whether employing them together is reasonable and worthwhile.

An MVP-based solution development approach can help.  MVPs break up the scope of large system implementations into smaller iterations.  This allows programs to stay below mandatory EVM cost thresholds while lowering risk and providing the choice of stopping further development when mission needs are satisfied or when it is otherwise deemed necessary (e.g., bad contractor performance).

Focus on Shortening Program Lead and Cycle Times

Many organizational leaders think of Agile as a way to speed
up software development, and nothing more. 
They obsess over adopting Scrum practices, DevOps pipelines, and Agile
tracking tools because they think in terms of increasing development team efficiency
and productivity rather than on continually improving program lead-time and
cycle time.

Lead Time and Cycle Time

Lead time is the time from when a customer orders a product to
when they receive it.  Cycle time is the
time between gaining authorization to produce an order and completion of a deliverable
product.  We replace the word “product”
with functionality, feature, capability, component, etc. when speaking about
software development.

Focusing on Agile and DevOps practices and tools affects cycle time.  Developers are able to crank out more code faster, but what happens before developers start coding a feature and after the feature is ready for deployment?  How big a percentage of cycle time is tied up in user acceptance testing, security checks, approvals, and integration activities (things out of the control of software teams)?  How much time do these activities add to cycle time and lead time?

In a true DevOps environment, the amount of time actually spent writing, building, and testing code is a small percentage of lead time.  In government programs, lead times dwarf cycle times and time-consuming project or program-specific processes lengthen cycle times.  Often, organizations narrowly focus on improving the shortest time span within program lead and cycle times while ignoring huge time sinks outside of the work performed by developers.

The actions organizations need to take to lower lead and cycle times are organization-specific.  However, one recommendation applies to any organization sponsoring Agile software development projects:  They should identify and manage dependencies between software teams and organizational, vendor, and customer stakeholders from day one.  

In Scrum, the Product Owner works to integrate stakeholders
in ongoing requirements and dependencies management.  It may be advantageous to include stakeholder
representatives in Scrum Teams if the development teams need their input on an
ongoing basis to develop valuable and compliant functionality.

Conclusion

Getting the most agility out of Agilish projects begins understanding the rules of the chosen Agile approach and the statutory, policy, programmatic, procedural, and technological constraints within which the project must operate. Based on that understanding, some mix of tailoring the Agile approach and changing existing organizational processes is in order.

There is no “cookbook” on how to do this. Different organizations and projects will require different approaches and mistakes will be made along the way.

The important thing is to treat the shift towards Agile in an agile way. In other words, whenever possible, work in ways that align with the chosen Agile approach first. Only modify the Agile approach when laws, regulations, and policies absolutely require it. Work to become proficient in the Agile approach before attempting to change it to better suit existing ways of working.

This is guaranteed to bring stress and discomfort in the short term as people grapple with how they will accomplish their work under the new paradigm. However, as long as we treat changes as experiments from which to learn and improve and we implement them in an iterative and incremental manner, we will mitigate negative effects while progressively moving in the direction of greater agility, both from a technological and organizational perspective.