Category: Product Owner

The Five Most Important Factors in Prioritizing Product Backlogs

Achieve effective Product Backlog ordering by optimally balancing five competing factors

Note: This article includes a video detailing how to calculate Weighted Shortest Job First (WSJF) values.

Product Backlog “prioritization” is a popular topic in Agile and Scrum forums.  It seems like a simple concept.  Teams prioritize the most valuable or important product backlog items or features and begin work on the highest priority items.  However, teams quickly discover that there is much more to prioritizing backlog items than that.

The difficulty boils down to determining what is more or less valuable or important when every item addresses valid needs.  How do we deal with the ambiguity of determining what is “most valuable” or “more important”?  How do we account for dependencies and other factors that influence what we build and when? How do we do so in a consistent, non-biased way that ensures delivery of valuable solutions, cost effectively, and in time to be most valuable?

Understanding Product Backlogs and their Refinement

For the uninitiated, before reading more about Product Backlog prioritization, I recommend reading our article on Product Backlog refinement.  At a minimum, understanding what a Product Backlog is and what Product Backlog refinement entails is crucial to understanding backlog prioritization.

Product Backlog refinement includes three main activities:

  1. Management of Product Backlog Items:  The creation, retrieval/tracking, update, and deletion of items
  2. Sizing of Product Backlog Items:  Relative size estimation of items
  3. Ordering:  Deciding in what order to address each item

In this article, I focus on Product Backlog ordering. This article does not apply to Sprint or iteration backlogs. Sprint backlogs are solely composed of user stories that take two to four weeks to complete. These items are likely too small in scope to warrant multi-factor prioritization/ordering schemes.

Prioritization vs. Ordering

As of 2011, the official Scrum Guide began defining the Product Backlog as “an ordered list” instead of a “prioritized” list.  Why was this changed and what is the difference between prioritizing a list and ordering it?

As Barry Overeem states in his Scrum.org article:

The focus on ordering (over ‘prioritization’) underscores the active role that the Product Owner continuously has to play in the ordering and reordering, of the work in a manner that maximizes value.

https://www.scrum.org/resources/blog/myth-5-scrum-product-backlog-prioritized

Simply stated, many factors influence Product Backlog Ordering, not just what is considered most important from a business or mission perspective.

Non-trivial software solutions service many sponsors, stakeholders, customers, and end users.  Their interests and priorities differ from, and sometimes contradict, each other.  It is the job of the Product Owner (PO) to fuse the various needs, wants, and perspectives of that solution community into one complete, coherent, and cohesive product vision.

There are also project and technical realities that must be taken into account when deciding what portions of a solution to build and deliver and when.  Examples:

  • Environments (e.g., development, integration, test, and production environments) may not be ready for use at a particular point in the project schedule
  • Key system dependencies (e.g., features, components, libraries, frameworks) may be missing or incomplete, thus impeding progress
  • The customer may add or take away project scope during the project

Business or mission circumstances, solution community needs, solution requirements, and project priorities change as the solution takes shape through iterative and incremental delivery of system capabilities.  A PO must lead continuous refinement and ordering of Product Backlog items to align with such changes.

Five Factors that Influence Product Backlog Ordering

The most optimal ordering of Product Backlog items is a balance between these competing factors:

  1. Business/Mission Value
  2. Cost/Size
  3. Time Criticality
  4. Technical Dependencies
  5. Risk Reduction/Opportunity Enablement
Figure 1: Product Backlog Ordering Factors

Factor 1: Business/Mission Value

How Agile defines value is different from how traditional project management defines it.  A simple definition of value is whatever solution sponsors, stakeholders, customers, and end users care about or makes them happy.  We discuss Agile’s concept of value further here.

A feature’s business or mission value is the value created by implementing the feature (e.g., revenue, cost savings, customer retention, prospective customers, future opportunities, mission accomplishment).  Features that map closest to the product vision likely rank highest for this factor.[1]

Factor 2: Cost/Size

It is common Agile practice to use relative sizing to estimate how much of a development team’s capacity will be consumed by a particular Product Backlog item.  One way Agile teams perform relative sizing is by assigning story points to Product Backlog items. 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” stories relative to each other. More complex stories typically require more time and effort to complete, thus earning more story points than less complex stories.

Just as there is a correlation between story complexity and size, there is also one between story size and the cost of implementing the story.  While not a perfect correlation, it is good enough to support efficient ordering of Product Backlog items.

Factor 3: Time Criticality

How soon solution capabilities or system dependencies are needed also influences Product Backlog ordering.  Again, the goal of Agile is to deliver valuable capabilities, cost effectively, and in time to be valuable.  Delivering a capability before it is needed risks spending resources on something that may never be needed (YAGNY:  You Aren’t Gonna Need It!).  Delivering after it is needed risks delivering it too late to be valuable.

