Search Results

In my experience assisting organizations with portfolio operations, a prevalent belief is that the key to solving workload issues is simply adding more staff. It's an intuitive reaction: too much work, not enough hands. But is this the real solution, or are we missing a fundamental piece of the puzzle? Many organizations, when faced with overwhelming workloads, instinctively look to quantify the additional headcount needed to meet their goals. This often leads to a perceived need for a significant increase in staff – sometimes as much as 30% more – a figure usually beyond the current budget's reach. However, even if the budget permitted such an expansion, the slow process of onboarding new employees suggests a different question: Are we maximizing our current capacity effectively? This requires a deeper investigation into our habitual approach to workload management. Through my observations, two primary issues frequently emerge in organizations: Excessive Approval of Work: Approving too much work at the portfolio level leads to missed commitments, slow delivery, and a diverted focus from the desired outcomes. Misguided Focus on People Management: Organizations often concentrate more on managing people rather than optimizing the system of delivery. ⠀To highlight and begin to address these issues, I recommend two simple yet revealing exercises: Demand vs. Capacity Analysis: Determine the demand by listing current portfolio initiatives and estimating the remaining work required. Assess the available capacity by calculating the actual time team members can dedicate to these initiatives. Compare the demand with the capacity to gauge whether the workload is realistically manageable. Throughput Analysis of Initiatives: Track the number of completed initiatives within a certain timeframe. Use this data to forecast the time required to clear the existing backlog of initiatives. At one organization, these analyses led to the startling revelation that, despite having adequate staffing, the backlog of work would take over two years to complete. This prompted the VP of portfolio management to acknowledge a crucial problem: poor execution. Further analysis highlighted several areas of concern: Misalignment on priorities. Lack of a unified view of the value delivery process. Frequent interruptions and shifts in priorities. Excessive ongoing work causing additional interruptions. Dependencies across various organizational units hindering smooth delivery. A reactive rather than proactive approach to planning. High staff turnover impacting consistent delivery. These tools – demand vs. capacity and initiative throughput – are straightforward methods to challenge the perceived need for more staff. They are simple and fast, often requiring no more than a couple of hours with the right people to generate the data. They facilitate constructive discussions about focusing on crucial initiatives, making informed decisions on future approvals, and improving current delivery practices. Ultimately, the goal shifts from "how do we get more people?" to "how do we effectively utilize our current capacity to focus on what's most important?" If you're interested in applying these methods to your organization's challenges, feel free to reach out for a deeper discussion on their practical implementation.

I see many questioning the value of PI Planning. As you weigh up options: a) avoid repeating the mistakes of the past; b) understand the benefits beyond "doing SAFe". Scaled Agile coined the term PI Planning but the practice predates SAFe. What are the benefits? Aligning on Objectives We need time to align on the journey ahead and what to expect. Regardless of how good an idea is, without giving people time to prepare, you invite failure. We used to see this with Scrum teams. The Product Owner would show up for Sprint Planning with new stories and expect a team commitment. The results were predictable. Balancing Capacity with Demand Setting expectations are healthy and natural. However, we know what happens when expectations exceed our capacity to deliver. Without input and consideration from those doing the work, we can’t set realistic expectations. Reduce Value-Stream Delays When we build large systems, the scale of the effort requires multiple teams. Collaborating teams need to ensure that dependencies are discussed and deliveries are synchronized to avoid lengthy value-stream delays. Done well, PI Planning will help you realize the benefits above. Yet, many fail. What are some of the common culprits? Not an Agile Release Train Do you have many teams that need to collaborate or do you just have many teams? Forcing people to collaborate who have no interest in each other is a recipe for disaster. If your teams are loosely coupled, bring them together for sharing and visioning but they will not need the full PI Planning experience. Value Stream Delays PI Planning causes a bottleneck as features wait to be pulled. One cause is loading teams to full capacity with no room for emergent work. This lack of agility incurs a cost of delay. We must build slack into our plans so that we can respond to change. Alternatively we can move more towards continuous planning where features flow continuously through the system. Emergent Work Dominates With innovative work, learning is fast and the landscape constantly changing. Similarly with production support the work will be uncertain. If you can't predict the next quarter how can you do PI Planning? You can’t. Failure to Collaborate PI Planning is a time for alignment. Constructive conflict and learning are essential. Often, PI Planning becomes a mere stuffing of team backlogs. Little discussion is given to capacity or if we are doing the right thing. One root cause is over-preparation. The event becomes a mere blessing of a plan created previously. Another root cause is that many teams are pressured to say yes regardless of whether it makes sense or not. If one of the first three scenarios apply you may not be a fit for PI Planning but you should find ways to come together and: a) agree on shared objectives; b) discuss how you can improve. However, if your PI Planning is coercive not collaborative, then PI Planning is not the problem, PI Planning has uncovered the problem.

