Rethinking Scaling: The Book of Right People Framework

In the following chapters you will be navigated through a story of a particular Right People (RIPE) framework implementation. The true names are exchanged and some details left out. Note that RIPE being a framework can be implemented in many ways depending on the respective context and the problem to solve.

You are invited to study the framework first to have a smooth read through the story: Explore the main concepts such as Topic Backlog so that you have a rough idea how they work when you hit them in course of the story. If you do not understand the framework fully, stay calm, you have only started reading the book.

You are also invited to join the RIPE framework LinkedIn group, where you can ask your questions of understanding to the book and share your ideas with people around the world:

>>> Join the LinkedIn group now <<<

Maybe you are not only interested in how the Right People framework works but also keen to know why it works. In such case you will enjoy chapters which follow, after the story comes to an end in the Part II of this book. 

At the end of each chapter, you will find I callout with supporting thoughts, questions to answer or little tasks to do. They are supposed to strengthen your understanding and to transfer your insights right away to your reality.

Now, take a deep breath and dive in.

My Name is Peter

My name is Peter, and I am a software engineer. Oh, this sounds like an opening sentence in a self-help group meeting. It shouldn’t. Probably, this comes from the hard time, I have gone through lately. My company was a place rich on interaction so to say. Not in a positive sense, however. My days used to be randomly filled with meetings of a likewise random quality. To be frank, most of the time they were pretty useless. I felt constantly distracted and couldn’t get much deep thinking done. I kept feeling sorry sprint by sprint for not delivering the output I was supposed to, and my Scrum Master couldn’t help with this impediment too. He used to argue that this was beyond our control. All right, now it feels like a self-help group meeting. Sorry for that, I just feel better getting this out me. 

Long story short, I quit this job and joined another company two weeks ago. The guy who interviewed me brought up an argument I couldn’t resist. They recently made some bold change to their meetings structure. He called it Right People framework, and my take was something like this: The new magic liberates you from an obligation to attend useless meetings because somebody imposed them on you (no matter if you like it or not). 

It sounded too good to be true. The guy was really into this, or he was good at selling. Either way, I decided for the option one and here I am. The guy whose place I took has left the company just because of meeting overload as I learned later. It seems like he wasn’t by far the only one who was sick and tired of a never-ending meeting madness. So, the new framework was hardly a fancy experiment of organizational development but a carefully designed strategic move towards employee retention.

Declined

A week ago, I attended my very first PI Planning at my new company and my new job felt all right. In fact, next to agile team events I was not invited to any meeting so far. I was happy about this but deep inside, was hoping this was not because I am a newbie yet. Also, I was on mission of a high management attention because the respective technical integration of our core system with SAP was a strategic step to our company.

You probably guess that now this story is going take a turn. You are right. My development environment was configured, and all tooling was ready to use. Let’s rock then! The sprint goal was stated very clearly: Prove a technical feasibility of SAP’s invoice service. I started to play with the interface according to the requirement. However, soon after this turned out to be quite a mess. The service was not accepting my parameters and if it did, in return it threw on me all error messages you can think of. So, I tried harder. The errors kept jumping at me even wilder. It was time to step back and think about getting some help on this. I travelled with me finger over the org-chart, looking for some shared service team, or for some architecture guys. There we go! A box called Platform Team smiled at me from the bottom of the org-chart. A few moments later I put some lyrics down to an invitation for the head of this team asking for support on SAP issues with invoice service: I face some problems with SAP invoice service and need some support to resolve them. Thank you in advance for your help.

It was surprisingly easy to find a time-slot with this guy, so I took my chance. I was proud of me because normally I would have spent days in search for a solution before I would reach out for a helping hand. With this feeling I left for lunch.

After lunch and a nice cup of coffee, I returned to my desk. To my big surprise my invite had been cancelled! Inside of the cancellation notice stood a short but clear message: Please submit this issue to the Topic Backlog. Thanks.