Agile achieves a “just-in-time” balance by constraining planning, development, and release scope to fit within relatively short time frames (iterations/Sprints/releases) and delivering the highest ordered items first.  By waiting until “the last responsible moment” to define, develop, and release solution functionality, we avoid over-engineering solutions or losing opportunities to provide value.

Factor 4: Technical Dependencies

Software solutions are inherently complex.  As such, their technical components often rely on other components to function.  For example, multiple features may require a database backend to store data and state.  Product Backlog ordering must take into account these dependencies as solutions grow and evolve.

Factor 5: Risk Reduction or Opportunity Enablement

Software system complexity introduces technical and project risks and opportunities.  Diligent backlog refinement spreads risk management actions across the entire software development effort.  For example, a team may choose to tackle riskier Product Backlog items earlier.  Another may identify an opportunity to shorten the schedule by accelerating delivery of a dependency common across multiple parts of the solution.  This differs from traditional project management efforts that, even when risks and opportunities are identified early, tend to accumulate risks, address them after they become issues, and miss opportunities.

Prioritization Techniques

Backlog ordering is the art of balancing these five factors to best facilitate Agile development and delivery of software solutions.  The three prioritization techniques briefly discussed in this section are not specific to Agile or Scrum.  They are well-known product management techniques. 

The first two, the Kano Model and the MoSCoW Method, have narrow perspectives and reduce business or mission value considerations to simplistic categories.  The third technique, Weighted Shortest Job First (WSJF), takes into account all five factors discussed in the previous section.

Kano Model

Professor Noriaki Kano developed the Kano Model in the 1980s.  The model categorizes product features according to customer needs and expectations.  In other words, what will satisfy or please customers?  Many versions of the model exist.  The original classifies items using five categories: Must-be, Attractive, One-Dimensional, Indifferent, and Reverse.

The Kano Model is most useful in organizations that create mostly “Must-Be” features: Features expected or taken for granted by customers.  However, products should include “Attractive” and “One-Dimensional” features to succeed in the marketplace.

Table 1: Kano Model Categories

Using this technique, the Product Backlog would include items from every category except “Reverse”.  Releases and Minimum Viable Products (MVPs) would include some set of items from those categories.  As MVPs grow and evolve, more items from across those categories would be added.

The problem with this approach is that it narrowly focuses on customer needs and expectations, which is one of many factors in gauging business or mission value.  However, Kano Model category definitions are useful in helping to shape thinking about the business or mission value of solution features.

MoSCoW Method

The MoSCoW Method, developed by Dai Clegg, has roots in Agile software development.  It is an acronym loosely based on the first letter of each of its categories: Must-Have, Should-Have, Could-Have and Won’t-Have.  The categories are defined from the point of view of what a product includes or offers vis-a-vis what customers or users want.  It answers the question, “What features will be included in the release or MVP?”

Table 2: MoSCoW Method Categories

Similar to the Kano Model, using this technique produces a Product Backlog that includes items from every category.  “Won’t-Have” items may either be postponed to future iterations or releases or dropped from the backlog altogether.

However, like the Kano Model, the MoSCoW Method focuses on one dimension of value.  In the case of the MoSCoW Method, it is determining which set of features best aligns with customer and end user expectations about the product/solution.

Weighted Shortest Job First (WSJF)

In his book, Principles of Product Development Flow: Second Generation Lean Product Development, Don Reinertsen explained the Weighted Shortest Job First (WSJF) prioritization model.  The model is used to sequence work in the most economically efficient way.

The folks at Scaled Agile Inc. explain a simplified version of Reinersten’s model here.  The simplified approach consists of two formulas:

Figure 2: A Formula for WSJF
Figure 3: Calculating Relative Cost of Delay

This simplified model is used in the Scaled Agile Framework (SAFe) to sequence (order) individual pieces of work or “jobs” (e.g., SAFe Features, Capabilities, and Epics) within their respective backlogs.

Unlike Reinertsen’s model, which uses monetary amounts to calculate Cost of Delay (CoD) and job duration, SAFe’s simplified model uses a relative sizing construct.  The construct uses a modified Fibonacci sequence as the basis for parameter values.  In calculating CoD, values for User-Business Value, Time Criticality, and Risk Reduction/Opportunity Enablement are assigned greater or smaller values relative to other jobs being ordered.  For job duration, “size” values are assigned to individual jobs.  Every job is sized relative to the other jobs being ordered.

We can create a simple table to track the relative values and calculate CoD and WSJF values:

Figure 4: WSJF Table