(WARNING: This one is a bit longer than expected - probably could do with a refactor🙄) Traditionally when we plan work for Portfolios of Projects we will pull together a detailed resource plan of our people with the idea being that we can predict how people will work to deliver Projects. They use this information to: Develop and work a plan: To understand how we might schedule the work of the effort out to ensure success Estimate cost: To help determine how much the effort will cost us, at least from the perspective of people cost People and skills: Understand whether we have the people and skills available to get the project done In order to ensure that we have the best use of our people (that they are being well or fully utilized) we treat people as “full time equivalents” (or FTEs) and then allocate them to work on Projects so that, for example, a person is allocated 25% to one Project, 30% to another, and the remainder (to 100%) to a third Project. Lean-agile implementations take a different approach. Rather than focus on the resources, they optimize the flow of business value by implementing a “pull” based system. We assume that we have a fixed capacity machine organized as stable teams to do work and that most of the time we have the right kind of people to get the work done (after all we have been getting work done up to now). The main issue we need to work is to ensure that our people are working on the most important things. We therefore prioritize the efforts on and pull work to the Teams on a regular cadence so we maximize value delivery for the capacity we have. We then make adjustments on this cadence as things change. A lot of organizations still require the Portfolio planning approach to work FTE based resource planning as part of the approval process. For those organization we need to understand under what kind of circumstances this kind of planning is effective both from the perspective of the results it produces, and in terms of being able to provide answers to the questions. Lets start with: Develop and work a plan Let’s start with is this effective in terms of results - does the plan actually work? My experience is that this kind of planning is not effective except for the smallest of Projects, where there is a huge amount of existing experience, and where the Projects are independent from other Projects. For anything more than this it doesn’t work on a couple of levels: From an individual perspective, the people doing the work have a tough time working the way the plan implies From a systems perspective, it is impossible to deal the impact of changes that happen From an individual perspective, I want you to put yourself in the position of the person that has been assigned to work 25% on one Project 1, 30% on Project 2, and the remainder (to 100%) on Project 3. The problem is that we are putting this person in a pretty difficult situation. Firstly, the reality is that this person doesn’t actually have 100% of her capacity available to do work. You lose capacity as you switch from one type of work to another. For 3 Projects, the drop in capacity is typically around 40% leaving an actual capacity of the person to be 60% of the total (See What is the Impact of Context Switching on the Ability to Deliver? for more on this). If there were a fourth project another 20% would be lost. The problem is that there is always other work coming in - the production support issue, the meeting we need to attend, … The capacity plan we have developed is pretty much dead on arrival. Even is the plan is actually executed as we planned there would still be problems. From the person’s perspective, they are juggling 3 backlogs and need to decide which Project is to get their attention right now. They do this from their perspective and understanding, which typically does not have a wide enough context to do what in the end is best for the business. My experience is that people do not think in terms of allocating their time 25% to this project, 30% to another, even with the most detailed schedule for their work. They will work on a particular project for a time until they have completed something or are blocked by something and then move on. At the end of the week they will look back and guess how much they worked on each project, and then adjust those guesses based on expectations from management (“you can’t charge to Project X …”). Bottom line is that my experience has been that our developers, QA, etc. do not really operate per the plan anyway - the plan will be impacted by local decision making. From the system perspective, the issue is different - it’s just too hard to plan out all the changes that need to be addressed as a result of change. It is possible to successfully use this approach to plan for our people’s work for simple efforts and a small number of people. However it quickly becomes impossible to use this approach as the number of Projects increases and as the number of interactions that can occur between Projects between increases. The reason this happens is that, while we might start off with a plan that seems reasonable, as we execute the plan it will be impacted by random events (e.g. “system is down!”) which change the interactions between people working the project, interactions between people and the technology and systems they are working with, and the overlapping relationships between this project and all the other projects, with their people, technology, and systems. For example, say one person, a developer, has to take a day off because they are sick. The developer was going to work on Project 1 with her 25% allocation to that project. In the simplest case this will impact the next person that is waiting on their Project 1 output so they can do their work, say a QA person who was expecting to use some of their 10% capacity allocated to this Project 1. The QA person realizes that the developer is not going get that work done, and so decides to work on Project 2 instead, another part of their allocation. However this decision has at least two impacts 1) anyone waiting on Project 1 work from the QA person 2) anyone how is now expected to respond to the change as a result of the QA’s decision to work on Project 2. And so on. And so on. And so on. The result is that this one change in the plan has a potentially huge ripple effect not just through one Project, but potentially impacting multiple Projects. And this is just one random event. By building a plan with FTE’s we have actually created a whole series of dependencies between Projects whether there are other more direct dependencies between those Projects or not. In this network of people doing projects, how many random events are there - from the large such as “The competitor has released a product that makes this work obsolete” to smaller events such as “Having seen the result, that’s not what I need…”, “You need to work this production issue!”, “Management has scheduled a meeting with …”, “We have a new person we need to onboard.”, “The test environment is not available”, etc. Change is in fact the norm. There are a lot of potential interactions that could result from a change. As a result the impact on your future plan is simply unknowable. To give you a flavor of the number of potential interactions between people: The chart says that if we have 10 people, then the number of potential direct and related interactions is 35 trillion. Wow. In reality, the situation is probably not as extreme as this level of interdependency indicates. We do not expect to have everyone working with everyone else. Rather we work to isolate dependencies by having people focus in particular business areas or technologies for example. Further, not all people will have the same impact. Some people will see a change, and manage it themselves, and that change will have limited “blast radius”. To me the real impact of this chart is how big the numbers of potential interactions become even for small numbers of people. In my experience, the burden of FTE type thinking typically falls on the people that we regard as experts, as critical. We have a tendency to put more onto these people which creates a huge dependency for all projects (the “Brent” problem from the book the “Phoenix Project”). These are also the people we want to leverage when we have a problem and so they are more likely to be impacted by random events. Let’s say there are 10 of these folks so the number of potential interactions, the ripple effect, is around 35 trillion. So when something impacts those key people the ripple effects are potentially dramatic. And with these numbers you can see why it is impossible to predict what might happen as part of a re-planning exercise. While it is comfortable to think that we can plan this upfront, this turns out to be wishful thinking. There are just too many potential changes and ripple effects to really ensure we will be able to deal with changes in our system. Sadly, looking back on the project we will be able to pinpoint the problem and even have a discussion about what we should have done differently. Unfortunately, this will only reinforce the idea that we can be deterministic in our planning process - “If we only had analyzed this more!”. In fact we know something now only with the benefit of hindsight because, rather than dealing with 35 trillion possibilities, we can see the actual possibility that happened - this would have been impossible to determine this at the time of the change. Estimate cost There is no doubt that using the FTE type approach will allow us to develop an estimate for the effort. In many ways this is seen as a requirement for portfolio planning. We need to know the cost in order to ensure that when we work on the item we have a positive business outcome - a return on this investment if you like. Like all estimates, the use of FTE type thinking is a guess. We might think that we have a “good” guess because in going through the process of determining the FTE plan we’ve probably also thought a little about how we are going to get it done (architecture and design work) as well as the steps required to get something done (FTE scheduling). From the planning discussion above we can see that this level of “additional” detail is actually not going to improve the estimate much as the bigger impact on the plan is change. In fact it is even worse than that in that the process gives us a false sense of security. Let’s face it, the time when we are pulling these estimates together is the time when we know the least about whatever it is we are doing. We generate additional documentation, but the reality is that we have not delivered anything the customer, or the business, cares about - (part of) a working system - and so don’t actually know what the rate of progress will be. It is only when we start delivering real functionality that we can understand what the likely progress of the work is. This is not to say we should not provide estimates. Prudent business decisions are based on understanding some view of the potential cost and potential outcome. But there are quicker and cheaper ways to get at cost (such as using relative sizing with the historical throughput) without the overhead of building a plan that won’t be followed. In addition, with lean-agile approaches we will review the information we have on a cadence and, based on what we are seeing, make a call for the best use of our scarce capacity right now, updating the financial data as we go based on what we are seeing. In other words we replace upfront approval process and plan with an incremental funding approach which optimizes our delivery of value. People and skills The FTE process usually incorporates a view of the skills we need for a project. It might say things like “we need a JDE developer, a QA person, etc.” The thinking is that using this information we can start having discussions about whether we have the skills we need and whether we have enough people to get the work done. One downside of this approach is that the natural discussion will always be “we need more people”. The reality is that there is always more demand on the system (more requests) than can be possibly handled. Typically this results in a constant feeling that we are understaffed. But it should be noted that we are only understaffed in comparison to the budget we currently have. The real discussion we need to have is whether it is worthwhile to bring in additional people in the light of the amount we have budgeted from an overall business perspective. Lean-agile takes a slightly different approach. At the broad level of portfolio planning, we can be pretty sure we have people with the skills that we need to do the work we need. We know this as we have a history of delivering the work. The lean-agile approach takes that work and prioritizes it, force ranking every effort (usually within specific domains). Based on historical data we know how much we have been traditionally been able to complete per unit time. We can leverage this to determine the cut-line of the work, above which it will probably be done, below which we cannot start right now. Looking at the Initiatives below the cut-line will allow us to have a focused discussion about whether it is a good business decision to bring more people in to address some of these initiatives. There is an additional discussion about skills. In general the organization has the skills it needs to get the work done in the organization. If we find ourselves with too few of a particular skills we can leverage the organization to teach others within the organization the skills that are required. In general the 80-20 rule applies here - you can teach someone to support 80% what they deliver very quickly with the remaining 20% requiring more experienced involvement. For example, one place I worked, we did not have enough QA for the amount of work. We put a plan in place to bring in more QA, but realizing that this would take some time (and be potentially disruptive) we had our QA folks work with our development folks to better test their efforts - think like a QA person. Sure, the first use of people in this skill area might be slower, but this approach is less disruptive than bringing in new people to get the work done, and you end up with a more resilient organization, able to take anything on. The place where we could anticipate a skills mismatch is when we are contemplating an Initiative that is in a totally new domain or uses a totally new technology. If you are unable to leverage internal people to grown their skills, learning, then we might chose to bring in additional experts. From a lean-agile perspective the mechanism exists to address this. Since we are planning and implementing on a cadence (say quarterly PI), if we discover this need we raise the need as part of the process to get ready for the next PI and work to bring in the required skills on the cadence. This has the additional benefit of reducing disruption. There we have it. In answer to the question “Under what conditions is Full-Time Equivalent (FTE) resource planning effective?” and related questions about planning, estimating costs, and people and skills, for any organization of sufficient size the answer is “you aren’t going to need it” at best and “you are doing activities that are wasteful” at worst. That said, many organizations do not trust that this is possible and so set up an experiment to run both approaches in parallel for a while. While this is wasteful (you are using two different approaches to the same questions), and will slow down decision making (building the FTE plan takes time) and hence time to market, this might be the easiest way to get to comfortable with the lean-agile approach.