What was wrong with my invite? How he only dares to decline it? I felt offended, I felt disappointed, and above all, I felt left alone with my problem. At this point I decided to do, what I am supposed to do when I feel blocked. I reach out to our Scrum Master Lea, expecting a speech about this being beyond the circle of our control and so forth. Instead, she pointed me politely to the landing page of the Right People framework: Don’t feel bad about this Peter. The thing is, we do not conduct meetings to resolve cross-cutting issues anymore. Instead, we have a central Topic Backlog, where we collect all such issues to be processed in RIPE Sprints. I didn’t feel much better but at least I knew what to do next – go and find out how this Right People framework (RIPE) works. 

On my way home, I was thinking about how deeply it hurts to receive a cancellation of an invite. Normally you are obliged to accept a meeting invite if your agenda permits. It's difficult to accept when someone turns down your invitation. On the other hand, it takes some courage too, to decline an invitation just like that.

RTFM

In the next morning, I was over it. The next few hours were dedicated to my self-study of the RIPE lading page. To my big surprise, what I found was a one-pager with a very brief description of how the Right People framework works. It took me no more than 10 minutes to go through it. I learned how to submit a Topic to the Topic Backlog, and I also learned that RIPE Sprints are conducted every Thursday and how they worked.

So, I sat down and described the problem with the invoice service roughly and submitted the Topic to the Topic Backlog according to the description from the landing page. Piece of cake. I need to say thank you to Lea for pointing me to this stuff.

Few moments later, I received a notice from Herbie telling me that my Topic does not qualify for a RIPE Sprint. What is wrong with this company? In there a hidden camera somewhere recording the scene? Probably they are testing my resilience and probably this is a standard procedure to get to know how newbies handle frustrating moments. I was indeed frustrated, I started to question myself, and I couldn’t believe this is happening for real. Who was this Herbie anyway!?

The only person, who seemed not to refuse me yet was Lea. So, I decided to go and see her again. She asked me with her patient voice: You have carefully gone through the description of the Right People framework, haven’t you? Few moments later I found myself reading the brief one-pager again, but this time more carefully. It stated very clearly that a Topic needs to fulfill a so-called Definition of Ready (DoR) criteria to be qualified for a RIPE Sprint. One of the criteria requested to formulate the Topic by stating one or more well formulated key questions to be answered to resolve the Topic. Oh boy, my Topic hardly contained any key questions. I need to calm down, and re-phrase the Topic according to the Definition of Ready.

Asking the right questions is not easy.  It forces you to get ready for an interaction and gives the invited party an opportunity to get prepared. So, putting down key questions is the best way to verbalize expectations to the outcome of the respective meeting. According to the Right People framework, if and only if all the key questions are answered, the outcome of the meeting is positive. What the framework prescribes made a lot of sense to me. However, it took me some deep thinking to come up with the following key questions:

• Which version of the invoice service is the one to integrate?

• Where do I find the best description of the interface semantics?

• What is the meaning of the Error-Code 4321?

Read the f… manual (RTFM) came to my mind as was submitting the Topic again.

My first Time

It was Thursday morning, and I was on the call of my first RIPE Sprint. My Topic was one of 20 Topics selected to be processed on that day. At around 8:30am it was my turn to pitch the Topic. My voice was little bit shaking but I managed to get the message through thought there were 250 people on the call. It was easy because I didn’t need to improvise due to prepared key questions.

After the last pitch was over, Herbie invited all of us attending to vote for the most important Session. In a few moments we had a prioritized list of Sessions to process on that they. The Right People framework calls such day a RIPE Sprint and the respective list of Sessions a RIPE Sprint Backlog, which fits very nicely. 

Thereafter, Herbie placed the Sessions from the RIPE Sprint Backlog on the agenda of the day, one by one, making sure no Session is conflicting with some other due to People willing to attend both. In such case the respective people were supposed to raise their voice immediately. 

I assumed the guy from the Platform team will opt-in for my Session and we will have a one-on-one meeting. However, completely different people did, including the CIO! Yes, the CIO was interested to understand the issue and willing to provide her support. My Session has been prioritized very high because this SAP integration was a prestigious mission of a high management attention. Frankly, I was little nervous to have the CIO in the Session thought.

The Day after