The following video provides more details on calculating WSJF values:

Calculating WSJF Values

The initial formulaic answer is a start to the ordering, not a final answer.  The computed sequence of Product Backlog items is adjusted to account for technical dependencies between them.

Teams may find it helpful to keep in mind the Kano Model and MoSCoW Method categories as they assign relative business or mission values to Product Backlog items/features and determine which items are ranked too low to include in the next Sprint or release.  Just remember that those categories do not represent the entirety of business or mission value.

We can use WSJF sequencing whenever Product Backlog we perform refinement.  Since Product Backlog refinement is a continual process, there will be future opportunities to apply WSJF.  Aim for “good enough” and trust that whatever issues surface later will be taken into account during the next round of Product Backlog ordering.

It is good practice to not let Product Backlogs grow too large.  Clearing items that may never be implemented is a good idea.  They can always be reintroduced later for ordering.  In the same vein, avoid ordering the entire Product Backlog.  Instead, focus on the next three Sprints or so.  Ordering items that may never rise high enough in the backlog to be implemented is wasteful.

Remember that Product Backlog ordering is an art, not a science.  As leads of this process, POs must leverage input from their Development Teams and solution community stakeholders and their own intuition and experience.

When Not to Employ WSJF

If the product backlog is small or mainly populated with user story-sized items, computation of WSJF values may be overkill. However, it is still advisable to take the five ordering factors discussed here into account when ordering product backlogs.

Leveraging User Story Maps

Scrum Teams can leverage user story maps to organize an ordered Product Backlog across solution workflow steps, Sprints, and releases.  Scrum Teams may use them in tandem with Product Backlogs to help identify dependencies as part of backlog refinement.  We explain user story mapping and provide an example here.

Capacity Allocation

The Product Backlog contains all of the solution requirements (e.g., epics and user stories) for which the Development Team may implement features.  If it is not in the Product Backlog, the Development Team does not implement it.  However, just because something is in the Product Backlog does not mean it will be done.

In light of this, it is often difficult for teams to balance delivery of business or mission value with work necessary to:

  • Implement back-end functionality or infrastructure that supports business/mission-facing functionality
  • Perform system maintenance to ensure overall system performance and quality
  • Address technical debt
  • Explore new requirements and technical approaches to address them

One way Scrum Teams achieve the right balance between different types of work is through capacity allocation.  Teams allocate their capacity to do work within an iteration/Sprint.  They allocate percentages of that timebox to specific types of work.  For example, a team may agree to devote most of the next Sprint to developing new business or mission capabilities, but allocate a percentage of that time to address technical debt and maintenance.  The team agrees to the types of work they will perform, and the percentages of the Sprint those work types will consume, based on current needs and constraints.

Conclusion

The key to effective Product Backlog prioritization is achieving an optimal balance between competing factors.  “Optimal” does not mean perfect. 

The WSJF technique provides a simple way of accounting for those factors.  WSJF is only a tool to help make decisions.  It is not a deterministic process that renders an exact solution. 

Arriving at a “good enough” Product Backlog ordering depends much more on effective collaboration between POs, development teams, and solution community stakeholders than on applying the techniques discussed in this article.  Ultimately, the quality of Product Backlog ordering depends on Agile’s empirical inspect and adapt approach to defining and executing work.

[1] Don McGreal and Ralph Jocham (2018).  The professional Product Owner: Leveraging Scrum as a Competitive Advantage 1st Edition. Scrum.org



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.



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.



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

Don’t! But if you must …

This is the first 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

You are likely reading this because you are looking for a way to make Agile work within the byzantine world of government/public sector Information Technology (IT).  My perspective comes from more than a decade of working with the U.S. Federal Government implementing software systems using Agile.  I have spent a good portion of that time working in “hybrid-Agile”, “Scrumfall”, “Agilefall”, or “Agilish” projects.  My advice: Do your best to avoid Agilish projects.

Reasons to Avoid Agilish Projects

Look, I get it.  You
are likely getting conflicting direction from your government agency or
client.  They want Agile’s speed and
flexibility with traditional project
management or “Waterfall” project controls. 
They want end users to have greater say in shaping solution features
during development, but award firm-fixed-price contracts and require adherence
to inflexible program baselines.  Even
when agencies use “Agile-friendly” contracting rules, contract language and
oversight requirements often impose Waterfall processes and reporting
requirements.

The problem is that you can’t have your cake and it too.  There is no free lunch. <Insert another hackneyed phrase here> In trying to be both Agile and Waterfall, most Agilish government projects toss agility aside to accommodate established project management processes.  I now discuss concrete reasons why Agilish projects are a bad idea.

Agilish isn’t a Real Thing