In the past, the idea that the “leader decides” mode of decision making seemed to work well for Portfolio level decisions. However in today’s world this approach is less effective. Today’s world is getting more and more complex. The traditional tools we use for decision making are increasingly not effective in this complex world. Many organizations realize that the old approaches don’t work, that more perspectives are required, and so put in place increasingly complicated processes to ensure that they pull together all the information required to make a decision. One place I worked put in place a 12-step process “portfolio initiative approval workflow” each with multiple sub-workflows supported by a tool where each person in that workflow was assigned “work” as part of the decision process which then moved on to the next step, and so on. The problem with this approach is there is still no total understanding or alignment on the decisions as each discipline is treated as an independent silo. Worse since it is a serial workflow, it takes a long time for any decision to go through the system (in this case, the decision to do something often took longer than the process of implementation) which reduces our ability to respond to change. Lean and agile approaches encourage collaboration to address problems with more traditional approaches to decision making. Collaboration: Ensures that we hear all the aspects of a subject we are making a decision on through direct involvement from all the different disciplines involved and so become aware not only of what we are intending, but also potential constraints and risks, and even contrary viewpoints. Ensures we have an aligned view of the subject as a result of modifying what we thought based on the other sources of information. People come into the discussion with their viewpoint on a specific decision, but as a result of collaboration they end up with an aligned view Helps us to overcome our personal biases when making decisions. (See https://www.hanssamios.com/dokuwiki/what_inbuilt_biases_do_we_have_that_impede_good_decision_making for some ideas on this.) Creates a “better” decision by leveraging everyone’s perspective and working together toward the decision. Often I am surprised by the decision a team of people comes up with in that I have to acknowledge that the final decision was better than mine when I work collaboratively I have found that I will often not know who had the “better” idea as it emerges from the discussion - people pinging off each other. “Diversity trumps ability” - Scott Page Usually means a faster decision. This drive for collaboration does not mean that we do not make decisions, or that decisions will necessarily take a long time. The point of getting everyone together on a decision is to ensure we hear everyone and then decide. There may be preparation work required before getting to this nexus, but the overall process should be very quick. It is especially quick when you compare it to the serial “process” approach described above, or when you think about how many meetings you would have to schedule to get to a specific decision on something (setup meeting, missed a key person, setup next meeting, need more data, setup next meeting, …, revisit decision, …) All this collaboration can sound a little “namby-pamby”. There is no doubt the approach will improve decision making. But if the decision is not supported by execution, then we might as well not have bothered. Once we have made a decision we need to support that decision with a working agreement from all those involved. The working agreement is: “Disagree and commit” - Various attributions In other words, once we have made a decision, all the people involved in that decision commit to doing what is required to execute, even if the decision was not what they wanted. We cannot get the benefit of the decision if some people do not support the execution because “well, I didn’t want to do it that way”. Further, the working agreement is that we will continue this level of execution until a new, joint decision is made. While the context of this discussion is Portfolio and Program Management, the reality is that this discussion holds true for all levels of an organization, teams to executive - collaboration amongst diverse opinions improves decision making in complex environments. This does not mean all decisions are made this way. If the problem you are dealing with is pretty clear, apply the best practice and get on with it. If the problem you are dealing seems to be chaotic, then just make a call (do something, anything) so you can understand better what you need to do. Or sometimes, someone has just decided, and we just need to get on with it. The purpose of this discussion is to recognize our world is increasingly complex, and that we should use decision making approaches have the potential to offer better outcomes where that makes sense. And while it might be implied in the discussion above, it should be noted that the benefits of collaboration also apply to work products. For example, this is the reason we work with teams when we are working business cases at the portfolio level, all the way to user story definition for teams. This is why “pair programming” is more effective than a single developer working something. This is the reason most effective coaches like to pair with other coaches and other interested parties when developing new materials, courses, etc. “Diversity trumps ability” in our increasingly complex world.

When organizations meet resistance all too often, they focus on adding fuel they don't ask how they can subtract friction. As I was observing a large team of teams progress through planning it became apparent that demand for functionality far exceeded the capacity of the available humans. Bob proclaimed that budget was not an issue "just tell me how many developers you need, and I will get the funding". I tried coaching Bob that uncovering and eliminating waste in his backlog would enable him to get everything done. But, the pull of the past was just too strong. The first instinct of Bob and many in leadership when faced with a challenge is to push harder by adding carrots or sticks. Instead of looking for ways to decrease friction and reduce the payload, they add more fuel to the rocket ship. This was the key message from Loran Nordgren in his interview with Shankar Vedantam on Hidden Brain 2.0. Nordgren shared that frictions tend to be buried and require discovery. We often have to shift attention from the challenge itself, which is our natural point of fixation. Friction requires knowing our audience and knowing the context. In product development, friction comes in many forms such as excessive handoffs, bottlenecks or over-production. Unlike Bob, budget was an issue for Melissa, she couldn't add more fuel. When the development team told Melissa that everything she was asking for would take 8 years rather than the 15 months she hoped, her only option was to find and remove friction. What transpired was a remarkable piece of teamwork and one of my best days as a coach. Melissa and the development team took a hard look at the feature backlog. By ruthlessly eliminating any functionality not adding customer value, they were able to shrink the timeline from 8 years to 13 months. The contrast between Bob and Melissa is stark. Bob added fuel. Melissa reduced the payload. Melissa discovered that often a better more sustainable approach is to first uncover and reduce friction.

How you conduct Planning Increment (PI) Execution meetings can drastically affect your organization's productivity and employee satisfaction. It's the pulse of your group's collective effort, keeping stakeholders informed and decisions on track. However, for many organizations, these meetings have become a rote recitation of status updates, leaving participants feeling disengaged and the actual value of the conversation untapped. Let's explore how you can revitalize your PI Execution Meetings, transforming them from monotone information caterers to vibrant, problem-solving hubs that boost transparency, active involvement, and continuous improvement. The purpose of a PI Execution meeting is to share progress on the current increment with stakeholders, understand the current reality, and respond to changes. It covers updates toward shared goals, work status, team velocity, and potential changes in scope, and forecasts completion timelines. It also provides a forum for decision-making, sharing lessons learned, and recognizing team contributions, all to promote transparency and continuous improvement. There are several key topics to consider as part of structuring a PI Execution Meeting: 1) Progress Against PI Goals or Objectives: What progress have teams made towards each goal or objective for this PI? What have the teams achieved so far in terms of results and outcomes? Highlight the work that teams have completed, is still in progress, or has yet to start. Progress may include the completed Epics, Features, Stories (e.g., burndown or burnup chart, %), and other things like quality and technical debt work. 2) Velocity and Capacity: How much work is the team completing in each Sprint or iteration within the PI? Is the team’s velocity in line with the capacity planned at the beginning of the PI? (e.g., perhaps there was an unexpected change to team velocity) 3) Capacity Allocation Balancing: Are the teams maintaining a balanced distribution of effort across various work categories such as new features, bug fixes, technical debt, and innovation initiatives? Discuss how the teams manage their workload and the potential adjustments necessary to ensure optimal balance. 4) Changes or Scope Churn: Highlight any changes made to the plan since the last update due to changes in priorities, additional work discovered, scope creep, or other reasons. 5) Blockers and Risks: Identify any obstacles that are currently hindering progress, potential risks that might cause problems, and plans to address or mitigate them 6) Quality and Health Metrics: Share any relevant metrics about the quality of the work being done, such as the number of bugs reported, escapes, test coverage, KPIs, team morale, or customer satisfaction scores. 7) Forecast for PI Completion: Based on the progress and velocity so far, what is the forecast for completing the remaining work in the PI? Analyze the team throughput and make a forecast for what may not be delivered by the end of the PI. 8) Decisions Needed to Respond to Change: Highlight any areas where decisions are needed that could affect the priorities or scope of the PI. Consider including decisions related to strategic shifts, resource allocation, or scope changes due to unexpected complexities or dependencies. 9) Lessons Learned and Improvements: Briefly touch upon any key learnings the team has had during the PI or any improvements they have made or plan to make in their processes 10) Recognitions and Success Stories: Celebrate success stories and individuals to boost morale and motivation. Think about recognizing individuals who have made significant contributions, teams who have collaborated effectively, or any other noteworthy efforts or successes In addition to these options, I’d like to provide a little caution and perhaps plant some ideas for future improvements. Early attempts with a PI Execution Meeting structure have stakeholders and team members walking through a litany of status updates. Some updates are essential, while others are less so, which consumes valuable time and energy that people could better spend to address critical issues and formulate countermeasures. One of the foundational principles of Lean is to create value and minimize waste. In the context of meetings, what do stakeholders consider as value-added? Stakeholders spend large parts of these meetings getting updated on progress. But most workflow management tools can provide stakeholders with an intuitive, real-time view of progress at their convenience. Everyone should already have the status they need before starting a meeting. This behavior opens the opportunity to use the meeting time for value-added topics. As organizations reflect and improve their meetings and workflow management, PI Execution Meetings should evolve toward becoming a forum where participants collectively understand what’s happening, make sense of the opportunities and challenges, brainstorm potential countermeasures, and agree on a shared path forward. Instead of a one-way update monologue, the meeting becomes more engaging and interactive, promoting active involvement from all attendees. Here’s a description of how organizations transition toward a better PI Execution Meeting over time as they learn and improve their meeting structure, collective behaviors, and workflow management systems. Phase 1: Information Caterer In the first phase, one or more people gather updates from the team and compile them into a presentation for the stakeholders. The meeting is primarily a one-way conversation, with the presenter walking through the updates and stakeholders passively receiving information. While organized and straightforward, catering status updates on a silver platter often need more real-time engagement and can be time-consuming for the presenter(s). As organizations realize the limitations of this method, they begin to look for ways to automate the update collection process and improve stakeholder engagement. Phase 2: Dashboard Dancer With automation and data discipline, real-time dashboards and reports in workflow management tools replace manual presentations. An expert user guides stakeholders through these visuals during the meeting. This approach saves time in compiling updates, provides real-time data, and starts to facilitate more discussion around the status. This phase still has its challenges, as not all stakeholders may find the visuals intuitive or easy to understand, and the meeting can still be one-sided if the expert user does most of the talking. Phase 3: Conversation Catalyst Like the flipped classroom model in education, stakeholders review status updates offline before the meeting. The meeting purpose shifts to collaborative discussion and decision-making, which is a valuable use of time. In this phase, meetings become interactive and engaging, and stakeholders feel more ownership and involvement. More ownership and responsibility improve the speed and quality of decision-making, autonomy, and morale. This phase requires stakeholders to change their habits and expectations, which can be challenging. Organizations must ensure that dashboards and reports are easily accessible and intuitively understandable for stakeholders. A culture of preparation and active meeting participation also needs to be cultivated. Call to Action The evolution of the PI Execution Meeting structure is a journey that requires iterative learning, improvements, and adjustments to an organization’s collective behaviors and workflow management systems. The journey is about curating a collection of heuristics for improvement, not a one-size-fits-all approach. The key lies in understanding that the journey isn’t just about better status updates. It’s about shifting from passive status consumption to active engagement and decision-making. Your call to action is to start reflecting on the purpose of your PI Execution Meetings and how they are structured and facilitated. Begin by asking the fundamental questions: How are these meetings adding value? How can you eliminate waste and make them more efficient? How can you facilitate more engagement and problem-solving? Start with the “Information Caterer” if needed, but don’t get stuck there. Strive to become a “Dashboard Dancer,” then work towards the “Conversation Catalyst.” Improving a PI Execution Meeting is challenging and requires all team members’ time, patience, and concerted effort. However, the rewards – improved collaboration, quicker decision-making, better use of time, and ultimately, increased productivity and product quality – are well worth the effort. Every step you take is a step towards creating a culture of transparency, continuous improvement, and collective problem-solving, which are the hallmarks of a learning organization. Related Recommendations: Lencioni, Patrick. Death by Meeting: A Leadership Fable...About Solving the Most Painful Problem in Business, 2004. Kaner, Sam. Facilitator's Guide to Participatory Decision-Making, 2014.