The next day I went to Lea to say thank you. I was still impressed and flashed by the stuff which happened the other day. I told her that I understood the role of Herbie. He holds the organization back purposely because otherwise RIPE Sprint would get flooded with poorly prepared Topics of unclear expectations. This is a typical problem of conventional meetings.

Another problem of conventional meetings is poor or event missing facilitation. With RIPE it was not surprising that facilitation was great. A Track Host is facilitating many Sessions in a row which is the best way to acquired such skill.

One question kept me busy still: What if I do not opt-in for a Session and at the Check-out, I am not happy with some decision thereof? Lea smiled back at me and explained that in case I wouldn’t opt-in, I would express my trust to those colleagues who would attend the Session and therefore I was going to accept every decision they might take, no matter if I liked it or not. I argued that in some cases the decision might be wrong still. She smiled again and explained that I in such case was invited to submit a Topic to reconsider such a decision. But until this Topic hits a RIPE Sprint, the decision was going to stay in charge. 

This is nothing but a true face of our culture of trust, she added. At that moment I reflected my objection and saw another bad smell of my former company, where decisions lasted until they were over-ruled in some way, somewhere, somehow. So, the Right People framework provides a binding governance for our decision-making process I stated. Now you get it Peter, Leo confirmed.

Talking about trust, what happens if somebody wants to attend every Session? In such case you would end up with a single track, wouldn’t you? Lea seemed to expect this question: Yes, you would, and everybody would witness such behavior at agenda setting in the morning. At the end of the day, such a guy would set the pace of the value flow inside the company. Not by pulling strings behind the scenes but directly on the stage, where everybody including the top-management is watching. Instead of resolving 20 Topics weekly, we would maybe resolve 5 only and hold back the delivery at 25% because of pending decisions. Do you think, such behavior would survive? I understood. This system is self-optimizing and a behavior like this would hardly be tolerated.

I also realized that a Topic Backlog is a great source of information to management including C-Level. It reflects all the issues the organization is facing. Day by day, week by week. These issues expose the naked truth (no filter inside) because they come from all over the organization and bypass a bottom-up filter of the pyramid. This way management has got a chance to feel the pulse of the entire organization and grasp the true challenge people are confronted with. 

In the end I understood why it is not efficient to organize meetings both out of my local need and out of my local knowledge. It needs a Herbie and all the simple but powerful mechanisms of the Right People framework to make sure that the whole organization stays aligned to the overall priorities.

And my truly breathtaking insight? This organization literally changes its shape every Thursday. Depending on the Topics to process and depending on the people who chose to opt-in the organization re-groups entirely driven by the respective needs (Topics) and constraints (involve the right people during a RIPE Sprint). Most importantly, the opt-in principle makes sure the whole-group event of the RIPE Sprint stays highly efficient. Nobody spends a minute longer in meetings than needed! This stuff is truly game-changing.

In the end, the RIPE framework logic is designed to absorb complexity: 

1. Topic Backlog: Liberate people form meetings-overload so that they stop keeping each other busy for no reason (This is the key inter-relationship in scaled organizations to fix)

2. Definition of Ready: If there is a problem, don’t rush into quick local optimization but verbalize the problem by stating the respective key questions and share this reality across the company

3. RIPE Sprint: Bring the right people across the company together to understand the root cause of the problem and the relationships between the respective effects

4. RIPE Session: Take an aligned, profound and authorized decision right away

5. Check-out: Inform about the decision and explain it if necessary to stay on the same page across the entire organization

Walking back to my desk I was thinking about the role artificial intelligence might play in this. Just imagine a one-pager report for the CEO summarizing the Topic Backlog of the past week, past month, past year. That would probably uncover many chronic issues and pain points to address at the executive level.

Now it was time for a nice glass of wine watching a beautiful sunset. The radio plays Franky Sinatra with his I did it my way and … Okay, now it sounds like a sweet movie ending. It shouldn’t but I couldn’t help myself.

Lunch with the CEO

It is Friday. Peter as well as other recent hires enter a casual lunch setup in the company cafeteria. The CEO, Michael, is standing with a group of employees as part of a monthly initiative to connect directly with the team. One of the employees, Sarah, a product manager from a cross-functional team, takes the opportunity to stand next to him. Peter follows the conversation closely. 

