12 Lean-Agile Portfolio Management Antipatterns: Part 2
In Part 1, we discussed 4 strategic alignment and funding antipatterns that, when resolved, can leave your agile organization in a better position to perform in this age of digital disruption. Here, we focus on the remaining 8 operational antipatterns.
8 A/LPM Operational Antipatterns
Operational Antipatterns
Failing to visualize the portfolio management process (and the work within it)
Failing to limit work-in-progress and queue lengths
Failing to adequately define large initiatives
Failing to quantify 'what success looks like' for large initiatives (by establishing meaningful metrics up front)
Failing to systematically prioritize large initiatives
Failing to decompose large initiatives into meaningful epics and features
Failing to have dedicated resources for product development
Failing to withhold a percentage of program or team capacity as a buffer (i.e., running the team at 100%)
Which results in micromanaging program and/or team backlog prioritization (as a reactionary tactic)
Visualize the Portfolio Management Process (and the Work within It)
Make portfolio management work visible to everyone involved. Taking the time to create a portfolio kanban board that accurately describes the current state of our portfolio management process helps us understand where gaps and blockages exist in those processes. Creating another portfolio kanban board that describes an ideal state will provide a map of where we need to go. Making our portfolio kanban board visible to the rest of the organization will let everyone know how we work and what we are working on, plus it begins to demystify portfolio management for everyone involved. Also, it is much more difficult to ignore something that is readily visible to even the casual passer-by.
Limit Work-In-Progress and Queue Lengths
Modern organizations simply have much more work than they have the capacity to deliver. Prioritization is usually the canned answer to this dilemma, but there are two other answers that are almost universally ignored: limiting work-in-progress (WIP) and queue lengths. The first, ‘limit work-in-progress’, is a technique originating from kanban and lean manufacturing. By adding WIP limits to our portfolio kanban board, we can begin to identify and remove bottlenecks, increasing throughput and the amount of work actually completed. Limiting work-in-progress helps us optimize flow by having us focus on less until those few items are completely finished instead of chronically starting one portfolio initiative after another, diluting our focus and resulting in the delivery of less and less.
The second commonly ignored answer is to ‘limit queue lengths.’ This concept is derived from Little’s Law, which states that the mean response time (W) for an item to pass through a process is equal to the mean number of items in the system (L) divided by the mean processing time (𝛌).
For example, if we have 10 items in a work queue (L) and the average processing time (𝛌) is 1 hour, then the average response time (W) for a new item entering the work queue will be 10/1 or 10 hours. If we double the number of items in the work queue (L) to 20, the wait time (W) likewise doubles to 20 hours!
If you have an organization with 60 major initiatives that each take 3 months to complete, then any new initiative will have to wait 20 months (almost 2 years!) before it is even looked at. The lesson here is to aggressively limit the number of work items you have in any queue. Be ruthless in actively looking for reasons to turn work down. By doing so, you will greatly increase the responsiveness of your portfolio management processes and ensure that your organization is only working on initiatives that are both high priority and tightly aligned with your organization’s goals and strategies.
Define Large Initiatives
New ideas come from all corners of the organization. From hallway conversations to support requests, elevator pitches, and customer complaints, there is rarely a lack of good ideas to transform into meaningful work. Once an idea has been approved for work, it is incumbent on lean/agile portfolio managers to adequately define that idea before it can become meaningful work. This means capturing the intent of the idea, determining how it aligns with overarching business goals and strategies, looking for viable alternatives before committing to development, and determining what is in and out of scope. This is a great deal of work before the work of development ever begins. However, when we take the time to define our initiatives up front, the quality of the resulting downstream product or feature is almost always higher and takes significantly less time to develop. As Abraham Lincoln said, “Give me six hours to chop down a tree and I will spend the first four sharpening the ax.”
Quantify 'What Success Looks Like'
As part of clearly defining portfolio initiatives, we should also take the time to define the metrics that will determine whether the initiative is successful after implementation. These metrics need not already exist; they can be specific to each initiative. However, it is imperative that the metrics we choose are meaningful and quantifiable. For example, if we are implementing a product feature on an ecommerce website with the intent of increasing conversion rates, then we will need conversion rate data from before the implementation of the feature to compare with conversion rate data from after the feature was implemented. If, after taking market rhythms and events into account, the conversion rate increases to or above the established metric target(s) and the cost of implementing the feature is only a fraction of the revenue generated by the feature, then it would be safe to call the initiative a success. However, if the conversion rate does not meet or exceed the target metrics and development costs equal or exceed the cost of implementing the feature, then it would be clear that the initiative was a failure. The more clearly defined the success metrics we have up front, the greater opportunity we have to mitigate the risks associated with an initiative. While we will never be able to eliminate all risk, we can and should clearly define everything we can to expose and mitigate associated risks before development work begins - allowing us to steer our organizations away from unprofitable work.
Systematically Prioritize Large Initiatives
This point seems like a given, but you would be surprised at how many organizations either do not prioritize major initiatives or who do, but only do so based on the highest paid person’s opinion (the HiPPO). The prioritization of major organizational initiatives should be based on quantifiable fact because all human beings suffer from cognitive bias to some degree. Therefore, we need objective criteria, based on our organization’s collective business goals and strategies, that allow us to make informed decisions about the relative importance and economic impact of each initiative in relation to other initiatives. Whether we use a canned prioritization model (like Reinertsen’s WSJF) or we come up with one based on criteria specific to our organization, it is imperative that we sequence initiatives to derive the maximum economic benefit from them. When we fail to do this, we are forced back on our instincts, a non-economic system like FIFO (First-in, First-out) or we defer to the HiPPO in the room. Three tactics that leave us with no real understanding of how one initiative relates to another and what impact it will have on the organization.
Decompose Large Initiatives into Meaningful Epics and Features
After large initiatives have been successfully defined, we still need to break them down into smaller, more meaningful units of work for the teams and teams of teams below the portfolio level. This will include collaboration with and participation from initiative sponsors, architects, product managers and/or product owners. The intent is to decompose the initiative into smaller units that teams and teams of teams downstream can successfully pick up, develop, and deliver. This entails breaking large initiatives into smaller epics and then, in turn, breaking those epics into smaller product features. The paradigm being employed here is Initiative > Epic > Feature > Story. Some large initiatives will require a breakdown like this (others may not). The goal is to decompose the work to such a point that a team or team of teams, working with portfolio managers, can take those epics or features and create actionable user stories for them. Once this has been done, those stories can be estimated, a rolled up estimated level of effort can be defined and the teams and teams of teams downstream can begin sequencing (read prioritizing) those stories for work. Without this collaborative breakdown of initiatives from portfolio management to the individual team level, alignment and shared understanding will be lost at each handoff. However, with this collaborative breakdown, everyone involved will be aligned and share the same understanding of what needs to be built and, more importantly, why.
Having Dedicated Resources for Product Development
Modern waterfall, or sequence-based project management, has long operated on several assumptions that do not necessarily hold true when applied to software development. The first is that projects are temporary efforts. While this often holds true when applied to construction projects, software product development typically remains ongoing throughout the life of a software product. The development of individual product features should absolutely be temporary efforts, but development on the product as a whole remains a constant activity.
Second, teams are formed for and funded by projects. Again, for a client paying for large scale construction this may seem true. But even contractors have dedicated teams that stay together and move from one construction project to another. There is an abundance of research that repeatedly proves that teams that stay together tend to become better over time. If software product development is a continuous activity throughout the life of the software product, then would it not make sense for the team or teams developing that software product to stay together as well? If each product feature is treated as a distinct ‘project’ necessitating the formation and eventual dissolution of a new team, wouldn’t that imply that we are losing valuable time and knowledge to team formation and reformation based on a project funding model that simply does not fit modern software product development?
Lastly, organizations that operate on the project-based model break those projects into distinct phases and then attempt to sequence those component phases through skill-specific teams in such a way as to prevent any one skill-specific team from going idle. This results in development teams being 35% ‘dedicated’ to Project A, 45% ‘dedicated’ to Project B, and 30% ‘dedicated’ to Project C (the number need not add up to just 100% in the modern enterprise environment). This behavior necessitates context switching which research has shown to slow down completion and delivery of work.
All of this boils down to one simple point: before we waste time defining and sequencing and decomposing large initiatives, we need to know that we have (or will have) dedicated product development teams downstream to complete and deliver this work. Without those downstream development teams, it doesn’t matter how good we are at portfolio management as any ready initiatives will simply sit idle until they can be picked up by one or more product development teams. Make sure your work has somewhere to go before wasting effort defining it.
Withhold a Percentage of Program or Team Capacity as a Buffer
While this particular behavior doesn’t exactly fall into the realm of portfolio management, it is a behavior that can be driven by portfolio management. It is a common antipattern to consume all of a development team’s or program’s capacity, especially with new features. However, doing so ensures that there is no buffer with which to handle unexpected work, like critical production issues. If a team has an average velocity of 24 or a program an average velocity of 120, it is extremely foolish to consume all of that velocity, dedicating it to new feature development if there is even the slightest possibility of production issues arising. If velocity is consumed in its entirety and unplanned work does happen, then some other work must be deprioritized, prompting ad hoc meetings and a flurry of largely reactionary activity. It is no difficult task to find a team or program who has had their sprint or program increment forced into reactionary chaos due to unplanned work in the absence of any spare capacity. However, if portfolio management sets the expectation that a certain small percentage (10, 15, or perhaps even 20%) of team or program velocity be withheld specifically to address unplanned work, then there are no ad hoc meetings to discuss how to bring that work into an already dedicated team. Each team or program can simply use the buffer at their discretion to handle unplanned work. When no unplanned work arises, teams can simply pull in work from the top of their backlogs, but this expectation must come from the top of the organization and be applied wisely at every level downstream.
———
If you noticed some SAFe concepts and terminology above, don’t be alarmed! Michael Miller is a certified Scaled Agile Framework Program Consultant (SPC) and draws heavily on the framework in his day-to-day work as an Enterprise Agile Coach. If you have an interest in learning more about Lean/Agile Portfolio Management or certification as a SAFe Lean Portfolio Manager, please feel free to reach out to him at mmiller@clearlyagileinc.com. Thank you!