We can learn a lot about the Agile Coaching market from Olive Oil? Let me share a story. I was in a very large store looking for olive oil. It's wonderful that our diet has improved so much over the last few decades but, the choice is overwhelming. Narrowing my options to first cold-pressed still left me a multitude of options. I googled for "best olive oil", it didn't help much. I couldn't spend all day, I eventually grabbed a popular brand that I'd used in the past. I'm sure there were tastier choices but good enough for my pizza dough. A few weeks later, we were visiting Breckenridge, Colorado. While I was a few thousand feet higher being thoroughly humbled by my lack of skiing prowess, my wife was exploring the town. She found a small specialty store called Olive Fusion that really merits a plug here because their olive oil was delicious. I don't know if it was cold-pressed but I was glad we picked some up. Although Olive Fusion can't compete with the supermarkets for price and options they obviously really know their craft. If the result of value is taste, they delivered. As I was researching for this opinion piece and pondering whether my analog between Agile coaching and buying olive oil experience would resonate, I found this quote: There’s a big problem with olive oil: Real olive oil is far more costly than other vegetable oils, so you can make a lot of money by slipping in cheaper oils.

Since we reduced our workforce last year, one surprising result is that many things have gone faster. In retrospect, I underestimated the indirect costs of lower-priority projects. – Zuckerberg, Meta’s Year of Efficiency, March 14, 2023 TL:DR Meta’s Year of Efficiency (1) focuses on improving organizational efficiency and financial performance in a challenging environment. In the coming months, Meta plans to flatten org structures, cancel low-priority projects, reduce its workforce, and slow hiring rates. From my perspective as a Lean and Agile coach, Zuckerberg’s statement evokes mixed feelings. On the one hand, I appreciate his recognition of the potential pitfalls of overstaffing and working on too many lower-priority projects. On the other hand, I am disheartened when leaders pursue strategies that result in suboptimal financial outcomes and subsequently resort to large-scale layoffs to rectify the situation. The “Surprising” Benefits of Limiting Work-In-Progress Lean and Agile practitioners may recognize Zuckerberg’s statement as a real-world example of Little’s Law at work with the associated benefits of limiting work-in-progress (WIP). Little's Law is a fundamental equation in queueing theory that states the average number of items in a system (L) is equal to the arrival rate of items (λ) multiplied by the average time each item spends in the system (W), expressed as L = λ x W A reworked version of this equation in terms of WIP, cycle time (the average time an item spends in the system), and throughput (the item completion rate) or WIP = Throughput × Cycle Time By lowering work-in-progress (WIP) while maintaining constant throughput, the average time each item spends in the system (cycle time) typically decreases. When Meta reduced the number of projects and kept their throughput steady, their delivery rate improved. Even if their overall throughput decreased due to layoffs, if the percentage reduction in WIP was more significant, a reduction in cycle time would still be expected. Company leaders at every level avoid surprise and instead carefully consider the important tradeoffs between WIP, throughput, and cycle time for their teams. Lack of Respect for People It deeply saddens me when leadership teams resort to mass layoffs as their primary countermeasure for addressing a company's financial troubles, especially when these issues stem from the leadership’s own misguided strategy and poor decision-making. It begs the question: why don't leaders embrace alternative approaches, such as natural attrition, hiring freezes, retraining, bonus and salary reductions, or accepting lower profit margins before choosing to upend the lives of laid-off employees? "Respect for People" is one of the foundational principles of Lean Thinking. (2) This concept emphasizes cultivating a culture that values every individual, encourages empowerment, and nurtures the growth and well-being of employees and stakeholders alike. Let's briefly explore the different aspects of this principle to provide additional context and reduce ambiguity: Valuing employees: Company success is built upon the collective skills, knowledge, and efforts of its people. By treating employees with dignity, respect, and fairness, the company creates an environment where individuals feel valued and motivated to contribute their best work. Empowering employees: Employees engage in problem-solving at all levels of the organization. By providing the necessary training and tools, the company empowers employees to identify and address issues, promoting continuous improvement and innovation. Developing people: Leaders are committed to the personal and professional growth of employees, investing in their development through ongoing training and mentorship. This focus on human development not only benefits individual employees but also strengthens the overall organization. Respect for stakeholders: Respect for People extends beyond employees, to include customers, suppliers, and communities in which the company operates. The company strives to build strong relationships and act as a responsible corporate citizen, contributing to the betterment of society as a whole. Mass layoffs are clearly at odds with the Respect for People principle, as layoffs erode trust, undermine employee morale, and disrupt workplace culture. Such actions suggest that an organization places a higher priority on short-term financial gains rather than fostering long-term investment in its people and their development. In stark contrast, Toyota is a company renowned for its unwavering commitment to treating employees with respect, striving to retain and retrain them rather than resorting to layoffs. Even during the 2008-2009 global financial crisis, Toyota refrained from laying off full-time employees, despite facing significant financial challenges. The company instead implemented cost-cutting measures, reduced working hours, and retrained employees for different roles. However, it is important to note that Toyota's dedication to avoiding layoffs primarily extends to full-time employees, with temporary workers and contract employees receiving less job security. Sword of Damocles Mass layoffs combined with a disregard for Respect for People have far-reaching and subtle consequences that extend well beyond short-term financial gains. The Sword of Damocles is an ancient Greek parable that tells the story of Damocles, a courtier who envied the power and wealth of his ruler, Dionysius. Dionysius offered Damocles the chance to experience his life as a ruler, but with a catch: a sword hung by a single horsehair above Damocles' head, symbolizing the constant threat and uncertainty that comes with power. Mass layoffs and their lingering effects on company culture are like the Sword of Damocles, as they create a climate of fear, uncertainty, self-centeredness, and mistrust that can have far-reaching consequences for the organization's success and long-term stability. This pervasive sense of vulnerability and even dread results in diminished morale, decreased productivity, eroded trust between employees and management, increased unwanted attrition, and subpar team performance. Mass layoffs also lead to the troubling consequence of “silent quitting” where remaining employees mentally and emotionally limit their engagement with work. Disheartened employees may attend work meetings and complete their tasks, but they limit their discretionary effort, and enthusiasm, and don’t go above and beyond for their role, team, or organization. The negative effects of mass layoffs linger with the employees that remain. Rebuilding trust requires consistent efforts from the company's leadership to demonstrate commitment to employee well-being, transparency, and stable financial health. Advice for Company Leadership To avoid resorting to mass layoffs, company leadership should consider implementing these sensible strategies that, while common sense, are often not widely applied: Reserve funds to support employee payroll during challenging times Be cautious about overhiring; carefully staff medium and low-priority projects and products Prioritize employee retention, retraining, and repurposing for roles with higher value instead of resorting to layoffs Leverage natural attrition, implement hiring freezes, reduce bonuses, incentivize early retirement, cut salaries and overtime, and curtail discretionary spending Accept responsibility AND the associated consequences for short-term financial difficulties and take a disproportionate hit to executive compensation If leadership teams have not thought through these considerations, perhaps it’s time to start. What are the right levels of financial reserves? How would we know if we were overhiring? Do we have the systems in place to retain, retrain, and repurpose talent from low to high-priority work? Advice for Employees Employees must prioritize their own well-being and career development. Loyalty is often a one-way street, with individuals being more loyal to companies than companies are to them. People can be loyal, but companies rarely are. During my early career, I worked in the highly-cyclical semiconductor industry for Intel Corporation. Amid the Dot-com bubble bust, one of the guiding pieces of advice employees shared with coworkers was to "stay close to the wafers." Semiconductors are produced on silicon wafers, which are Intel’s core products. “Staying close to the wafers” implied that if your role did not directly contribute to the company's core products or value streams, then there was less job security than a position more directly connected to the core business. For instance, it was more advantageous to work in a support organization for a core process than in a secondary support organization (i.e. a support team for another support team). If your team is two or more steps removed from the core business or if your team is working on a highly speculative initiative, then consider making a move closer to the core. "You own your own employability" was another concept widely advocated across Intel. This means that individuals need to take responsibility for their career development and job security. Employees should actively invest in their skills, knowledge, and professional network to maintain or enhance their value in the job market, rather than relying solely on their current employer for job stability or career growth. This principle promotes self-reliance, resilience, adaptability, and a proactive approach to career development. In his book Only the Paranoid Survive, (3) Andy Grove, the CEO of Intel, wrote, "Nobody owes you a career," emphasizing the idea that individuals are responsible for their own career growth and development. Andy’s brutally honest advice for employees rings true today in the face of economic uncertainty, rapidly evolving technologies, and the rise of artificial intelligence: If you are an employee, sooner or later you will be affected by a strategic inflection point. Who knows what your job will look like after cataclysmic change sweeps through your industry and engulfs the company you work for? Who knows if your job will even exist and, frankly, who will care besides you? Until very recently, if you went to work at an established company, you could assume that your job would last the rest of your working life. But when companies no longer have lifelong careers themselves, how can they provide one for their employees? As these companies struggle to adapt, the methods of doing business that worked very well for them for decades are becoming history. Companies that have had generations of employees growing up under a no-layoff policy are now dumping 10,000 people onto the street at a crack. The sad news is, nobody owes you a career. Your career is literally your business. You own it as a sole proprietor. You have one employee: yourself. You are in competition with millions of similar businesses: millions of other employees all over the world. You need to accept ownership of your career, your skills and the timing of your moves. It is your responsibility to protect this personal business of yours from harm and to position it to benefit from the changes in the environment. Nobody else can do that for you. To ensure job stability and employability, particularly for those working in companies with a history of mass layoffs or facing financial difficulties, employees should consider these recommendations: Establish an emergency fund covering at least six months of living expenses. Remain connected with or move closer toward the core revenue streams of your company Commit to yourself and your craft - invest in personal growth and skills development rather than relying on the company for job security Explore new job opportunities proactively, even before it becomes a necessity Cultivate and maintain a strong professional network outside your current company, as it will prove invaluable when needed You’ve Been WARN’ed To stay informed and prepared for potential job loss, employees should monitor their state's Worker Adjustment and Retraining Notification (WARN) reports (4) which require employers to give a 60-day advance notice before initiating a plant closure or mass layoff, allowing employees and their families time to prepare for potential job loss, explore alternative employment opportunities, and, if needed, acquire new skills or retrain to enhance their competitiveness in the job market. These reports can be found on individual state government websites. At the time of writing, the companies with the highest number of upcoming layoffs after today (April 3, 2023) are shown in the table below from WARNTracker.com. If you happen to work for one of these companies, you know what to do. May the odds be ever in your favor. References Zuckerberg, Mark. “Update on Meta’s Year of Efficiency.” Meta Newsroom. March 14, 2023. https://about.fb.com/news/2023/03/mark-zuckerberg-meta-year-of-efficiency/ Womack and Jones. Lean Thinking: Banish Waste and Create Wealth in Your Corporation, 2003. Grove, Andrew. Only the Paranoid Survive, 1998. Worker Adjustment and Retraining Notification (WARN) reports. WARN Tracker website. https://www.warntracker.com/