Sarah: Thanks for doing this, Michael. It’s not every day we get to chat over a sandwich with the CEO.

Michael (smiling): Happy to be here, Sarah. These lunches are some of the best parts of my calendar—no slides, no Zoom fatigue, just real conversation.

Sarah: So, what keeps you busy these days—beyond the usual mountain of meetings?

Michael (chuckling): Well, you just named one of them—meetings. But it’s more than just being busy; what’s been really occupying my mind lately is a chronic challenge we’ve had for a while: meeting overload, poor decision-making processes, and siloed thinking.

Sarah: Sounds familiar. At my former company they’ve tried a few reorganizations over the years, but they never really stuck.

Michael: We’ve been through a similar journey here too. That’s what frustrated me. We’ve reorganized several times, hoping a new structure would magically fix these problems. But it didn’t. Because no matter how you slice an org chart, the need to align the parts never goes away. And unfortunately, new structures quickly become new silos anyway.

Sarah: So how are you thinking about it now?

Michael: I started looking for something fundamentally different—not just another restructure. I stumbled upon Kotter’s idea of a dual operating system, which was intriguing. The idea of running a network alongside the hierarchy made sense. But when we tried to translate that into something actionable... we hit a wall.

Sarah: Not surprised. It’s hard to implement abstract frameworks in a day-to-day reality. What seems like a good idea at the first glance is not quite the same after trying it out under real conditions.

Michael: Absolutely. Then—almost by accident—I came across something called the Right People framework. And it clicked. Unlike other approaches, this one doesn’t try to fix everything with new reporting lines. It focuses on clarity and cross-cutting collaboration, not control.

Sarah (leaning in): How so?

Michael: The framework separates two things:

• Creating clarity and alignment across silos, and

• Taking action, which stays with the accountable teams.

What struck me was that we’re not bad at execution—but we’re slow at alignment. That’s where we lose time and energy. Everyone's working hard, but not always in the same direction, or with the same understanding.

Sarah: That resonates. Sometimes I feel like we spend more time syncing with other teams than actually building things.

Michael: Exactly. The issue isn’t laziness or incompetence—it’s the structure itself. It makes it hard to tap into collective knowledge quickly. Messages going up and down the hierarchy get filtered, distorted. Assumptions creep in. By the time a decision is made, it's often based on incomplete or outdated information.

Sarah: So how does this framework solve that?

Michael: As it says in the name, It brings the right people together—not the "most senior," not the "official owners"—but those with relevant insights, regardless of their function. And it happens in time-boxed “RIPE Sprints”. These groups don’t execute solutions; they create shared clarity on cross-cutting issues. That clarity then flows back to the accountable teams to act on.

Sarah: No re-org? That almost sounds too good to be true.

Michael (smiling): That’s what I thought at first. But that’s the beauty of it—it’s a no-regret move. You don’t mess with reporting lines or existing SAFe structures. And because the topics go into a shared “RIPE Sprint Backlog” ahead of time, there’s transparency. If a sensitive or inappropriate topic sneaks in, I can spot it before it goes live and make sure it's handled the right way.

Sarah: That must take a lot of trust, though.

Michael: It does. But it builds more trust in return. And interestingly, I noticed a flavor of Theory of Constraints in the whole thing. Remember the book The Goal?

Sarah: Yeah! We read it in our Lean workshop last year.

Michael: Then you’ll get this: the framework surfaces the bottlenecks—not in production, but in thinking and alignment. It lets us work on what really blocks value flow.

Sarah: How does it play with the Scaled Agile Framework? You have invested a lot into that I’ve heard.

Michael: That was one of my first concerns. But it actually complements SAFe well. It doesn’t replace Agile Release Trains or the hierarchy—it enhances them. You can use the Right People framework to solve alignment issues that PI Planning doesn’t fully address. In fact, two weeks after a PI Planning many considerations become obsolete and the plan loses track.  The world keeps turning after a PI Planning and it is turning fast. 

Sarah: You run RIPE Sprints weekly. Is it not too much of an invest. I mean the whole organization comes together once a week, similarly to a PI Planning.