Hybrid Agile or Agilish is not a recognized software development approach.  It is an project management approach to Agile without roots in proven Agile or software engineering practices.  There is no standard framework (like Scrum) or body of knowledge (like SAFe or PMBOK) for Agilish implementations.  Without standards or best practices, you’ll be making up your own Agilish implementation as you go.  The same goes for contract firms that claim expertise in hybrid-Agile.

Predictive vs. Adaptive Planning

In traditional project management, the bulk of project planning happens before and immediately after the start of a project.  This is a predictive planning approach.  Predictive planning assumes the next project will be similar to previous projects.  Thus, it is possible to estimate (predict) the amount of work (scope), necessary resources, timeframes (schedule), and cost (budget) of the next project based on historical data and experience.  This assumption is fine for routine and relatively simple projects but breaks down for more complex, technically challenging, or innovative projects. 

Agile planning is adaptive planning.  In Agile, planning and management of risks and opportunities occur throughout the entire effort.  Decisions are based on lessons learned and insights gained during development.  This allows Agile teams to, “Welcome changing requirements, even late in development.”

The Worst of Both Worlds

Mixing Waterfall with Agile yields the worst of both worlds.  You introduce 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.

Table listing the negative results on Waterfall and Agile when mixing the two approaches.
When Waterfall and Agile Mix

Agilish from the Start

In government institutions, the shift away from traditional project management to Agile is rarely, if ever, a bottom up initiative.  Most likely, your agency or government client decreed Agile as its preferred or official software “project management” approach.  Such pronouncements usually mark the beginning of Agilish projects.

Agile, and its most popular implementation, Scrum, are not “project management” approaches at all.  Agile is an umbrella term covering multiple approaches (e.g., Scrum, XP, Kanban, Crystal) to building and delivering complex technical systems.  These approaches share the tenets of the Agile Manifesto and its foundational 12 Principles of Agile, which I paraphrase and distill below:

  • Teams develop and deliver system capabilities
    iteratively and incrementally within short timeframes
  • Empowered teams manage their own work and work
    at a sustainable pace
  • The measure of progress is delivery of valuable
    capabilities rather than alignment to plans
  • Direct and ongoing collaboration between and
    among technical, organizational, and customer stakeholders largely replaces
    formal documentation

Agile is a vision for a way of working, not a way of
managing work or workers.  Scrum is a
lightweight framework of roles, rules, and best practices that embody the
tenets of the Agile Manifesto and the principles of Agile.  Characterizing Agile or Scrum, or any other
flavor of Agile, as a “project management methodology” virtually guarantees
Agile adoption failure.

Software Development Has Changed

Most enterprise software solutions are complex systems that change and evolve for as long as they are operational.  Agile and DevOps enable this ongoing evolution by:

  • Decreasing the time it takes to develop, test, and deploy new software capabilities
  • Increasing the frequency of new software capability deployments
  • Automating Operations and Maintenance (O&M) activities

Agile and DevOps allow organizations to move away from deploying
large software releases periodically or infrequently towards continuous flows
of software feature releases.  A strong
DevOps culture fosters:

  • Close collaboration between developers and
    systems operations personnel
  • Automation of system deployment, monitoring,
    alerting, and troubleshooting activities

Agile does away with discrete Waterfall phases for planning,
analysis, design, testing, and deployment followed by a long O&M phase.  All of these activities happen in Agile, but
occur continually and in rapid cycles, thanks to DevOps.  Information and insights gained during these
cycles inform how solutions evolve and how teams improve technical quality and team
processes.

Agile and DevOps open the door to a different way of
working.  DevOps enables software
development teams to deliver increments of valuable functionality sustainably
and when needed rather than on a set schedule.  
As the speed and frequency of releases increase, scheduled project start
and end dates lose their significance.

We move into what some call a “Software Development as a
Service (SDaaS)” model.  Instead of
standing up new projects, agencies augment available software development teams
or form new ones.  The additional
software development capacity adds to the existing software development flows.  Agencies have the choice of adding technical
contributors as agency hires or contractors. 
By treating software development as a service capability, organizations
are able to ramp software development capacity up or down depending on mission
needs and budget constraints.

Conclusion

Acquisition of software systems by the U.S. Federal Government is transitioning from a traditional project management approach to Agile. Over the last five years, the Federal government has enacted significant statutory and policy changes to align acquisitions and contracting processes with Agile and DevOps. Unfortunately, this transition will take time due to the complexity of Federal acquisitions and contracting and the resulting decades-old predictive planning culture.

In the part two of this series, I’ll talk about the reasons why Federal software systems projects become Agilish and the resulting problems. Part three will cover ways to make Agilish projects more Agile.