Over my past few engagements I’ve noticed that the days of greenfield Agile transformations are gone. I am increasingly seeing organizations where this is not the first or even second move to Agile. But, for whatever reason, the results have not been what the organization expected and so the next round of “Agile transformation” is created. To me this is a problem; we need to be asking why it is that so many Agile implementations are not producing the results expected. At the risk of sounding simplistic, I’ve come to believe that one key reason the Agile implementation fails to meet expectations is that organizations often reorganize multiple times as they are also expecting people to adopt new ways of working. In many ways a reorg could be seen as the biggest impediment to sustaining an Agile transformation. The reason for this is is straight-forward - a reorganization has a number of negative impacts on the Agile transformation: The negative impact of fear. As the reorganization rolls out, the pervasive emotion of the people affected, either directly or indirectly, is fear. People worry about potential loss of job, loss of position, loss of status, and loss of all the relationships they have built up. To move to the new ways of working expected as a result of an Agile transformation people need to be able to experiment, to try things out, to fail, to learn. All of this is impossible when fear is the driving emotion. Instead people’s reaction will be the opposite of this; they will work to protect themselves and revert back to ways of working that have proven to be “safe” in the past. The negative impact of the new structure. There is often a pendulum effect associated with reorgs. Today’s reorg might be about “centralization”; tomorrows is about “decentralization”; and then back again. The seeds of the next reorg are effectively being sown with this reorg. While it looks like something is “being done” to improve, what is not being addressed is the root problem that the organization is trying to solve. The negative impact of being forced to change. Reorgs are often thrust on the organization. Rumors spread about the reorg, while management decide on the new structure, mostly in secret. When revealed, people are expected to work through the new approach. The reality is that there is a period of purgatory where people try to work through the changes. Capacity that could be focused on bringing value to market is lost while people work through the change. And since the change often affects the whole organization, the loss of capacity is significant, and unrecoverable. Worse since the change is thrust on the organization, while management will see compliance, they will typically see a reduction in engagement from their people - not something we want to see with our people. Or as Charlton Ogburn states: Reorgs are … a wonderful method for creating the illusion of progress while producing confusion, inefficiency, and demoralization This is not to say that all reorgs are bad; it's just that we probably need to be more careful in our use of this management tool: Determine whether a new structure is required. For example, you can leverage the idea of a “virtual” organization (teams, multi-teams, portfolio, etc.) so that no change in reporting structure is required. A number of Agile implementations I’ve worked on created, for example, virtual cross-functional teams and multi-team structures, producing profound changes in business outcomes while reducing the downside consequences of a reorg. Determine how much of a new structure is required. If a change is required, can we minimize the “blast radius” of the change by: Applying lean-agile principles to the reorg. For example, based on the business outcome we are trying to address we could work toward a “minimal viable impact” of the reorg. Don’t change everything! Keep the things that are working well. Experiment. Leveraging organizational lean-agile organizational design tools to increase the chances that there will be an improvement as a result of the change. For example, line up the work in relationship to the value stream of the organization, incorporate an understanding of Conway's Law in the structure, understand the impact of changing team cognitive load as you work on your new design, leverage Organizational Network Analysis to really understand how work is done, and leverage tools like a Design Structure Matrix to understand impact of interdependencies in the system and reduce complexity. Reduce fear and increase engagement in the change. Apply lean change management principles so that people can engage more effectively in the change. For example, allow people in the organization to co-create the new organization by providing input into the process before the final step. Specifically talk about impacts on things like psychological safety, expectations as a result of the change, changing roles and responsibilities, and the changing dynamics associated with decision making. At a minimum, make sure discussions about what is going to happen happen at all levels and that there is meaningful two-way discussion. The bottom line is that reorgs, while common, are a pretty blunt instrument to use in our quest for improved business outcomes. This does not mean they are not necessary, but we can often get better outcomes, less invasively, by working the change through the Agile transformation.