Michael First of all, it would be mistaken to compare a conventional SAFe PI Planning to a RIPE Sprint. At a RIPE Sprint, people opt in for Sessions, so they only attend, if they are willing to contribute. The only timeslot everybody shall attend is Pitch and plan, which takes no more than 20 minutes and a Check-out at the end of the day. So, nobody spends a minute being unproductive.  

Still, we were concerned with this. It was hard to tell how many topics were going to come up once we start inviting the people to bring their issues. We decided to start with a weekly cadence and adjust it as we go. At the beginning we had a high number of issues piling up but once we processed this legacy - so to speak – the numbers went down at a level we can well process weekly.

To have this number alone has been game-changing to us because until we implemented the RIPE framework, we had no clear indication of a need for alignment. Now, if we re-organize and this number Topics trends up then we know the re-organization was a mistake - the new org-chart introduced additional dependencies. It is as simple as that.

Sarah: That’s promising. So, what’s been the outcome so far?

Michael: Several, actually. Decisions are faster and better informed. Silo thinking is fading—people are collaborating across boundaries in ways we hadn’t seen before. But the biggest win? Employee engagement. People feel heard, included, and valued—not because we say it, but because the system demonstrates it during every RIPE Sprint.

Peter: Let me add to this. I have made a RIPE experience recently. It was nice to see that once you do not impose meetings and let people opt in for a session they are willing to contribute at, you end up with a level of engagement I have never seen before. Also, I was surprised to see how many people reached out to provide their helping hand. Now I understand what it means to tap the collective knowledge of a company. It means everything!

Sarah: I am impressed. It's rare to see such a bold positive outcome.

Michael: Exactly. No re-org fatigue, no expensive tools, no costly certifications, no army of consultants. Just better conversations for faster and smarter decisions. As a side-effect, no more siloed thinking and last but not least for me as an executive leader the best way to stay on pulse of the company and engage wherever it might help. Of course, I am also obliged to submit a Topic to the RIPE Topic Backlog if I have a cross-cutting issue to resolve.

Sarah: I’ve got the feeling there is some missing piece there, you haven’t told me about yet. 

Michael (nodding): I am glad you’re asking. In fact, there is. 

We are neither allowed to invite to a meeting for a cross-cutting issue, nor allowed to accept such an invite. Because all such issues belong to the RIPE Topic Backlog to be processed at some RIPE Sprint. This the way how we have stopped meeting overload for good. 

In addition, we are not allowed to overrule any decision taken in a RIPE Sprint unless we do this in some of the future RIPE Sprint. So to speak, what is decided in a RIPE Sprint can only be revisited in a RIPE Sprint. No bypassing allowed.

Sarah (smiling): Now I get the magic. I think I have several topics for the RIPE Topic Backlog, which I couldn’t resolve until now because I did not know who might help on them. This is a kind of a burden to me. Now, I look forward to the next RIPE Sprint to have them finally clarified. Yay!

Michael (laughing): That’s the goal. Taking decisions and creating clarity shall be something enjoyable and not a burden.

The conversation continues with a lighter tone as dessert is served, but the message sticks: transformation doesn’t always need to start with structure. Sometimes, it starts with getting the right people in the room.

Red and Blue Management Reality

As Albert Einstein once stated, you cannot solve problems by thinking which has caused them. Following up on this statement we invite you to re-think the prevalent ideas driving the management system of today’s enterprises. 

For this purpose, we build a new mental model of management reality to both articulate the problem and recognize the solution. We invite you to use two colors to indicate two capabilities each enterprise needs to master:

• Red: Ownership and enforcement

• Blue: Business agility and delivery speed at scale

We clearly recognize the importance of both. So, this is not about one over the other. We embrace the red, and we embrace the blue but each of them for a different reason. Markets do not care about your internal distribution of decision rights (red) but they care about how fast and how agile you deliver value (blue). However, any agile speedy move (blue), no matter how smart is worthless unless the respective decision is enforced to take an effect (red).

Enterprises around the world have been using the red management system for over decades very successfully. This system is based on the old paradigm of divide and conquer: Once a company grows larger, divide it up into smaller and thus manageable parts. Make sure these parts have a well-defined boundary (ownership) and distribute the decision rights the way that each owner is authorized to manage the respective part (enforcement). This is where pyramid like org charts come from.