David was struggling relating to key individuals in leadership roles particularly Becky and Kim. Kathryn asked me if I could help. I called David to schedule a chat. I feel bad, but I never made it to the end of his daily recorded voicemail greeting. Becky and Kim were classic drivers; comfortable taking charge and making fast and firm decisions based on a minimum of information. With a bias towards action they had little appreciation for David's in-depth analysis and detailed discourse. I shared with David a description from the DISC model of a driver: Driven by results and willing to take risks to achieve their goals. Extremely decisive, they are the people who will step up and take action. Preferring leadership positions, they are self-starters, confident and spurred to action by being presented with a challenge or competition. I asked him if that reminded him of anybody. Without hesitation, he said Becky, Kim and Kathryn. The DISC model provides the following guidance on how to interact with a driver. The best way to work with and communicate with someone possessing a dominant personality is to be direct, succinct, and stay on topic. It’s also best to speak confidently and avoid rambling, speaking repetitiously, or providing too much detail to these big-picture people. The E-colors personality model would describe David as Green and drivers as Red. It's not easy being Green. We are often forced to make difficult decisions based on imperfect information and this new age of Agile may seem a hostile environment for detail-oriented people. However, by experimenting and learning fast, we uncover greater insights and often way faster than if we spent more time doing analysis. Empirical learning through shortening the feedback loop is the essence of true business agility but it is also key to having two contrasting personalities co-exist and thrive.

Your entrepreneurial mindset got you a long way. Your product is valuable, feasible and viable. Now what. Responding to demands for more you add people of course. Someone suggested you need to be more agile which sounded like a good idea at the time. Now you look around the room and see familiar faces but who are all these others? Worst of all, despite doubling your workforce you’re not delivering as much as you did before. Where did it all go wrong? Think of any large endeavor, use your favorite hobby as an analog. Can you go straight from novice to expert? Of course not. Product development is an order of magnitude more complex. Yet why do we persistent in believing there is a simple answer? Maybe this isn't the first time you've tried Agile. If you are about to undertake yet another Agile transformation ask yourself this; is our new approach fundamentally different from what we did before or are we putting our faith in yet another big picture? Are we stuck in a never ending game of snakes and ladders? With so many succeeding with Agile it may seem a commodity. This assumption coupled with the notion that “there is one answer we just need to find it” leads us to the ladder of the next big picture only to slide back down the snake. Not understanding complexity we try to fit humans into boxes. As Dave Snowden points out, those rigid boundaries we establish, have a nasty habit of breaking catastrophically. To deal with complexity we cannot apply a 20th century project management mindset; we need to constantly sense and adapt. We need to invest in fostering an experimental mindset. Before attempting Agile in-the-large you must establish agility at the team and individual level. This is not easy, it takes courage, discipline and persistence. We need to overcome many biases. As Patrick Lencioni points out, organizational health is so simple and straightforward many have a hard time seeing it as a real opportunity for meaningful advantage. Starting small and mastering agility before scaling is a message difficult to hear, to deliver and to sell. Most hard choices are. Yet if you do have the courage, discipline and persistence you might just discover that you can do a whole lot more without ever scaling.