Business Agility at Scale

The main problem encoded inside the red system is decision-making process at the enterprise level (across pyramid) when it comes down to responding to a quickly changing complex environment, faster and smarter than competitors do. 

This capability is also called business agility at scale. Let’s take a closer look at the above-mentioned decision-making process. This process consists of the following logical steps:

1. Recognize a need for a response coordinated (aligned) across the pyramid

2. Prioritize the need with respect to the other needs

3. Decide which action shall be taken

4. Enforce the decision for the sake of the desired impact 

The last step is well covered by the red management system. Remember, the red is designed for ownership and enforcement.

The first three steps, however, are the domain of blue. Clearly, they can only be mastered by an appropriate interaction across the pyramid to both tap the collective knowledge of the organization and gain buy-in. As an enterprise grows, such interaction becomes increasingly challenging.

Conventional scaling frameworks advocate great methods, canvases and practice. However, even the best canvas in the world is worthless unless the right people use it to co-create response to the respective business need. We strongly believe that these scaling frameworks have underestimated the value of interaction patterns, which in turn is the very reason why they have been failing to delivery on promise of business agility at scale.

Asynchronous Communication

This is the two interaction patterns which has been designed and cultivated inside enterprise reality for over decades:

• Asynchronous communication: Sending (email) messages and posting content in all sorts of collaboration tools

• Synchronous (in person) communication: Re-occurring or an ad hoc meeting where people from different parts of the pyramid come together to get aligned

Asynchronous communication is a very tempting option because technology of the digital age we are living in makes is easy to compose and deliver any message to many people instantly. The downside of an asynchronous communication is obvious. Inboxes are flooded by messages and notifications day in day out. To recognize the important ones and to ignore the rest is more than impossible. Even if you are lucky to make the right choice, you still need to understand the story it tells. It is incredibly easy to miss the point. You reach back with your answer, and the same movie goes on at the other side generating additional traffic and eventually leading to interpersonal tensions out of misinterpretation of a written word.

So, it is in many cases better and emotionally safer to talk in person. This is what meetings are good for. 

New Frameworks, old Thinking

As business agility and delivery speed at scale have increasingly become a survival type of capabilities, scaling frameworks started to pop up. Still, none of those has been able to deliver on promise. 

Why so? Because they have been heavily influenced by the red kind of thinking. In case you disagree at this point, hold on for a minute. Try to ignore what scaling frameworks have been selling to you and look at what they really come with. Nicely painted pyramids (no boxes but curvy shapes) with fancy names of their nodes and levels. They don’t call it a department but a value stream. They don’t call it a team, but a stream aligned team. They don’t call it decision rights but guard rails. In different words, they are all stuck in the red paradigm of divide and conquer.

The same holds for interaction patterns. The do not call it meetings but events, which does not make them any better. In addition, they also heavily utilize the freedom to invite (chapter Freedom to invite), the biggest enemy to effective interaction (and so to agility) at scale. 

The only innovative pattern conventional scaling frameworks have come up with, is a meeting called Big Room Planning or PI Planning. This whole group meeting is obviously another way of how not to solve the problem, because it is an imposed meeting (everybody is supposed to attend) with a poor cost/benefit ratio: The whole organization comes together to stress-guess a plan for the next quarter within two days using two formats:

• Whole group presentation

• Team breakout Session

Both formats are of course nothing but divide and conquer way of thinking because they copy the pyramid: A whole group presentation matches the entire pyramid whereas team breakout sessions divide people into their boxes. Obviously, both formats are incredibly inappropriate for bringing the right people together to resolve cross-team and cross-level issues efficiently.

Still, organizations around the world stick to the whole group meeting format because they haven’t been advocated a proper interaction pattern yet. If you have a hammer, everything looks like a nail.

Right People Capacity

Every organization has a physical limit of the number of meetings which can be conducted during a particular day (or during some other period) to have the right people involved at each of them.

We call this number Right People Capacity. In case the actual number of meetings lies above this limit the company is run by a poor decision-making process because of failure to involve the right people. The more the actual number exceeds the Right People Capacity the worse the negative impact:

• Decisions are wrong because they are based on false assumptions

• Decisions are postponed which hurts the business due to lost opportunities or due to a late response to threats

• Decisions are made without involving the people who are impacted by them which obviously leads to push-back and lack of support

For the above reason Right People Capacity is one of the primary constraints of decision-making process. The theory of constraints advocates the following steps for the most efficient use of a constraint:

• Identify the Constraint: Locate the bottleneck, or the single most limiting factor, within the system that restricts its overall performance and throughput

• Exploit the Constraint: Maximize the efficiency of the identified constraint by ensuring it is always working at its peak performance and is not idle

• Subordinate Everything Else to the Constraint: Align all other non-constraint processes and resources to the needs of the constraint, so they support its operations and don't overload it

• Elevate the Constraint: Increase the capacity of the constraint, either through investment in new equipment, technology, or other significant means, to improve overall system performance

• Repeat the Process: Once a constraint has been elevated, a new one will likely appear, so you should return to Step 1 and start the cycle again to ensure continuous improvement and prevent inertia from becoming a new constraint

Let’s examine how the RIPE framework implements the above steps.

Obviously, the Right People Capacity changes constantly depending on the respective issues to resolve (and decisions to take). This is why nobody can assess or calculate this number in advance. RIPE is rooted in Open Space Technology (OST) framework by Harrison Owen. One of the OST elements is called agenda setting, where “the group figures out what it wants to do”. At RIPE we call it Pitch & plan. The result of this step is a jointly designed agenda of the respective RIPE Sprint. By design this agenda makes sure that every Session during the RIPE sprint will have the right people involved. The resulting number of Sessions equals the Right People Capacity of the sprint. This is the way how RIPE identifies the constraint.

To maximize the Right People Capacity, attendance at a Pitch & plan step is obligatory the entire organization. This makes sure everybody has a chance to opt-in for every Session s/he wants to join. In addition, RIPE Sprint (this might be a particular weekday) is strictly reserved for RIPE Sessions. That means, this agenda-space can only be used for RIPE Sessions. As we pointed out in the previous chapters, one of the reasons to un-efficient meetings is a poor preparation. RIPE framework borrows the idea of definition of ready (DoR) from the scrum framework: Only those Topics which fulfill definition of ready are qualified for a RIPE Sprint. This quality-check is performed upon the Intake step by the role called Host. This is the way how RIPE exploits the constraint.

Every RIPE implementation must be very clear on which kind of issues it covers. That means, which issues are supposed to be handled by RIPE governance. Once a RIPE implementation is rolled out, no meetings are allowed to be invited, and no invitations are allowed to be accepted for issues covered by RIPE. In addition, issues inside the Topic Backlog are prioritized according to the overall corporate priorities. So, every RIPE Sprint is filled with issues which are at the top of the corporate agenda at that time. In case a Session could not resolve the respective Topic, the Topics goes back to the Topic Backlog. Again, an idea borrowed from the Scrum framework, called Definition of Done. Finally, RIPE Sessions are fully authorized to make instant decisions regarding the respective Topics including the rule we call One Space of Authority: Any decision taken during a RIPE Session can only be revised on some future RIPE Session. This is the way how RIPE subordinates everything else to the constraint.

Resolving issues and taking decisions across pyramid is a capability vital to survival in complex environment. However, as we pointed out in early chapters, a decision is worthless unless the respective action (inside the red management system) follows. This leads us to an important lesson: What is the right balance between decision-taking and acting? In other words, what is the right balance between alignment and delivery? Remember, alignment is a prerequisite to efficient delivery, but it is delivery what earns money at the end of the day. So, elevating of the Right People Capacity has some natural limit. This limit is exactly the point where delivery (red management system) becomes a new constraint. Since the RIPE framework makes the Topic Backlog transparent this turning point can be easily spotted inside the Topic Backlog. Remember, Topic Backlog is being collectively filled by the entire organization and repeatedly processed in RIPE Sprints. This way, an organization assess the need for alignment. Once the need gets weaker elevating the constraint doesn’t make sense anymore.