Or "Is there value in assigning Business Value to PI Objectives?" Every now an again you start a discussion with fellow agile coaches and find that there are widely different opinions about what makes sense. This happened to me recently. The subject was SAFe’s practice of assigning Business Value (BV) to PI Objectives as part of the PI Planning event, and the subsequent assessment of the actual Business Value as the ART completes work. Reactions from “I never coach PI Objectives, or Business Value because it doesn’t add value” to “the 1-10 scale makes no sense for a business value assessment” to “PI Objectives make sense; Business Value not so much”, and “I’ve seen Business Value assessment work well”, and so on. Now by way of context, the coaches I am talking with are all very experienced coaches, having worked with many organizations on their move to agile, and particularly agile at scale. The conversation is not the result of lack of knowledge or experience but rather based on a keen understanding of both the purpose of the practice, the why, and organizational dynamics in which it will be applied. So to review, the reason that SAFe suggests the practice of both PI Objectives and the assignment of Business Value is it to: Ensure there is feedback loop as a result of the PI Planning event between what was requested from the business, and what has planned by the teams. Enable local decision making by the teams when they are faced with conflicting priorities based on the established understanding of business priorities. As a side effect, enable the creation of “business value delivered” predictability measure. My experience has been that you can use both PI Objectives and Business Value assessment effectively. But I’ve also seen the practice get in the way of progressing true change or, worse still, seen organizations simply go through the motions, with no collaboration or feedback. I suspect that this in the end is the root cause of the different perspectives. I’ve seen the practice used very effectively. For example, I attended a PI System Demo recently and, as they went through the demonstrations, the Business Owner really closed the feedback loop by talking about what the original PI Objective’s expectation was, what happened in the meantime, and what the resultant effect was. She was clear about how we were all in this together and took pains to stress where the Program troika and the management team had contributed to (especially) less than expected results. The resultant actual business value assessment made sense. But if this is not happening, then you should not force the practice. What this means is that you will need to revisit the purpose of the practice, and determine how you will get the same outcome if you do not use this particular part of the framework. For example, can the organization agree that the feedback loop is based on features being delivered and what does it mean if we do this? Can we evaluate the predictability of business value delivered through more direct means, such as a result of the telemetry of released product? Should we use PI Objectives without assigning Business Value so we can establish this important feedback loop? And so on. Like all changes that effect the organization, context matters. And sometimes even experienced coaches will have to agree to disagree.